Re: [RFC] usb-phy-generic: Add support to SMSC USB3315

[Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>]

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.