Hi, On Wed, Dec 21, 2016 at 2:41 AM, Xing Zheng <zhengxing@xxxxxxxxxxxxxx> wrote: > From: William wu <wulf@xxxxxxxxxxxxxx> > > We found that the suspend process was blocked when it run into > ehci/ohci module due to clk-480m of usb2-phy was disabled. > > The root cause is that usb2-phy suspended earlier than ehci/ohci > (usb2-phy will be auto suspended if no devices plug-in). and the > clk-480m provided by it was disabled if no module used. However, > some suspend process related ehci/ohci are base on this clock, > so we should refer it into ehci/ohci driver to prevent this case. > > The u2phy clock flow like this: > === > u2phy ________________ > | | |-----> UTMI_CLK ---------> | EHCI | > OSC_24M ---|---> PHY_PLL----|----| > |________^_______| |-----> 480M_CLK ---|G|---> | USBPHY_480M_SRC| ----> USBPHY_480M for SoC > | > | > GRF > === > > Signed-off-by: William wu <wulf@xxxxxxxxxxxxxx> > Signed-off-by: Xing Zheng <zhengxing@xxxxxxxxxxxxxx> > --- > > Changes in v2: > - update the commit message > - remove patches whic add and export the USBPHYx_480M_SRC clock IDs > > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 28 ++++++++++++++++++++-------- > 1 file changed, 20 insertions(+), 8 deletions(-) > > diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > index b65c193..2ad9255 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > @@ -315,8 +315,10 @@ > compatible = "generic-ehci"; > reg = <0x0 0xfe380000 0x0 0x20000>; > interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH 0>; > - clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>; > - clock-names = "hclk_host0", "hclk_host0_arb"; > + clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>, > + <&u2phy0>; > + clock-names = "usbhost", "arbiter", > + "utmi"; > phys = <&u2phy0_host>; > phy-names = "usb"; > status = "disabled"; > @@ -326,8 +328,12 @@ > compatible = "generic-ohci"; > reg = <0x0 0xfe3a0000 0x0 0x20000>; > interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH 0>; > - clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>; > - clock-names = "hclk_host0", "hclk_host0_arb"; > + clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>, > + <&u2phy0>; > + clock-names = "usbhost", "arbiter", > + "utmi"; > + phys = <&u2phy0_host>; > + phy-names = "usb"; > status = "disabled"; > }; > > @@ -335,8 +341,10 @@ > compatible = "generic-ehci"; > reg = <0x0 0xfe3c0000 0x0 0x20000>; > interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH 0>; > - clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>; > - clock-names = "hclk_host1", "hclk_host1_arb"; > + clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>, > + <&u2phy1>; > + clock-names = "usbhost", "arbiter", > + "utmi"; > phys = <&u2phy1_host>; > phy-names = "usb"; > status = "disabled"; > @@ -346,8 +354,12 @@ > compatible = "generic-ohci"; > reg = <0x0 0xfe3e0000 0x0 0x20000>; > interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH 0>; > - clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>; > - clock-names = "hclk_host1", "hclk_host1_arb"; > + clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>, > + <&u2phy1>; > + clock-names = "usbhost", "arbiter", > + "utmi"; > + phys = <&u2phy1_host>; > + phy-names = "usb"; This all looks better to me. From a device tree point of view it makes lots of sense to expose this PHY clock to the controller. Thus: Reviewed-by: Douglas Anderson <dianders@xxxxxxxxxxxx> I can't say that I understand all the interactions between the PHY code and the USB driver, but presumably others have reviewed that more? Offline Heiko pointed me at rockchip_usb2phy_otg_sm_work() which apparently calls rockchip_usb2phy_power_off() and rockchip_usb2phy_power_on() directly sometimes behind the back of the PHY framework. Very strange. I will also say that there were still some unanswered questions from the previous thread, namely: A) Heiko: Also, with the change, the ehci will keep the clock (and thus the phy) always on. Does the phy-autosuspend even save anything now? B) Brian: Is thre a race between power_off() and the delayed work in your USB2 PHY driver? IMHO neither of those two questions affect the correctness of this patch: that this clock ought to be provided to the USB Controller. ...but they both are important questions that should be answered. One other last note is that we probably should be specifying a more specific compatible string, like: "rk3399-ehci", "generic-ehci" That will allow us later to use these same device tree files and perhaps deal with the clocks / PHYs in a more efficient way. -Doug -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
