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

[Fabien Lahoudere]

On Wed, 2017-06-07 at 09:43 +0800, Peter Chen wrote:
> On Tue, Jun 06, 2017 at 07:36:10PM +0200, Fabien Lahoudere wrote:
> > 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@xxxxxxxxxxxxxxx>
> > ---
> > Â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
> 
> Your above patch is not accepted. I don't know ULPI PHY behavior at
> imx53, would you please make clear below things:
> 
> - Before setting phy mode at portsc, which you need to do?
I need to prepare clock and enable vcc.
Calling "usb_phy_init" before "ci_ulpi_init" works.
In my case usb_phy_init points to usb_gen_phy_init() from phy-generic.c which basically do:

regulator_enable(nop->vcc);
clk_prepare_enable(nop->clk);
nop_reset(nop);

> Â If they can't be in phy_init, you may register a power sequence
> Â instance.
How can I register a power sequence? by adding clock in a subnode of usbh2 node?


> - Can you read pid/vid correctly, and which way you would
> Â like to match your ulpi device, pid/vid or using device
> Â tree, see ulpi_match
Yes I can read pid/vid (ulpi ci_hdrc.2.ulpi: registered ULPI PHY: vendor 0424, product 0006)
I am not sure which way I prefer. The better seems to be pid/vid.


>