[1/2] dt-bindings: msm/dsi: Add ref clock for 10nm PHY

Submitted by Matthias Kaehlcke on Nov. 2, 2018, 9:45 p.m.

Details

Message ID 20181102214534.184593-1-mka@chromium.org
State New
Headers show
Series "Series without cover letter" ( rev: 1 ) in Freedreno

Not browsing as part of any series.

Commit Message

Matthias Kaehlcke Nov. 2, 2018, 9:45 p.m.
Allow the 10nm PHY driver to get the ref clock from the DT.

Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
 Documentation/devicetree/bindings/display/msm/dsi.txt | 4 ++++
 1 file changed, 4 insertions(+)

Patch hide | download patch | download mbox

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt
index dfc743219bd88..d0d2046ceff69 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -105,6 +105,10 @@  Required properties:
 - power-domains: Should be <&mmcc MDSS_GDSC>.
 - clocks: Phandles to device clocks. See [1] for details on clock bindings.
 - clock-names: the following clocks are required:
+  For 10nm PHY:
+  * "iface"
+  * "ref"
+  For other PHYs:
   * "iface"
   For 28nm HPM/LP, 28nm 8960 PHYs:
 - vddio-supply: phandle to vdd-io regulator device node

Comments

On Fri, Nov 02, 2018 at 02:45:33PM -0700, Matthias Kaehlcke wrote:
> Allow the 10nm PHY driver to get the ref clock from the DT.
> 

Might be nice to state that there are no current users of the 10nm phy in your
commit message.

Sean

> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
>  Documentation/devicetree/bindings/display/msm/dsi.txt | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt
> index dfc743219bd88..d0d2046ceff69 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
> +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
> @@ -105,6 +105,10 @@ Required properties:
>  - power-domains: Should be <&mmcc MDSS_GDSC>.
>  - clocks: Phandles to device clocks. See [1] for details on clock bindings.
>  - clock-names: the following clocks are required:
> +  For 10nm PHY:
> +  * "iface"
> +  * "ref"
> +  For other PHYs:
>    * "iface"
>    For 28nm HPM/LP, 28nm 8960 PHYs:
>  - vddio-supply: phandle to vdd-io regulator device node
> -- 
> 2.19.1.930.g4563a0d9d0-goog
>
Quoting Matthias Kaehlcke (2018-11-02 14:45:33)
> Allow the 10nm PHY driver to get the ref clock from the DT.
> 
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
>  Documentation/devicetree/bindings/display/msm/dsi.txt | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt
> index dfc743219bd88..d0d2046ceff69 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
> +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
> @@ -105,6 +105,10 @@ Required properties:
>  - power-domains: Should be <&mmcc MDSS_GDSC>.
>  - clocks: Phandles to device clocks. See [1] for details on clock bindings.
>  - clock-names: the following clocks are required:
> +  For 10nm PHY:
> +  * "iface"
> +  * "ref"
> +  For other PHYs:
>    * "iface"

Any reason we can't go back and do this for other phys too? They're all
the same with regards to this reference clk input.

>    For 28nm HPM/LP, 28nm 8960 PHYs:
>  - vddio-supply: phandle to vdd-io regulator device node
On Tue, Nov 06, 2018 at 03:09:40PM -0800, Stephen Boyd wrote:
> Quoting Matthias Kaehlcke (2018-11-02 14:45:33)
> > Allow the 10nm PHY driver to get the ref clock from the DT.
> > 
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > ---
> >  Documentation/devicetree/bindings/display/msm/dsi.txt | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt
> > index dfc743219bd88..d0d2046ceff69 100644
> > --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
> > +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
> > @@ -105,6 +105,10 @@ Required properties:
> >  - power-domains: Should be <&mmcc MDSS_GDSC>.
> >  - clocks: Phandles to device clocks. See [1] for details on clock bindings.
> >  - clock-names: the following clocks are required:
> > +  For 10nm PHY:
> > +  * "iface"
> > +  * "ref"
> > +  For other PHYs:
> >    * "iface"
> 
> Any reason we can't go back and do this for other phys too? They're all
> the same with regards to this reference clk input.

To avoid breaking existing users, at least the 28nm PHY is used by
msm8916. Also I don't have the hardware to test changes for other
PHYs.

Cheers

Matthias
Quoting Matthias Kaehlcke (2018-11-14 14:42:52)
> On Tue, Nov 06, 2018 at 03:09:40PM -0800, Stephen Boyd wrote:
> > Quoting Matthias Kaehlcke (2018-11-02 14:45:33)
> > > Allow the 10nm PHY driver to get the ref clock from the DT.
> > > 
> > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > > ---
> > >  Documentation/devicetree/bindings/display/msm/dsi.txt | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt
> > > index dfc743219bd88..d0d2046ceff69 100644
> > > --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
> > > +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
> > > @@ -105,6 +105,10 @@ Required properties:
> > >  - power-domains: Should be <&mmcc MDSS_GDSC>.
> > >  - clocks: Phandles to device clocks. See [1] for details on clock bindings.
> > >  - clock-names: the following clocks are required:
> > > +  For 10nm PHY:
> > > +  * "iface"
> > > +  * "ref"
> > > +  For other PHYs:
> > >    * "iface"
> > 
> > Any reason we can't go back and do this for other phys too? They're all
> > the same with regards to this reference clk input.
> 
> To avoid breaking existing users, at least the 28nm PHY is used by
> msm8916. Also I don't have the hardware to test changes for other
> PHYs.
> 

Hmmm I don't see why we need to worry about breaking "legacy" users. If
they're using an undocumented but still working method of doing
something that should be OK, but I'd like to see us update the DTS and
binding to be more forward looking so that future designs don't carry
forward badness. And not having hardware hasn't really been a problem in
the past either. We can probably have someone from Linaro test on any
affected platforms.