From: Peter Chen <hzpeterchen@gmail.com>
To: Stephen Boyd <stephen.boyd@linaro.org>
Cc: linux-usb@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
Andy Gross <andy.gross@linaro.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Neil Armstrong <narmstrong@baylibre.com>,
Arnd Bergmann <arnd@arndb.de>, Felipe Balbi <balbi@kernel.org>,
Peter Chen <peter.chen@nxp.com>,
Kishon Vijay Abraham I <kishon@ti.com>,
devicetree@vger.kernel.org,
Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>
Subject: Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy
Date: Thu, 15 Sep 2016 13:29:06 +0800 [thread overview]
Message-ID: <20160915052905.GA23958@b29397-desktop> (raw)
In-Reply-To: <147387497029.16543.5921198225528254345@sboyd-linaro>
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
next prev parent reply other threads:[~2016-09-15 5:29 UTC|newest]
Thread overview: 26+ 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 ` [PATCH v4 02/22] of: device: Export of_device_{get_modalias, uvent_modalias} to modules Stephen Boyd
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
[not found] ` <20160907213519.27340-4-stephen.boyd-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-09-08 1:12 ` Rob Herring
2016-09-08 1:54 ` Stephen Boyd
2016-09-12 22:05 ` 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-08 0:58 ` Rob Herring
2016-09-07 21:35 ` [PATCH v4 21/22] phy: Add support for Qualcomm's USB HSIC phy Stephen Boyd
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-13 7:03 ` Peter Chen
2016-09-13 20:41 ` Stephen Boyd
2016-09-14 2:11 ` Peter Chen
2016-09-14 6:29 ` Stephen Boyd
2016-09-14 9:33 ` Peter Chen
2016-09-14 17:42 ` Stephen Boyd
2016-09-15 5:29 ` Peter Chen [this message]
[not found] ` <20160910121857.GB11271@a0393678ub>
2016-09-14 5:29 ` Kishon Vijay Abraham I
2016-09-16 15:19 ` Rob Herring
2016-09-17 0:05 ` Stephen Boyd
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 21:13 ` Stephen Boyd
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=20160915052905.GA23958@b29397-desktop \
--to=hzpeterchen@gmail.com \
--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=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 \
--cc=stephen.boyd@linaro.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).