From: Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>
To: Peter Chen <hzpeterchen@gmail.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>,
Peter Chen <peter.chen@nxp.com>,
Peter Senna Tschudin <peter.senna@collabora.com>,
Felipe Balbi <balbi@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"open list:USB PHY LAYER" <linux-usb@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] usb-phy-generic: Add support to SMSC USB3315
Date: Tue, 06 Jun 2017 19:36:10 +0200 [thread overview]
Message-ID: <1496770570.22734.3.camel@collabora.co.uk> (raw)
In-Reply-To: <20170606015528.GB26189@b29397-desktop>
Hi Peter,
On Tue, 2017-06-06 at 09:55 +0800, Peter Chen wrote:
> On Mon, Jun 05, 2017 at 11:52:26AM +0200, Fabien Lahoudere wrote:
> > On Mon, 2017-06-05 at 17:43 +0800, Peter Chen wrote:
> > > On Mon, Jun 05, 2017 at 10:57:00AM +0200, Fabien Lahoudere wrote:
> > > > On Fri, 2017-06-02 at 15:00 -0700, Stephen Boyd wrote:
> > > > > On 05/26, Fabien Lahoudere wrote:
> > > > > > Hello
> > > > > >
> > > > > > I modify ci_hrdc_imx_probe to bypass "data->phy = devm_usb_get_phy_by_phandle(&pdev-
> > > > > > >dev,
> > > > > > "fsl,usbphy", 0);". Everything works as expected and call ci_ulpi_init.
> > > > > >
> > > > > > The problem is that in ci_ulpi_init, before calling "ci->ulpi =
> > > > > > ulpi_register_interface(ci-
> > > > > > > dev,
> > > > > >
> > > > > > &ci->ulpi_ops);" (to initialize our phy), "hw_phymode_configure(ci);" is called which is
> > > > > > the
> > > > > > original function that make our system to hang.
> > > > > >
> > > > > > Our phy is not initialised before calling ulpi_register_interface so I don't understand
> > > > > > how
> > > > > > the
> > > > > > phy
> > > > > > can reply if it is not out of reset state.
> > > > >
> > > > > I haven't see any problem in hw_phymode_configure(). What's the
> > > > > value of ci->platdata->phy_mode? USBPHY_INTERFACE_MODE_ULPI? If
> > > > > you phy needs to be taken out of reset to reply to the ulpi reads
> > > > > of the vendor/product ids, then it sounds like you have a similar
> > > > > situation to what I had. I needed to turn on some regulators to
> > > > > get those reads to work, otherwise they would fail, but knowing
> > > > > what needed to be turned on basically meant I needed to probe the
> > > > > ulpi driver so probing the ids wasn't going to be useful. So on
> > > > > my device the reads for the ids go through, but they get all
> > > > > zeroes back, which is actually ok because there aren't any bits
> > > > > set on my devices anyway. After the reads see 0, we fallback to
> > > > > DT matching, which avoids the "bring it out of reset/power it on"
> > > > > sorts of problems entirely.
> > > > >
> > > >
> > > > Yes the phy mode is configured to USBPHY_INTERFACE_MODE_ULPI.
> > > > Indeed, this phy need to be out of reset to work. For example everything works fine if I
> > > > call
> > > > "_ci_usb_phy_init(ci);" before calling "hw_phymode_configure(ci);"
> > > > This function only init reset GPIO and clock.
> > > >
> > > > For information, the original patch I have to fix the issue:
> > > >
> > > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > > > index 79ad8e9..21aaff1 100644
> > > > --- a/drivers/usb/chipidea/core.c
> > > > +++ b/drivers/usb/chipidea/core.c
> > > > @@ -391,6 +391,7 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
> > > > case USBPHY_INTERFACE_MODE_UTMI:
> > > > case USBPHY_INTERFACE_MODE_UTMIW:
> > > > case USBPHY_INTERFACE_MODE_HSIC:
> > > > + case USBPHY_INTERFACE_MODE_ULPI:
> > > > ret = _ci_usb_phy_init(ci);
> > > > if (!ret)
> > > > hw_wait_phy_stable();
> > > > @@ -398,7 +399,6 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
> > > > return ret;
> > > > hw_phymode_configure(ci);
> > > > break;
> > > > - case USBPHY_INTERFACE_MODE_ULPI:
> > > > case USBPHY_INTERFACE_MODE_SERIAL:
> > > > hw_phymode_configure(ci);
> > > > ret = _ci_usb_phy_init(ci);
> > > > --
> > >
> > > Currently, the hw_phymode_configure is called twice for ULPI PHY, the
> > > two execution are between _ci_usb_phy_init, would you test which one
> > > causes hang? If the second causes hang, you can make a patch for
> > > hw_phymode_configure that if the required PORTSC_PTS is the same
> > > the value in register, do noop.
> >
> > The first one hangs, _ci_usb_phy_init is not called due to hang.
> >
>
> So, you need to comment out hw_phymode_configure at ci_ulpi_init, and you
> can't get vid/pid correctly, right? If it is, we may need to add power on
> sequence at chipidea core driver (ci_hdrc_probe) for clock and reset things.
>
> http://www.spinics.net/lists/linux-usb/msg157134.html
>
> I am wondering if we can call ci_usb_phy_init before calling ci_ulpi_init,
> since we need to let hardware be ready before reading vid/pid.
> Stephen & Fabien, does that work for you?
>
I test the following patch and it works. But I am not sure that we can move safely ci_ulpi_init.
I will investigate more tomorrow if it is a problem for other phys.
Is it a good approach?
Subject: [PATCH 1/1] power on phy before getting vid/pid
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>
---
drivers/usb/chipidea/core.c | 12 ++++++++----
drivers/usb/chipidea/ulpi.c | 19 +++++++++++++++++++
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 79ad8e9..26889e1 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -879,10 +879,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
return -ENODEV;
}
- ret = ci_ulpi_init(ci);
- if (ret)
- return ret;
-
if (ci->platdata->phy) {
ci->phy = ci->platdata->phy;
} else if (ci->platdata->usb_phy) {
@@ -909,6 +905,14 @@ static int ci_hdrc_probe(struct platform_device *pdev)
ci->usb_phy = NULL;
}
+ /*
+ We move this in order to have phy reset and gpio information
+ before calling ci_ulpi_init.
+ */
+ ret = ci_ulpi_init(ci);
+ if (ret)
+ return ret;
+
ret = ci_usb_phy_init(ci);
if (ret) {
dev_err(dev, "unable to init phy: %d\n", ret);
diff --git a/drivers/usb/chipidea/ulpi.c b/drivers/usb/chipidea/ulpi.c
index 1219583..1c272e4 100644
--- a/drivers/usb/chipidea/ulpi.c
+++ b/drivers/usb/chipidea/ulpi.c
@@ -73,9 +73,28 @@ static int ci_ulpi_write(struct device *dev, u8 addr, u8 val)
int ci_ulpi_init(struct ci_hdrc *ci)
{
+ int ret;
if (ci->platdata->phy_mode != USBPHY_INTERFACE_MODE_ULPI)
return 0;
+ /*
+ This is the content of _ci_usb_phy_init from core.c to power on the phy.
+ Duplicated for test purpose only.
+ */
+ if (ci->phy) {
+ ret = phy_init(ci->phy);
+ if (ret)
+ return ret;
+
+ ret = phy_power_on(ci->phy);
+ if (ret) {
+ phy_exit(ci->phy);
+ return ret;
+ }
+ } else {
+ ret = usb_phy_init(ci->usb_phy);
+ }
+
/*
* Set PORTSC correctly so we can read/write ULPI registers for
* identification purposes
--
1.8.3.1
Thanks
Fabien
next prev parent reply other threads:[~2017-06-06 17:36 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-19 6:14 [RFC] usb-phy-generic: Add support to SMSC USB3315 Peter Senna Tschudin
2017-04-19 10:03 ` Sergei Shtylyov
2017-04-19 10:24 ` Peter Senna Tschudin
2017-04-19 17:23 ` Sergei Shtylyov
2017-04-20 8:50 ` Peter Chen
2017-05-23 18:16 ` Fabien Lahoudere
2017-05-23 21:00 ` Stephen Boyd
2017-05-25 10:36 ` Fabien Lahoudere
2017-05-26 9:00 ` Fabien Lahoudere
2017-06-02 22:00 ` Stephen Boyd
2017-06-05 8:57 ` Fabien Lahoudere
2017-06-05 9:43 ` Peter Chen
2017-06-05 9:52 ` Fabien Lahoudere
2017-06-06 1:55 ` Peter Chen
2017-06-06 17:36 ` Fabien Lahoudere [this message]
2017-06-07 1:43 ` Peter Chen
2017-06-07 15:00 ` Fabien Lahoudere
2017-06-08 12:27 ` Fabien Lahoudere
2017-06-09 8:26 ` Peter Chen
2017-06-09 11:17 ` Fabien Lahoudere
2017-06-12 1:20 ` 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=1496770570.22734.3.camel@collabora.co.uk \
--to=fabien.lahoudere@collabora.co.uk \
--cc=balbi@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=hzpeterchen@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=peter.chen@nxp.com \
--cc=peter.senna@collabora.com \
--cc=sboyd@codeaurora.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 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.