From: Stephen Boyd <stephen.boyd@linaro.org> To: Peter Chen <hzpeterchen@gmail.com> Cc: Felipe Balbi <balbi@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Neil Armstrong <narmstrong@baylibre.com>, linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Bjorn Andersson <bjorn.andersson@linaro.org>, devicetree@vger.kernel.org, Peter Chen <peter.chen@nxp.com>, Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>, Andy Gross <andy.gross@linaro.org>, Kishon Vijay Abraham I <kishon@ti.com>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy Date: Wed, 14 Sep 2016 10:42:50 -0700 [thread overview] Message-ID: <147387497029.16543.5921198225528254345@sboyd-linaro> (raw) In-Reply-To: <20160914093307.GC21674@b29397-desktop> Quoting Peter Chen (2016-09-14 02:33:07) > 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. Ok. Makes sense. > > > 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? Yes. In the qcom designs the xcvr clk is necessary to read/write any of the registers in the controller. So we wouldn't be able to touch portsc.pts or any other controller registers without a hang. > > 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. > 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. Are there any concerns with this patch? Or can they be reapplied?
WARNING: multiple messages have this Message-ID (diff)
From: stephen.boyd@linaro.org (Stephen Boyd) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy Date: Wed, 14 Sep 2016 10:42:50 -0700 [thread overview] Message-ID: <147387497029.16543.5921198225528254345@sboyd-linaro> (raw) In-Reply-To: <20160914093307.GC21674@b29397-desktop> Quoting Peter Chen (2016-09-14 02:33:07) > 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. Ok. Makes sense. > > > 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? Yes. In the qcom designs the xcvr clk is necessary to read/write any of the registers in the controller. So we wouldn't be able to touch portsc.pts or any other controller registers without a hang. > > 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. > 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. Are there any concerns with this patch? Or can they be reapplied?
next prev parent reply other threads:[~2016-09-14 17:42 UTC|newest] Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-09-07 21:34 [PATCH v4 00/22] Support qcom's HSIC USB and rewrite USB2 HS support Stephen Boyd 2016-09-07 21:34 ` Stephen Boyd 2016-09-07 21:34 ` [PATCH v4 02/22] of: device: Export of_device_{get_modalias, uvent_modalias} to modules Stephen Boyd 2016-09-07 21:34 ` Stephen Boyd 2016-09-07 21:34 ` [PATCH v4 02/22] of: device: Export of_device_{get_modalias,uvent_modalias} " Stephen Boyd 2016-09-08 0:58 ` Rob Herring 2016-09-08 0:58 ` [PATCH v4 02/22] of: device: Export of_device_{get_modalias, uvent_modalias} " Rob Herring 2016-09-08 0:58 ` [PATCH v4 02/22] of: device: Export of_device_{get_modalias,uvent_modalias} " Rob Herring 2016-09-07 21:35 ` [PATCH v4 03/22] usb: ulpi: Support device discovery via DT Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd [not found] ` <20160907213519.27340-4-stephen.boyd-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2016-09-08 1:12 ` Rob Herring 2016-09-08 1:12 ` Rob Herring 2016-09-08 1:12 ` Rob Herring 2016-09-08 1:54 ` Stephen Boyd 2016-09-08 1:54 ` Stephen Boyd 2016-09-12 22:05 ` Stephen Boyd 2016-09-12 22:05 ` Stephen Boyd 2016-09-12 22:05 ` Stephen Boyd 2016-09-07 21:35 ` [PATCH v4 04/22] usb: chipidea: Only read/write OTGSC from one place Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` [PATCH v4 05/22] usb: chipidea: Handle extcon events properly Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` [PATCH v4 06/22] usb: chipidea: Add platform flag for wrapper phy management Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` [PATCH v4 07/22] usb: chipidea: Notify events when switching host mode Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` [PATCH v4 08/22] usb: chipidea: Remove locking in ci_udc_start() Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` [PATCH v4 09/22] usb: chipidea: Add support for ULPI PHY bus Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` [PATCH v4 10/22] usb: chipidea: Consolidate extcon notifiers Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-08 1:23 ` Peter Chen 2016-09-08 1:23 ` Peter Chen 2016-09-07 21:35 ` [PATCH v4 12/22] usb: chipidea: msm: Rely on core to override AHBBURST Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` [PATCH v4 15/22] usb: chipidea: msm: Mux over secondary phy at the right time Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` [PATCH v4 18/22] usb: chipidea: msm: Add reset controller for PHY POR bit Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` [PATCH v4 19/22] usb: chipidea: msm: Handle phy power states Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd [not found] ` <20160907213519.27340-1-stephen.boyd-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2016-09-07 21:34 ` [PATCH v4 01/22] of: device: Support loading a module with OF based modalias Stephen Boyd 2016-09-07 21:34 ` Stephen Boyd 2016-09-07 21:34 ` Stephen Boyd 2016-09-08 0:58 ` Rob Herring 2016-09-08 0:58 ` Rob Herring 2016-09-08 0:58 ` Rob Herring 2016-09-07 21:35 ` [PATCH v4 11/22] usb: chipidea: msm: Mark device as runtime pm active Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` [PATCH v4 13/22] usb: chipidea: msm: Use hw_write_id_reg() instead of writel Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` [PATCH v4 14/22] usb: chipidea: msm: Add proper clk and reset support Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` [PATCH v4 16/22] usb: chipidea: msm: Restore wrapper settings after reset Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` [PATCH v4 17/22] usb: chipidea: msm: Make platform data driver local instead of global Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` [PATCH v4 20/22] usb: chipidea: msm: Be silent on probe defer errors Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` [PATCH v4 21/22] phy: Add support for Qualcomm's USB HSIC phy Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-16 14:21 ` Rob Herring 2016-09-16 14:21 ` Rob Herring 2016-09-07 21:35 ` [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-07 21:35 ` Stephen Boyd 2016-09-13 7:03 ` Peter Chen 2016-09-13 7:03 ` Peter Chen 2016-09-13 20:41 ` Stephen Boyd 2016-09-13 20:41 ` Stephen Boyd 2016-09-14 2:11 ` Peter Chen 2016-09-14 2:11 ` Peter Chen 2016-09-14 2:11 ` Peter Chen 2016-09-14 6:29 ` Stephen Boyd 2016-09-14 6:29 ` Stephen Boyd 2016-09-14 9:33 ` Peter Chen 2016-09-14 9:33 ` Peter Chen 2016-09-14 17:42 ` Stephen Boyd [this message] 2016-09-14 17:42 ` Stephen Boyd 2016-09-15 5:29 ` Peter Chen 2016-09-15 5:29 ` Peter Chen [not found] ` <20160910121857.GB11271@a0393678ub> 2016-09-14 5:29 ` Kishon Vijay Abraham I 2016-09-14 5:29 ` Kishon Vijay Abraham I 2016-09-14 5:29 ` Kishon Vijay Abraham I 2016-09-16 15:19 ` Rob Herring 2016-09-16 15:19 ` Rob Herring 2016-09-17 0:05 ` Stephen Boyd 2016-09-17 0:05 ` Stephen Boyd 2016-09-19 21:01 ` Rob Herring 2016-09-19 21:01 ` Rob Herring 2016-09-19 21:01 ` Rob Herring 2016-09-08 2:06 ` [PATCH v4 00/22] Support qcom's HSIC USB and rewrite USB2 HS support Peter Chen 2016-09-08 2:06 ` Peter Chen 2016-09-08 2:06 ` Peter Chen 2016-09-08 21:13 ` Stephen Boyd 2016-09-08 21:13 ` Stephen Boyd 2016-09-09 0:45 ` Peter Chen 2016-09-09 0:45 ` Peter Chen 2016-09-09 0:45 ` Peter Chen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=147387497029.16543.5921198225528254345@sboyd-linaro \ --to=stephen.boyd@linaro.org \ --cc=andy.gross@linaro.org \ --cc=arnd@arndb.de \ --cc=balbi@kernel.org \ --cc=bjorn.andersson@linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=fabien.lahoudere@collabora.co.uk \ --cc=hzpeterchen@gmail.com \ --cc=kishon@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=narmstrong@baylibre.com \ --cc=peter.chen@nxp.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.