linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Chen <hzpeterchen@gmail.com>
To: Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>
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, 6 Jun 2017 09:55:28 +0800	[thread overview]
Message-ID: <20170606015528.GB26189@b29397-desktop> (raw)
In-Reply-To: <1496656346.31741.4.camel@collabora.co.uk>

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?

-- 

Best Regards,
Peter Chen

  reply	other threads:[~2017-06-06  1:55 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 [this message]
2017-06-06 17:36                     ` Fabien Lahoudere
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=20170606015528.GB26189@b29397-desktop \
    --to=hzpeterchen@gmail.com \
    --cc=balbi@kernel.org \
    --cc=fabien.lahoudere@collabora.co.uk \
    --cc=gregkh@linuxfoundation.org \
    --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 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).