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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
