Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Rob Herring]

On Fri, Sep 16, 2016 at 7:05 PM, Stephen Boyd  wrote:
> Quoting Rob Herring (2016-09-16 08:19:51)
>> On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
>> > The high-speed phy on qcom SoCs is controlled via the ULPI
>> > viewport.
>> >

[...]

>> > +- qcom,init-seq:
>> > +Usage: optional
>> > +Value type: 
>> > +Definition: Should contain a sequence of ULPI register and address 
>> > pairs to
>> > +program into the ULPI_EXT_VENDOR_SPECIFIC area. This is 
>> > related
>> > +to Device Mode Eye Diagram test.
>>
>> We generally nak this type of property. For 1 register I don't care so
>> much. For 100, that would be another story.
>>
>> Is this value per unit, per board, per SoC? Can you limit it to certain
>> registers?
>
> I'm told that this can be per board, depending on how it's wired from
> the phy pins to the usb port. Typically it's the same though for the
> boards I have, mostly because those boards are similar designs with
> respect to how USB is wired. The set of registers is not that many, 4 or
> 5 at most. My understanding is these are tuning registers. Right now the
> register part in the binding is the full register offset, and not an
> offset from ULPI_EXT_VENDOR_SPECIFIC (0x80). I could change this to be
> an offset from that area if you like so that this can't be abused to
> write into standard ULPI registers (there really isn't any way to
> enforce this in software though).

Okay, that sounds fine to me.

Rob

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Rob Herring]

On Fri, Sep 16, 2016 at 7:05 PM, Stephen Boyd  wrote:
> Quoting Rob Herring (2016-09-16 08:19:51)
>> On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
>> > The high-speed phy on qcom SoCs is controlled via the ULPI
>> > viewport.
>> >

[...]

>> > +- qcom,init-seq:
>> > +Usage: optional
>> > +Value type: 
>> > +Definition: Should contain a sequence of ULPI register and address 
>> > pairs to
>> > +program into the ULPI_EXT_VENDOR_SPECIFIC area. This is 
>> > related
>> > +to Device Mode Eye Diagram test.
>>
>> We generally nak this type of property. For 1 register I don't care so
>> much. For 100, that would be another story.
>>
>> Is this value per unit, per board, per SoC? Can you limit it to certain
>> registers?
>
> I'm told that this can be per board, depending on how it's wired from
> the phy pins to the usb port. Typically it's the same though for the
> boards I have, mostly because those boards are similar designs with
> respect to how USB is wired. The set of registers is not that many, 4 or
> 5 at most. My understanding is these are tuning registers. Right now the
> register part in the binding is the full register offset, and not an
> offset from ULPI_EXT_VENDOR_SPECIFIC (0x80). I could change this to be
> an offset from that area if you like so that this can't be abused to
> write into standard ULPI registers (there really isn't any way to
> enforce this in software though).

Okay, that sounds fine to me.

Rob

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Rob Herring]

On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> The high-speed phy on qcom SoCs is controlled via the ULPI
> viewport.
> 
> Cc: Kishon Vijay Abraham I 
> Cc: 
> Signed-off-by: Stephen Boyd 
> ---
>  .../devicetree/bindings/phy/qcom,usb-hs-phy.txt|  83 ++
>  drivers/phy/Kconfig|   8 +
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/phy-qcom-usb-hs.c  | 289 
> +
>  4 files changed, 381 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>  create mode 100644 drivers/phy/phy-qcom-usb-hs.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt 
> b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> new file mode 100644
> index ..d7eacd63d06b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> @@ -0,0 +1,83 @@
> +Qualcomm's USB HS PHY
> +
> +PROPERTIES
> +
> +- compatible:
> +Usage: required
> +Value type: 
> +Definition: Should contain "qcom,usb-hs-phy" and more specifically one 
> of the
> +following:
> +
> +"qcom,usb-hs-phy-apq8064"
> +"qcom,usb-hs-phy-msm8916"
> +"qcom,usb-hs-phy-msm8974"

This is fine, but things are usually named -.

> +
> +- #phy-cells:
> +Usage: required
> +Value type: 
> +Definition: Should contain 0
> +
> +- clocks:
> +Usage: required
> +Value type: 
> +Definition: Should contain clock specifier for the reference and sleep
> +clocks
> +
> +- clock-names:
> +Usage: required
> +Value type: 
> +Definition: Should contain "ref" and "sleep" for the reference and sleep
> +clocks respectively
> +
> +- resets:
> +Usage: required
> +Value type: 
> +Definition: Should contain the phy and POR resets
> +
> +- reset-names:
> +Usage: required
> +Value type: 
> +Definition: Should contain "phy" and "por" for the phy and POR resets
> +respectively
> +
> +- v3p3-supply:
> +Usage: required
> +Value type: 
> +Definition: Should contain a reference to the 3.3V supply
> +
> +- v1p8-supply:
> +Usage: required
> +Value type: 
> +Definition: Should contain a reference to the 1.8V supply
> +
> +- extcon:

I don't recommend using extcon binding. It needs some work to put it 
nicely.

> +Usage: optional
> +Value type: 
> +Definition: Should contain the vbus and ID extcons in the first and 
> second
> +cells respectively
> +
> +- qcom,init-seq:
> +Usage: optional
> +Value type: 
> +Definition: Should contain a sequence of ULPI register and address pairs 
> to
> +program into the ULPI_EXT_VENDOR_SPECIFIC area. This is 
> related
> +to Device Mode Eye Diagram test.

We generally nak this type of property. For 1 register I don't care so 
much. For 100, that would be another story.

Is this value per unit, per board, per SoC? Can you limit it to certain 
registers?

> +
> +EXAMPLE
> +
> +otg: usb-controller {
> + ulpi {
> + phy {
> + compatible = "qcom,usb-hs-phy-msm8974", 
> "qcom,usb-hs-phy";
> + #phy-cells = <0>;
> + clocks = <_board>, < GCC_USB2A_PHY_SLEEP_CLK>;
> + clock-names = "ref", "sleep";
> + resets = < GCC_USB2A_PHY_BCR>, < 0>;
> + reset-names = "phy", "por";
> + v3p3-supply = <_l24>;
> + v1p8-supply = <_l6>;
> + extcon = <>, <_id>;
> + qcom,init-seq = /bits/ 8 <0x81 0x63>;
> + };
> + };
> +};

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Rob Herring]

On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> The high-speed phy on qcom SoCs is controlled via the ULPI
> viewport.
> 
> Cc: Kishon Vijay Abraham I 
> Cc: 
> Signed-off-by: Stephen Boyd 
> ---
>  .../devicetree/bindings/phy/qcom,usb-hs-phy.txt|  83 ++
>  drivers/phy/Kconfig|   8 +
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/phy-qcom-usb-hs.c  | 289 
> +
>  4 files changed, 381 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>  create mode 100644 drivers/phy/phy-qcom-usb-hs.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt 
> b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> new file mode 100644
> index ..d7eacd63d06b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> @@ -0,0 +1,83 @@
> +Qualcomm's USB HS PHY
> +
> +PROPERTIES
> +
> +- compatible:
> +Usage: required
> +Value type: 
> +Definition: Should contain "qcom,usb-hs-phy" and more specifically one 
> of the
> +following:
> +
> +"qcom,usb-hs-phy-apq8064"
> +"qcom,usb-hs-phy-msm8916"
> +"qcom,usb-hs-phy-msm8974"

This is fine, but things are usually named -.

> +
> +- #phy-cells:
> +Usage: required
> +Value type: 
> +Definition: Should contain 0
> +
> +- clocks:
> +Usage: required
> +Value type: 
> +Definition: Should contain clock specifier for the reference and sleep
> +clocks
> +
> +- clock-names:
> +Usage: required
> +Value type: 
> +Definition: Should contain "ref" and "sleep" for the reference and sleep
> +clocks respectively
> +
> +- resets:
> +Usage: required
> +Value type: 
> +Definition: Should contain the phy and POR resets
> +
> +- reset-names:
> +Usage: required
> +Value type: 
> +Definition: Should contain "phy" and "por" for the phy and POR resets
> +respectively
> +
> +- v3p3-supply:
> +Usage: required
> +Value type: 
> +Definition: Should contain a reference to the 3.3V supply
> +
> +- v1p8-supply:
> +Usage: required
> +Value type: 
> +Definition: Should contain a reference to the 1.8V supply
> +
> +- extcon:

I don't recommend using extcon binding. It needs some work to put it 
nicely.

> +Usage: optional
> +Value type: 
> +Definition: Should contain the vbus and ID extcons in the first and 
> second
> +cells respectively
> +
> +- qcom,init-seq:
> +Usage: optional
> +Value type: 
> +Definition: Should contain a sequence of ULPI register and address pairs 
> to
> +program into the ULPI_EXT_VENDOR_SPECIFIC area. This is 
> related
> +to Device Mode Eye Diagram test.

We generally nak this type of property. For 1 register I don't care so 
much. For 100, that would be another story.

Is this value per unit, per board, per SoC? Can you limit it to certain 
registers?

> +
> +EXAMPLE
> +
> +otg: usb-controller {
> + ulpi {
> + phy {
> + compatible = "qcom,usb-hs-phy-msm8974", 
> "qcom,usb-hs-phy";
> + #phy-cells = <0>;
> + clocks = <_board>, < GCC_USB2A_PHY_SLEEP_CLK>;
> + clock-names = "ref", "sleep";
> + resets = < GCC_USB2A_PHY_BCR>, < 0>;
> + reset-names = "phy", "por";
> + v3p3-supply = <_l24>;
> + v1p8-supply = <_l6>;
> + extcon = <>, <_id>;
> + qcom,init-seq = /bits/ 8 <0x81 0x63>;
> + };
> + };
> +};

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Peter Chen]

On Wed, Sep 14, 2016 at 10:42:50AM -0700, Stephen Boyd wrote:
> > > 
> > > Hmm.. maybe the confusion is in which registers we should be able to
> > > access? Are we talking about the ULPI viewport MMIO register space or
> > > the ULPI registers that we access through the viewport? I have a
> > > hw_phymode_configure() inside of of ci_ulpi_init() so that the
> > > identification registers through the ULPI viewport read properly
> > > (assuming there aren't other power requirements like regulators). If we
> > > don't set the portsc.pts before using the viewport, the viewport doesn't
> > > work and reads timeout. So we really don't touch the ULPI registers
> > > except for the scratch space and the id registers until after the phy is
> > > properly powered on with clks and regulators, because the only place we
> > > touch them after doing the id checking is in this phy driver in
> > > qcom_usb_hs_phy_power_on(). We've "solved" the chicken-egg problem where
> > > we don't know which device driver to probe because the phy needs to be
> > > powered on to read the id registers to know which device driver to use
> > > by using DT to match up device drivers instead.
> > > 
> > > [1] https://www.sparkfun.com/datasheets/Components/SMD/ULPI_v1_1.pdf
> > 
> > Ok, ulpi phy works like USB device on USB bus which create device at
> > runtime. So, like some hard-wired USB devices, it may needs power
> > sequence too, otherwise, how it knows which driver can loads.
> > 
> 
> Yes. We use the DT compatible string to ignore any issues with reading
> the device ids when the device is powered off. Unlike USB though, we
> have device drivers for the ULPI PHYs that do the power sequencing along
> with other initializations, so using a common pwrseq layer seems like
> overkill just so we can read the id registers.

If the attempt to read id registers will not hang the system, it can
work. Like the case [1], without PHY ref_clk, it will hang when
configure PHY mode (visit portsc.pts), it has no chance to read id
registers. So, I still think the ULPI bus driver needs to do power
sequence for its children, unless you have some place to open the
ref_clk.

> 
> Are there any concerns with this patch? Or can they be reapplied?

For this patch, it is ok for me.


[1] http://www.spinics.net/lists/linux-usb/msg146336.html
-- 

Best Regards,
Peter Chen

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Peter Chen]

On Wed, Sep 14, 2016 at 10:42:50AM -0700, Stephen Boyd wrote:
> > > 
> > > Hmm.. maybe the confusion is in which registers we should be able to
> > > access? Are we talking about the ULPI viewport MMIO register space or
> > > the ULPI registers that we access through the viewport? I have a
> > > hw_phymode_configure() inside of of ci_ulpi_init() so that the
> > > identification registers through the ULPI viewport read properly
> > > (assuming there aren't other power requirements like regulators). If we
> > > don't set the portsc.pts before using the viewport, the viewport doesn't
> > > work and reads timeout. So we really don't touch the ULPI registers
> > > except for the scratch space and the id registers until after the phy is
> > > properly powered on with clks and regulators, because the only place we
> > > touch them after doing the id checking is in this phy driver in
> > > qcom_usb_hs_phy_power_on(). We've "solved" the chicken-egg problem where
> > > we don't know which device driver to probe because the phy needs to be
> > > powered on to read the id registers to know which device driver to use
> > > by using DT to match up device drivers instead.
> > > 
> > > [1] https://www.sparkfun.com/datasheets/Components/SMD/ULPI_v1_1.pdf
> > 
> > Ok, ulpi phy works like USB device on USB bus which create device at
> > runtime. So, like some hard-wired USB devices, it may needs power
> > sequence too, otherwise, how it knows which driver can loads.
> > 
> 
> Yes. We use the DT compatible string to ignore any issues with reading
> the device ids when the device is powered off. Unlike USB though, we
> have device drivers for the ULPI PHYs that do the power sequencing along
> with other initializations, so using a common pwrseq layer seems like
> overkill just so we can read the id registers.

If the attempt to read id registers will not hang the system, it can
work. Like the case [1], without PHY ref_clk, it will hang when
configure PHY mode (visit portsc.pts), it has no chance to read id
registers. So, I still think the ULPI bus driver needs to do power
sequence for its children, unless you have some place to open the
ref_clk.

> 
> Are there any concerns with this patch? Or can they be reapplied?

For this patch, it is ok for me.


[1] http://www.spinics.net/lists/linux-usb/msg146336.html
-- 

Best Regards,
Peter Chen

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Peter Chen]

On Tue, Sep 13, 2016 at 11:29:12PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-09-13 19:11:33)
> > On Tue, Sep 13, 2016 at 01:41:44PM -0700, Stephen Boyd wrote:
> > > Quoting Peter Chen (2016-09-13 00:03:58)
> > > > On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> > > > > The high-speed phy on qcom SoCs is controlled via the ULPI
> > > > > viewport.
> > > > > 
> > > > 
> > > > Hi Stephen, I am a little puzzled how this driver co-work with chipidea
> > > > driver. According to nxp IC guys, the ULPI PHY's clock needs to be 
> > > > enabled
> > > > before access portsc.pts (calling hw_phymode_configure), otherwise,
> > > > the system will hang. But I find you call hw_phymode_configure before
> > > > phy->power_on, doesn't your design have this requirement?
> > > 
> > > Which clk needs to be enabled? The xcvr_clk? I believe that clk
> > > corresponds to the "core" clk that we enable in the msm glue driver
> > > layer. When that clk is enabled, the ULPI phy is able to respond to
> > > register read/writes via the ULPI viewport.
> > > 
> > 
> > The input clock for ULPI PHY, maybe it is ref_clk at this PHY driver, 
> > so in your platform, even PHY clock is gated, you can still access
> > portsc.pts to configure PHY mode at controller register?
> 
> There are a couple input clocks for this phy. I'm not sure which one the
> nxp IC guys think needs to be enabled. Typically, the ref_clk is always
> on so it's hard for me to test a scenario where it isn't enabled. But
> I'm not sure that the ref_clk is what we're talking about anyway. Would
> you know the frequency perhaps?

I think this ref_clk is ULPI PHY vendor specific, at USB3317, it is
26Mhz.

> The ref_clk is usually 19.2MHz on these
> SoCs. That would match up with the "crystal input" pin in the ULPI
> spec[1].
> 
> Do you know if this is documented anywhere in the chipidea manual?
> I'll have to look again and see if there's something in there, but I
> didn't see anything like this.
> 
> I would guess that we're talking about the xcvr clock though, because
> from what I see in the manual, this is used to clock the interface
> between the ULPI phy and the controller. In the ULPI spec, this matches
> up with the "clock" signal for the ULPI phy and that usually runs at
> something >= 60MHz. 

I think you are right, since controller only concerns the output clock.
So, if you have not enabled xcvr, you may meet hang when set portsc.pts too?

At some designs, ULPI input clock (ref_clk) may from Soc internal,
without enabling it, the controller will not get PHY clock (60Mhz).
When visiting portsc.pts, may meet hang.

> 
> > 
> > > >
> > > > Besides, you read ulpi id before phy->power_on, how can read work before
> > > > phy power on?
> > > > 
> > > 
> > > I've found that even having the link clk enabled before phy->power_on
> > > doesn't mean it's possible to read the id registers though. That's
> > > because there can be other power supplies, like regulators, which need
> > > to be on for the phy to operate properly.
> > > 
> > 
> > Then I am puzzled the current initialization for your case, in my mind,
> > it should like below:
> > 
> > qcom_usb_hs_phy_probe->qcom_usb_hs_phy_power_on->ci_ulpi_init
> > 
> > Like other PHYs, it should get PHY first, then power on it, after that,
> > you can access its register.
> > 
> 
> Hmm.. maybe the confusion is in which registers we should be able to
> access? Are we talking about the ULPI viewport MMIO register space or
> the ULPI registers that we access through the viewport? I have a
> hw_phymode_configure() inside of of ci_ulpi_init() so that the
> identification registers through the ULPI viewport read properly
> (assuming there aren't other power requirements like regulators). If we
> don't set the portsc.pts before using the viewport, the viewport doesn't
> work and reads timeout. So we really don't touch the ULPI registers
> except for the scratch space and the id registers until after the phy is
> properly powered on with clks and regulators, because the only place we
> touch them after doing the id checking is in this phy driver in
> qcom_usb_hs_phy_power_on(). We've "solved" the chicken-egg problem where
> we don't know which device driver to probe because the phy needs to be
> powered on to read the id registers to know which device driver to use
> by using DT to match up device drivers instead.
> 
> [1] https://www.sparkfun.com/datasheets/Components/SMD/ULPI_v1_1.pdf

Ok, ulpi phy works like USB device on USB bus which create device at
runtime. So, like some hard-wired USB devices, it may needs power
sequence too, otherwise, how it knows which driver can loads.

-- 

Best Regards,
Peter Chen

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Peter Chen]

On Tue, Sep 13, 2016 at 11:29:12PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-09-13 19:11:33)
> > On Tue, Sep 13, 2016 at 01:41:44PM -0700, Stephen Boyd wrote:
> > > Quoting Peter Chen (2016-09-13 00:03:58)
> > > > On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> > > > > The high-speed phy on qcom SoCs is controlled via the ULPI
> > > > > viewport.
> > > > > 
> > > > 
> > > > Hi Stephen, I am a little puzzled how this driver co-work with chipidea
> > > > driver. According to nxp IC guys, the ULPI PHY's clock needs to be 
> > > > enabled
> > > > before access portsc.pts (calling hw_phymode_configure), otherwise,
> > > > the system will hang. But I find you call hw_phymode_configure before
> > > > phy->power_on, doesn't your design have this requirement?
> > > 
> > > Which clk needs to be enabled? The xcvr_clk? I believe that clk
> > > corresponds to the "core" clk that we enable in the msm glue driver
> > > layer. When that clk is enabled, the ULPI phy is able to respond to
> > > register read/writes via the ULPI viewport.
> > > 
> > 
> > The input clock for ULPI PHY, maybe it is ref_clk at this PHY driver, 
> > so in your platform, even PHY clock is gated, you can still access
> > portsc.pts to configure PHY mode at controller register?
> 
> There are a couple input clocks for this phy. I'm not sure which one the
> nxp IC guys think needs to be enabled. Typically, the ref_clk is always
> on so it's hard for me to test a scenario where it isn't enabled. But
> I'm not sure that the ref_clk is what we're talking about anyway. Would
> you know the frequency perhaps?

I think this ref_clk is ULPI PHY vendor specific, at USB3317, it is
26Mhz.

> The ref_clk is usually 19.2MHz on these
> SoCs. That would match up with the "crystal input" pin in the ULPI
> spec[1].
> 
> Do you know if this is documented anywhere in the chipidea manual?
> I'll have to look again and see if there's something in there, but I
> didn't see anything like this.
> 
> I would guess that we're talking about the xcvr clock though, because
> from what I see in the manual, this is used to clock the interface
> between the ULPI phy and the controller. In the ULPI spec, this matches
> up with the "clock" signal for the ULPI phy and that usually runs at
> something >= 60MHz. 

I think you are right, since controller only concerns the output clock.
So, if you have not enabled xcvr, you may meet hang when set portsc.pts too?

At some designs, ULPI input clock (ref_clk) may from Soc internal,
without enabling it, the controller will not get PHY clock (60Mhz).
When visiting portsc.pts, may meet hang.

> 
> > 
> > > >
> > > > Besides, you read ulpi id before phy->power_on, how can read work before
> > > > phy power on?
> > > > 
> > > 
> > > I've found that even having the link clk enabled before phy->power_on
> > > doesn't mean it's possible to read the id registers though. That's
> > > because there can be other power supplies, like regulators, which need
> > > to be on for the phy to operate properly.
> > > 
> > 
> > Then I am puzzled the current initialization for your case, in my mind,
> > it should like below:
> > 
> > qcom_usb_hs_phy_probe->qcom_usb_hs_phy_power_on->ci_ulpi_init
> > 
> > Like other PHYs, it should get PHY first, then power on it, after that,
> > you can access its register.
> > 
> 
> Hmm.. maybe the confusion is in which registers we should be able to
> access? Are we talking about the ULPI viewport MMIO register space or
> the ULPI registers that we access through the viewport? I have a
> hw_phymode_configure() inside of of ci_ulpi_init() so that the
> identification registers through the ULPI viewport read properly
> (assuming there aren't other power requirements like regulators). If we
> don't set the portsc.pts before using the viewport, the viewport doesn't
> work and reads timeout. So we really don't touch the ULPI registers
> except for the scratch space and the id registers until after the phy is
> properly powered on with clks and regulators, because the only place we
> touch them after doing the id checking is in this phy driver in
> qcom_usb_hs_phy_power_on(). We've "solved" the chicken-egg problem where
> we don't know which device driver to probe because the phy needs to be
> powered on to read the id registers to know which device driver to use
> by using DT to match up device drivers instead.
> 
> [1] https://www.sparkfun.com/datasheets/Components/SMD/ULPI_v1_1.pdf

Ok, ulpi phy works like USB device on USB bus which create device at
runtime. So, like some hard-wired USB devices, it may needs power
sequence too, otherwise, how it knows which driver can loads.

-- 

Best Regards,
Peter Chen

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Kishon Vijay Abraham I]

On Saturday 10 September 2016 05:48 PM, Kishon Vijay Abraham I wrote:
> 
> On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
>> The high-speed phy on qcom SoCs is controlled via the ULPI
>> viewport.
>>
>> Cc: Kishon Vijay Abraham I 
>> Cc: 
>> Signed-off-by: Stephen Boyd 
> 
> merged this and the previous patch to linux-phy.

since there are pending discussions, I'll drop this patch for now.

Thanks
Kishon
> 
> Thanks
> Kishon
> 
>> ---
>>  .../devicetree/bindings/phy/qcom,usb-hs-phy.txt|  83 ++
>>  drivers/phy/Kconfig|   8 +
>>  drivers/phy/Makefile   |   1 +
>>  drivers/phy/phy-qcom-usb-hs.c  | 289 
>> +
>>  4 files changed, 381 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>>  create mode 100644 drivers/phy/phy-qcom-usb-hs.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt 
>> b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>> new file mode 100644
>> index ..d7eacd63d06b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>> @@ -0,0 +1,83 @@
>> +Qualcomm's USB HS PHY
>> +
>> +PROPERTIES
>> +
>> +- compatible:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain "qcom,usb-hs-phy" and more specifically one 
>> of the
>> +following:
>> +
>> +"qcom,usb-hs-phy-apq8064"
>> +"qcom,usb-hs-phy-msm8916"
>> +"qcom,usb-hs-phy-msm8974"
>> +
>> +- #phy-cells:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain 0
>> +
>> +- clocks:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain clock specifier for the reference and sleep
>> +clocks
>> +
>> +- clock-names:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain "ref" and "sleep" for the reference and sleep
>> +clocks respectively
>> +
>> +- resets:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain the phy and POR resets
>> +
>> +- reset-names:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain "phy" and "por" for the phy and POR resets
>> +respectively
>> +
>> +- v3p3-supply:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain a reference to the 3.3V supply
>> +
>> +- v1p8-supply:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain a reference to the 1.8V supply
>> +
>> +- extcon:
>> +Usage: optional
>> +Value type: 
>> +Definition: Should contain the vbus and ID extcons in the first and 
>> second
>> +cells respectively
>> +
>> +- qcom,init-seq:
>> +Usage: optional
>> +Value type: 
>> +Definition: Should contain a sequence of ULPI register and address 
>> pairs to
>> +program into the ULPI_EXT_VENDOR_SPECIFIC area. This is 
>> related
>> +to Device Mode Eye Diagram test.
>> +
>> +EXAMPLE
>> +
>> +otg: usb-controller {
>> +ulpi {
>> +phy {
>> +compatible = "qcom,usb-hs-phy-msm8974", 
>> "qcom,usb-hs-phy";
>> +#phy-cells = <0>;
>> +clocks = <_board>, < GCC_USB2A_PHY_SLEEP_CLK>;
>> +clock-names = "ref", "sleep";
>> +resets = < GCC_USB2A_PHY_BCR>, < 0>;
>> +reset-names = "phy", "por";
>> +v3p3-supply = <_l24>;
>> +v1p8-supply = <_l6>;
>> +extcon = <>, <_id>;
>> +qcom,init-seq = /bits/ 8 <0x81 0x63>;
>> +};
>> +};
>> +};
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 830c443eeabf..ee0ec021a98c 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -417,6 +417,14 @@ config PHY_QCOM_UFS
>>  help
>>Support for UFS PHY on QCOM chipsets.
>>  
>> +config PHY_QCOM_USB_HS
>> +tristate "Qualcomm USB HS PHY module"
>> +depends on USB_ULPI_BUS
>> +select GENERIC_PHY
>> +help
>> +  Support for the USB high-speed ULPI compliant phy on Qualcomm
>> +  chipsets.
>> +
>>  config PHY_QCOM_USB_HSIC
>>  tristate "Qualcomm USB HSIC ULPI PHY module"
>>  depends on USB_ULPI_BUS
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 5422f543d17d..31c84faa07fa 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -50,6 +50,7 @@ obj-$(CONFIG_PHY_STIH41X_USB)  += 
>> phy-stih41x-usb.o
>>  obj-$(CONFIG_PHY_QCOM_UFS)  += phy-qcom-ufs.o
>>  obj-$(CONFIG_PHY_QCOM_UFS)  += phy-qcom-ufs-qmp-20nm.o
>>  obj-$(CONFIG_PHY_QCOM_UFS)  += phy-qcom-ufs-qmp-14nm.o
>> +obj-$(CONFIG_PHY_QCOM_USB_HS)   += 

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Kishon Vijay Abraham I]

On Saturday 10 September 2016 05:48 PM, Kishon Vijay Abraham I wrote:
> 
> On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
>> The high-speed phy on qcom SoCs is controlled via the ULPI
>> viewport.
>>
>> Cc: Kishon Vijay Abraham I 
>> Cc: 
>> Signed-off-by: Stephen Boyd 
> 
> merged this and the previous patch to linux-phy.

since there are pending discussions, I'll drop this patch for now.

Thanks
Kishon
> 
> Thanks
> Kishon
> 
>> ---
>>  .../devicetree/bindings/phy/qcom,usb-hs-phy.txt|  83 ++
>>  drivers/phy/Kconfig|   8 +
>>  drivers/phy/Makefile   |   1 +
>>  drivers/phy/phy-qcom-usb-hs.c  | 289 
>> +
>>  4 files changed, 381 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>>  create mode 100644 drivers/phy/phy-qcom-usb-hs.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt 
>> b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>> new file mode 100644
>> index ..d7eacd63d06b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>> @@ -0,0 +1,83 @@
>> +Qualcomm's USB HS PHY
>> +
>> +PROPERTIES
>> +
>> +- compatible:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain "qcom,usb-hs-phy" and more specifically one 
>> of the
>> +following:
>> +
>> +"qcom,usb-hs-phy-apq8064"
>> +"qcom,usb-hs-phy-msm8916"
>> +"qcom,usb-hs-phy-msm8974"
>> +
>> +- #phy-cells:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain 0
>> +
>> +- clocks:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain clock specifier for the reference and sleep
>> +clocks
>> +
>> +- clock-names:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain "ref" and "sleep" for the reference and sleep
>> +clocks respectively
>> +
>> +- resets:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain the phy and POR resets
>> +
>> +- reset-names:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain "phy" and "por" for the phy and POR resets
>> +respectively
>> +
>> +- v3p3-supply:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain a reference to the 3.3V supply
>> +
>> +- v1p8-supply:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain a reference to the 1.8V supply
>> +
>> +- extcon:
>> +Usage: optional
>> +Value type: 
>> +Definition: Should contain the vbus and ID extcons in the first and 
>> second
>> +cells respectively
>> +
>> +- qcom,init-seq:
>> +Usage: optional
>> +Value type: 
>> +Definition: Should contain a sequence of ULPI register and address 
>> pairs to
>> +program into the ULPI_EXT_VENDOR_SPECIFIC area. This is 
>> related
>> +to Device Mode Eye Diagram test.
>> +
>> +EXAMPLE
>> +
>> +otg: usb-controller {
>> +ulpi {
>> +phy {
>> +compatible = "qcom,usb-hs-phy-msm8974", 
>> "qcom,usb-hs-phy";
>> +#phy-cells = <0>;
>> +clocks = <_board>, < GCC_USB2A_PHY_SLEEP_CLK>;
>> +clock-names = "ref", "sleep";
>> +resets = < GCC_USB2A_PHY_BCR>, < 0>;
>> +reset-names = "phy", "por";
>> +v3p3-supply = <_l24>;
>> +v1p8-supply = <_l6>;
>> +extcon = <>, <_id>;
>> +qcom,init-seq = /bits/ 8 <0x81 0x63>;
>> +};
>> +};
>> +};
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 830c443eeabf..ee0ec021a98c 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -417,6 +417,14 @@ config PHY_QCOM_UFS
>>  help
>>Support for UFS PHY on QCOM chipsets.
>>  
>> +config PHY_QCOM_USB_HS
>> +tristate "Qualcomm USB HS PHY module"
>> +depends on USB_ULPI_BUS
>> +select GENERIC_PHY
>> +help
>> +  Support for the USB high-speed ULPI compliant phy on Qualcomm
>> +  chipsets.
>> +
>>  config PHY_QCOM_USB_HSIC
>>  tristate "Qualcomm USB HSIC ULPI PHY module"
>>  depends on USB_ULPI_BUS
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 5422f543d17d..31c84faa07fa 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -50,6 +50,7 @@ obj-$(CONFIG_PHY_STIH41X_USB)  += 
>> phy-stih41x-usb.o
>>  obj-$(CONFIG_PHY_QCOM_UFS)  += phy-qcom-ufs.o
>>  obj-$(CONFIG_PHY_QCOM_UFS)  += phy-qcom-ufs-qmp-20nm.o
>>  obj-$(CONFIG_PHY_QCOM_UFS)  += phy-qcom-ufs-qmp-14nm.o
>> +obj-$(CONFIG_PHY_QCOM_USB_HS)   += phy-qcom-usb-hs.o
>>  obj-$(CONFIG_PHY_QCOM_USB_HSIC) += 

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Peter Chen]

On Tue, Sep 13, 2016 at 01:41:44PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-09-13 00:03:58)
> > On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> > > The high-speed phy on qcom SoCs is controlled via the ULPI
> > > viewport.
> > > 
> > 
> > Hi Stephen, I am a little puzzled how this driver co-work with chipidea
> > driver. According to nxp IC guys, the ULPI PHY's clock needs to be enabled
> > before access portsc.pts (calling hw_phymode_configure), otherwise,
> > the system will hang. But I find you call hw_phymode_configure before
> > phy->power_on, doesn't your design have this requirement?
> 
> Which clk needs to be enabled? The xcvr_clk? I believe that clk
> corresponds to the "core" clk that we enable in the msm glue driver
> layer. When that clk is enabled, the ULPI phy is able to respond to
> register read/writes via the ULPI viewport.
> 

The input clock for ULPI PHY, maybe it is ref_clk at this PHY driver, 
so in your platform, even PHY clock is gated, you can still access
portsc.pts to configure PHY mode at controller register?

> >
> > Besides, you read ulpi id before phy->power_on, how can read work before
> > phy power on?
> > 
> 
> I've found that even having the link clk enabled before phy->power_on
> doesn't mean it's possible to read the id registers though. That's
> because there can be other power supplies, like regulators, which need
> to be on for the phy to operate properly.
> 

Then I am puzzled the current initialization for your case, in my mind,
it should like below:

qcom_usb_hs_phy_probe->qcom_usb_hs_phy_power_on->ci_ulpi_init

Like other PHYs, it should get PHY first, then power on it, after that,
you can access its register.

-- 

Best Regards,
Peter Chen

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Peter Chen]

On Tue, Sep 13, 2016 at 01:41:44PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-09-13 00:03:58)
> > On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> > > The high-speed phy on qcom SoCs is controlled via the ULPI
> > > viewport.
> > > 
> > 
> > Hi Stephen, I am a little puzzled how this driver co-work with chipidea
> > driver. According to nxp IC guys, the ULPI PHY's clock needs to be enabled
> > before access portsc.pts (calling hw_phymode_configure), otherwise,
> > the system will hang. But I find you call hw_phymode_configure before
> > phy->power_on, doesn't your design have this requirement?
> 
> Which clk needs to be enabled? The xcvr_clk? I believe that clk
> corresponds to the "core" clk that we enable in the msm glue driver
> layer. When that clk is enabled, the ULPI phy is able to respond to
> register read/writes via the ULPI viewport.
> 

The input clock for ULPI PHY, maybe it is ref_clk at this PHY driver, 
so in your platform, even PHY clock is gated, you can still access
portsc.pts to configure PHY mode at controller register?

> >
> > Besides, you read ulpi id before phy->power_on, how can read work before
> > phy power on?
> > 
> 
> I've found that even having the link clk enabled before phy->power_on
> doesn't mean it's possible to read the id registers though. That's
> because there can be other power supplies, like regulators, which need
> to be on for the phy to operate properly.
> 

Then I am puzzled the current initialization for your case, in my mind,
it should like below:

qcom_usb_hs_phy_probe->qcom_usb_hs_phy_power_on->ci_ulpi_init

Like other PHYs, it should get PHY first, then power on it, after that,
you can access its register.

-- 

Best Regards,
Peter Chen

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Peter Chen]

On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> The high-speed phy on qcom SoCs is controlled via the ULPI
> viewport.
> 

Hi Stephen, I am a little puzzled how this driver co-work with chipidea
driver. According to nxp IC guys, the ULPI PHY's clock needs to be enabled
before access portsc.pts (calling hw_phymode_configure), otherwise,
the system will hang. But I find you call hw_phymode_configure before
phy->power_on, doesn't your design have this requirement?
   
Besides, you read ulpi id before phy->power_on, how can read work before
phy power on?

Peter

> Cc: Kishon Vijay Abraham I 
> Cc: 
> Signed-off-by: Stephen Boyd 
> ---
>  .../devicetree/bindings/phy/qcom,usb-hs-phy.txt|  83 ++
>  drivers/phy/Kconfig|   8 +
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/phy-qcom-usb-hs.c  | 289 
> +
>  4 files changed, 381 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>  create mode 100644 drivers/phy/phy-qcom-usb-hs.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt 
> b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> new file mode 100644
> index ..d7eacd63d06b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> @@ -0,0 +1,83 @@
> +Qualcomm's USB HS PHY
> +
> +PROPERTIES
> +
> +- compatible:
> +Usage: required
> +Value type: 
> +Definition: Should contain "qcom,usb-hs-phy" and more specifically one 
> of the
> +following:
> +
> +"qcom,usb-hs-phy-apq8064"
> +"qcom,usb-hs-phy-msm8916"
> +"qcom,usb-hs-phy-msm8974"
> +
> +- #phy-cells:
> +Usage: required
> +Value type: 
> +Definition: Should contain 0
> +
> +- clocks:
> +Usage: required
> +Value type: 
> +Definition: Should contain clock specifier for the reference and sleep
> +clocks
> +
> +- clock-names:
> +Usage: required
> +Value type: 
> +Definition: Should contain "ref" and "sleep" for the reference and sleep
> +clocks respectively
> +
> +- resets:
> +Usage: required
> +Value type: 
> +Definition: Should contain the phy and POR resets
> +
> +- reset-names:
> +Usage: required
> +Value type: 
> +Definition: Should contain "phy" and "por" for the phy and POR resets
> +respectively
> +
> +- v3p3-supply:
> +Usage: required
> +Value type: 
> +Definition: Should contain a reference to the 3.3V supply
> +
> +- v1p8-supply:
> +Usage: required
> +Value type: 
> +Definition: Should contain a reference to the 1.8V supply
> +
> +- extcon:
> +Usage: optional
> +Value type: 
> +Definition: Should contain the vbus and ID extcons in the first and 
> second
> +cells respectively
> +
> +- qcom,init-seq:
> +Usage: optional
> +Value type: 
> +Definition: Should contain a sequence of ULPI register and address pairs 
> to
> +program into the ULPI_EXT_VENDOR_SPECIFIC area. This is 
> related
> +to Device Mode Eye Diagram test.
> +
> +EXAMPLE
> +
> +otg: usb-controller {
> + ulpi {
> + phy {
> + compatible = "qcom,usb-hs-phy-msm8974", 
> "qcom,usb-hs-phy";
> + #phy-cells = <0>;
> + clocks = <_board>, < GCC_USB2A_PHY_SLEEP_CLK>;
> + clock-names = "ref", "sleep";
> + resets = < GCC_USB2A_PHY_BCR>, < 0>;
> + reset-names = "phy", "por";
> + v3p3-supply = <_l24>;
> + v1p8-supply = <_l6>;
> + extcon = <>, <_id>;
> + qcom,init-seq = /bits/ 8 <0x81 0x63>;
> + };
> + };
> +};
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 830c443eeabf..ee0ec021a98c 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -417,6 +417,14 @@ config PHY_QCOM_UFS
>   help
> Support for UFS PHY on QCOM chipsets.
>  
> +config PHY_QCOM_USB_HS
> + tristate "Qualcomm USB HS PHY module"
> + depends on USB_ULPI_BUS
> + select GENERIC_PHY
> + help
> +   Support for the USB high-speed ULPI compliant phy on Qualcomm
> +   chipsets.
> +
>  config PHY_QCOM_USB_HSIC
>   tristate "Qualcomm USB HSIC ULPI PHY module"
>   depends on USB_ULPI_BUS
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 5422f543d17d..31c84faa07fa 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -50,6 +50,7 @@ obj-$(CONFIG_PHY_STIH41X_USB)   += 
> phy-stih41x-usb.o
>  obj-$(CONFIG_PHY_QCOM_UFS)   += phy-qcom-ufs.o
>  obj-$(CONFIG_PHY_QCOM_UFS)   += phy-qcom-ufs-qmp-20nm.o
>  

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Peter Chen]

On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> The high-speed phy on qcom SoCs is controlled via the ULPI
> viewport.
> 

Hi Stephen, I am a little puzzled how this driver co-work with chipidea
driver. According to nxp IC guys, the ULPI PHY's clock needs to be enabled
before access portsc.pts (calling hw_phymode_configure), otherwise,
the system will hang. But I find you call hw_phymode_configure before
phy->power_on, doesn't your design have this requirement?
   
Besides, you read ulpi id before phy->power_on, how can read work before
phy power on?

Peter

> Cc: Kishon Vijay Abraham I 
> Cc: 
> Signed-off-by: Stephen Boyd 
> ---
>  .../devicetree/bindings/phy/qcom,usb-hs-phy.txt|  83 ++
>  drivers/phy/Kconfig|   8 +
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/phy-qcom-usb-hs.c  | 289 
> +
>  4 files changed, 381 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>  create mode 100644 drivers/phy/phy-qcom-usb-hs.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt 
> b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> new file mode 100644
> index ..d7eacd63d06b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> @@ -0,0 +1,83 @@
> +Qualcomm's USB HS PHY
> +
> +PROPERTIES
> +
> +- compatible:
> +Usage: required
> +Value type: 
> +Definition: Should contain "qcom,usb-hs-phy" and more specifically one 
> of the
> +following:
> +
> +"qcom,usb-hs-phy-apq8064"
> +"qcom,usb-hs-phy-msm8916"
> +"qcom,usb-hs-phy-msm8974"
> +
> +- #phy-cells:
> +Usage: required
> +Value type: 
> +Definition: Should contain 0
> +
> +- clocks:
> +Usage: required
> +Value type: 
> +Definition: Should contain clock specifier for the reference and sleep
> +clocks
> +
> +- clock-names:
> +Usage: required
> +Value type: 
> +Definition: Should contain "ref" and "sleep" for the reference and sleep
> +clocks respectively
> +
> +- resets:
> +Usage: required
> +Value type: 
> +Definition: Should contain the phy and POR resets
> +
> +- reset-names:
> +Usage: required
> +Value type: 
> +Definition: Should contain "phy" and "por" for the phy and POR resets
> +respectively
> +
> +- v3p3-supply:
> +Usage: required
> +Value type: 
> +Definition: Should contain a reference to the 3.3V supply
> +
> +- v1p8-supply:
> +Usage: required
> +Value type: 
> +Definition: Should contain a reference to the 1.8V supply
> +
> +- extcon:
> +Usage: optional
> +Value type: 
> +Definition: Should contain the vbus and ID extcons in the first and 
> second
> +cells respectively
> +
> +- qcom,init-seq:
> +Usage: optional
> +Value type: 
> +Definition: Should contain a sequence of ULPI register and address pairs 
> to
> +program into the ULPI_EXT_VENDOR_SPECIFIC area. This is 
> related
> +to Device Mode Eye Diagram test.
> +
> +EXAMPLE
> +
> +otg: usb-controller {
> + ulpi {
> + phy {
> + compatible = "qcom,usb-hs-phy-msm8974", 
> "qcom,usb-hs-phy";
> + #phy-cells = <0>;
> + clocks = <_board>, < GCC_USB2A_PHY_SLEEP_CLK>;
> + clock-names = "ref", "sleep";
> + resets = < GCC_USB2A_PHY_BCR>, < 0>;
> + reset-names = "phy", "por";
> + v3p3-supply = <_l24>;
> + v1p8-supply = <_l6>;
> + extcon = <>, <_id>;
> + qcom,init-seq = /bits/ 8 <0x81 0x63>;
> + };
> + };
> +};
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 830c443eeabf..ee0ec021a98c 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -417,6 +417,14 @@ config PHY_QCOM_UFS
>   help
> Support for UFS PHY on QCOM chipsets.
>  
> +config PHY_QCOM_USB_HS
> + tristate "Qualcomm USB HS PHY module"
> + depends on USB_ULPI_BUS
> + select GENERIC_PHY
> + help
> +   Support for the USB high-speed ULPI compliant phy on Qualcomm
> +   chipsets.
> +
>  config PHY_QCOM_USB_HSIC
>   tristate "Qualcomm USB HSIC ULPI PHY module"
>   depends on USB_ULPI_BUS
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 5422f543d17d..31c84faa07fa 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -50,6 +50,7 @@ obj-$(CONFIG_PHY_STIH41X_USB)   += 
> phy-stih41x-usb.o
>  obj-$(CONFIG_PHY_QCOM_UFS)   += phy-qcom-ufs.o
>  obj-$(CONFIG_PHY_QCOM_UFS)   += phy-qcom-ufs-qmp-20nm.o
>  obj-$(CONFIG_PHY_QCOM_UFS)   += phy-qcom-ufs-qmp-14nm.o
> 

[PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Stephen Boyd]

The high-speed phy on qcom SoCs is controlled via the ULPI
viewport.

Cc: Kishon Vijay Abraham I 
Cc: 
Signed-off-by: Stephen Boyd 
---
 .../devicetree/bindings/phy/qcom,usb-hs-phy.txt|  83 ++
 drivers/phy/Kconfig|   8 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-qcom-usb-hs.c  | 289 +
 4 files changed, 381 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
 create mode 100644 drivers/phy/phy-qcom-usb-hs.c

diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
new file mode 100644
index ..d7eacd63d06b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
@@ -0,0 +1,83 @@
+Qualcomm's USB HS PHY
+
+PROPERTIES
+
+- compatible:
+Usage: required
+Value type: 
+Definition: Should contain "qcom,usb-hs-phy" and more specifically one of 
the
+following:
+
+"qcom,usb-hs-phy-apq8064"
+"qcom,usb-hs-phy-msm8916"
+"qcom,usb-hs-phy-msm8974"
+
+- #phy-cells:
+Usage: required
+Value type: 
+Definition: Should contain 0
+
+- clocks:
+Usage: required
+Value type: 
+Definition: Should contain clock specifier for the reference and sleep
+clocks
+
+- clock-names:
+Usage: required
+Value type: 
+Definition: Should contain "ref" and "sleep" for the reference and sleep
+clocks respectively
+
+- resets:
+Usage: required
+Value type: 
+Definition: Should contain the phy and POR resets
+
+- reset-names:
+Usage: required
+Value type: 
+Definition: Should contain "phy" and "por" for the phy and POR resets
+respectively
+
+- v3p3-supply:
+Usage: required
+Value type: 
+Definition: Should contain a reference to the 3.3V supply
+
+- v1p8-supply:
+Usage: required
+Value type: 
+Definition: Should contain a reference to the 1.8V supply
+
+- extcon:
+Usage: optional
+Value type: 
+Definition: Should contain the vbus and ID extcons in the first and second
+cells respectively
+
+- qcom,init-seq:
+Usage: optional
+Value type: 
+Definition: Should contain a sequence of ULPI register and address pairs to
+program into the ULPI_EXT_VENDOR_SPECIFIC area. This is related
+to Device Mode Eye Diagram test.
+
+EXAMPLE
+
+otg: usb-controller {
+   ulpi {
+   phy {
+   compatible = "qcom,usb-hs-phy-msm8974", 
"qcom,usb-hs-phy";
+   #phy-cells = <0>;
+   clocks = <_board>, < GCC_USB2A_PHY_SLEEP_CLK>;
+   clock-names = "ref", "sleep";
+   resets = < GCC_USB2A_PHY_BCR>, < 0>;
+   reset-names = "phy", "por";
+   v3p3-supply = <_l24>;
+   v1p8-supply = <_l6>;
+   extcon = <>, <_id>;
+   qcom,init-seq = /bits/ 8 <0x81 0x63>;
+   };
+   };
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 830c443eeabf..ee0ec021a98c 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -417,6 +417,14 @@ config PHY_QCOM_UFS
help
  Support for UFS PHY on QCOM chipsets.
 
+config PHY_QCOM_USB_HS
+   tristate "Qualcomm USB HS PHY module"
+   depends on USB_ULPI_BUS
+   select GENERIC_PHY
+   help
+ Support for the USB high-speed ULPI compliant phy on Qualcomm
+ chipsets.
+
 config PHY_QCOM_USB_HSIC
tristate "Qualcomm USB HSIC ULPI PHY module"
depends on USB_ULPI_BUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 5422f543d17d..31c84faa07fa 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_PHY_STIH41X_USB) += phy-stih41x-usb.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
+obj-$(CONFIG_PHY_QCOM_USB_HS)  += phy-qcom-usb-hs.o
 obj-$(CONFIG_PHY_QCOM_USB_HSIC)+= phy-qcom-usb-hsic.o
 obj-$(CONFIG_PHY_TUSB1210) += phy-tusb1210.o
 obj-$(CONFIG_PHY_BRCM_SATA)+= phy-brcm-sata.o
diff --git a/drivers/phy/phy-qcom-usb-hs.c b/drivers/phy/phy-qcom-usb-hs.c
new file mode 100644
index ..73fb4b49a8e1
--- /dev/null
+++ b/drivers/phy/phy-qcom-usb-hs.c
@@ -0,0 +1,289 @@
+/**
+ * Copyright (C) 2016 Linaro Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 

[PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Stephen Boyd]

The high-speed phy on qcom SoCs is controlled via the ULPI
viewport.

Cc: Kishon Vijay Abraham I 
Cc: 
Signed-off-by: Stephen Boyd 
---
 .../devicetree/bindings/phy/qcom,usb-hs-phy.txt|  83 ++
 drivers/phy/Kconfig|   8 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-qcom-usb-hs.c  | 289 +
 4 files changed, 381 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
 create mode 100644 drivers/phy/phy-qcom-usb-hs.c

diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
new file mode 100644
index ..d7eacd63d06b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
@@ -0,0 +1,83 @@
+Qualcomm's USB HS PHY
+
+PROPERTIES
+
+- compatible:
+Usage: required
+Value type: 
+Definition: Should contain "qcom,usb-hs-phy" and more specifically one of 
the
+following:
+
+"qcom,usb-hs-phy-apq8064"
+"qcom,usb-hs-phy-msm8916"
+"qcom,usb-hs-phy-msm8974"
+
+- #phy-cells:
+Usage: required
+Value type: 
+Definition: Should contain 0
+
+- clocks:
+Usage: required
+Value type: 
+Definition: Should contain clock specifier for the reference and sleep
+clocks
+
+- clock-names:
+Usage: required
+Value type: 
+Definition: Should contain "ref" and "sleep" for the reference and sleep
+clocks respectively
+
+- resets:
+Usage: required
+Value type: 
+Definition: Should contain the phy and POR resets
+
+- reset-names:
+Usage: required
+Value type: 
+Definition: Should contain "phy" and "por" for the phy and POR resets
+respectively
+
+- v3p3-supply:
+Usage: required
+Value type: 
+Definition: Should contain a reference to the 3.3V supply
+
+- v1p8-supply:
+Usage: required
+Value type: 
+Definition: Should contain a reference to the 1.8V supply
+
+- extcon:
+Usage: optional
+Value type: 
+Definition: Should contain the vbus and ID extcons in the first and second
+cells respectively
+
+- qcom,init-seq:
+Usage: optional
+Value type: 
+Definition: Should contain a sequence of ULPI register and address pairs to
+program into the ULPI_EXT_VENDOR_SPECIFIC area. This is related
+to Device Mode Eye Diagram test.
+
+EXAMPLE
+
+otg: usb-controller {
+   ulpi {
+   phy {
+   compatible = "qcom,usb-hs-phy-msm8974", 
"qcom,usb-hs-phy";
+   #phy-cells = <0>;
+   clocks = <_board>, < GCC_USB2A_PHY_SLEEP_CLK>;
+   clock-names = "ref", "sleep";
+   resets = < GCC_USB2A_PHY_BCR>, < 0>;
+   reset-names = "phy", "por";
+   v3p3-supply = <_l24>;
+   v1p8-supply = <_l6>;
+   extcon = <>, <_id>;
+   qcom,init-seq = /bits/ 8 <0x81 0x63>;
+   };
+   };
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 830c443eeabf..ee0ec021a98c 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -417,6 +417,14 @@ config PHY_QCOM_UFS
help
  Support for UFS PHY on QCOM chipsets.
 
+config PHY_QCOM_USB_HS
+   tristate "Qualcomm USB HS PHY module"
+   depends on USB_ULPI_BUS
+   select GENERIC_PHY
+   help
+ Support for the USB high-speed ULPI compliant phy on Qualcomm
+ chipsets.
+
 config PHY_QCOM_USB_HSIC
tristate "Qualcomm USB HSIC ULPI PHY module"
depends on USB_ULPI_BUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 5422f543d17d..31c84faa07fa 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_PHY_STIH41X_USB) += phy-stih41x-usb.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
+obj-$(CONFIG_PHY_QCOM_USB_HS)  += phy-qcom-usb-hs.o
 obj-$(CONFIG_PHY_QCOM_USB_HSIC)+= phy-qcom-usb-hsic.o
 obj-$(CONFIG_PHY_TUSB1210) += phy-tusb1210.o
 obj-$(CONFIG_PHY_BRCM_SATA)+= phy-brcm-sata.o
diff --git a/drivers/phy/phy-qcom-usb-hs.c b/drivers/phy/phy-qcom-usb-hs.c
new file mode 100644
index ..73fb4b49a8e1
--- /dev/null
+++ b/drivers/phy/phy-qcom-usb-hs.c
@@ -0,0 +1,289 @@
+/**
+ * Copyright (C) 2016 Linaro Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include