All of lore.kernel.org
 help / color / mirror / Atom feed
From: valentin.longchamp@epfl.ch (Valentin Longchamp)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/1] ehci-mxc: Fix mx31 OTG host initialisation
Date: Tue, 11 May 2010 11:03:41 +0200	[thread overview]
Message-ID: <4BE91D6D.5010207@epfl.ch> (raw)
In-Reply-To: <20100511063907.GU31199@pengutronix.de>

See the comments below.

On 05/11/2010 08:39 AM, Sascha Hauer wrote:
> On Mon, May 10, 2010 at 08:13:40PM +0200, Philippe R?tornaz wrote:
>> On mx31 the OTG host initialisation fail if you need to have
>> an ULPI transfert to initialize the PHY.
>>
>> In order to be able to communicate with the PHY a complete reset
>> of the usb host is needed. After the PHY initialization the host
>> usb configuration registers need to be rewritten to avoid a host
>> controller lockup.
>>
>> Signed-off-by: Philippe R?tornaz<philippe.retornaz@epfl.ch>
>> ---
>>   drivers/usb/host/ehci-mxc.c |   68 +++++++++++++++++++++++++++++++++++++++++++
>>   1 files changed, 68 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
>> index 544ccfd..39d28da 100644
>> --- a/drivers/usb/host/ehci-mxc.c
>> +++ b/drivers/usb/host/ehci-mxc.c
>> @@ -29,6 +29,11 @@
>>   #define PORTSC_OFFSET		0x184
>>   #define USBMODE_OFFSET		0x1a8
>>   #define USBMODE_CM_HOST		3
>> +#define USBCMD_OFFSET		0x140
>> +#define USBCMD_RS		(1<<  0)
>> +#define USBCMD_RST		(1<<  1)
>> +#define USBSTS_OFFSET		0x144
>> +#define USBSTS_HCH		(1<<  12)
>>
>>   struct ehci_mxc_priv {
>>   	struct clk *usbclk, *ahbclk;
>> @@ -120,6 +125,7 @@ static int ehci_mxc_drv_probe(struct platform_device *pdev)
>>   	int irq, ret, temp;
>>   	struct ehci_mxc_priv *priv;
>>   	struct device *dev =&pdev->dev;
>> +	int i;
>>
>>   	dev_info(&pdev->dev, "initializing i.MX USB Controller\n");
>>
>> @@ -204,6 +210,51 @@ static int ehci_mxc_drv_probe(struct platform_device *pdev)
>>   	if (ret<  0)
>>   		goto err_init;
>>
>> +	/* i.Mx31 OTG host has a bug, if you don't do a reset, then ULPI
>> +	 * transfert timeout. */
>
> s/transfert/transfers/
> Same below.
>
>> +	if (cpu_is_mx31()&&  pdev->id == 0) {
>> +		/* Wait for the controller to go idle */
>> +		for (i = 0; i<  10000; i++) {
>> +			if (readl(hcd->regs + USBSTS_OFFSET)&  USBSTS_HCH)
>> +				break;
>> +			udelay(1);
>> +		}
>> +		if (i == 10000) {
>> +			dev_err(dev, "Timeout while stopping USB controller\n");
>> +			goto err_init;
>> +		}
>> +
>> +		/* Stop the usb controller */
>> +		temp = readl(hcd->regs + USBCMD_OFFSET);
>> +		writel(temp&  (~USBCMD_RS), hcd->regs + USBCMD_OFFSET);
>> +
>> +		for (i = 0; i<  10000; i++) {
>> +			if (!(readl(hcd->regs + USBCMD_OFFSET)&  USBCMD_RS))
>> +				break;
>> +			udelay(1);
>> +		}
>> +
>> +		if (i == 10000) {
>> +			dev_err(dev, "Timeout while stopping USB controller\n");
>> +			goto err_init;
>> +		}
>> +
>> +		/* Reset the usb controller */
>> +		temp = readl(hcd->regs + USBCMD_OFFSET);
>> +		writel(temp | USBCMD_RST, hcd->regs + USBCMD_OFFSET);
>> +
>> +		for (i = 0; i<  10000; i++) {
>> +			if (!(readl(hcd->regs + USBCMD_OFFSET)&  USBCMD_RST))
>> +				break;
>> +			udelay(1);
>> +		}
>> +
>> +		if (i == 10000) {
>> +			dev_err(dev, "Timeout while reseting USB controller\n");
>> +			goto err_init;
>> +		}
>> +	}
>
> You add the resetting of the controller after setting up USBMODE/PORTSC
> setup. Wouldn't it be possible to change the order so that we do not
> have to do it twice?

It has to be tested, but if it works the code would then be clearer.

> Also, I think the whole reset functionality should be a seperate
> function. I can imagine we'll need it elsewhere or on different SoCs in
> which case the if clause above gets complicated.

I also think most of the things could be implemented as functions for a 
better readability (reset, and as Mark suggested a static inline 
function for the delay).

Val

>
> Sascha
>
>
>> +
>>   	/* Initialize the transceiver */
>>   	if (pdata->otg) {
>>   		pdata->otg->io_priv = hcd->regs + ULPI_VIEWPORT_OFFSET;
>> @@ -213,6 +264,23 @@ static int ehci_mxc_drv_probe(struct platform_device *pdev)
>>   			dev_err(dev, "unable to enable vbus on transceiver\n");
>>   	}
>>
>> +	/* i.Mx31 OTG host has a bug, if you do an ULPI transfert then the host
>> +	 * controller stay busy. Rewriting the register is enough to make it
>> +	 * working */
>> +	if (cpu_is_mx31()&&  pdev->id == 0) {
>> +		/* set USBMODE to host mode */
>> +		temp = readl(hcd->regs + USBMODE_OFFSET);
>> +		writel(temp | USBMODE_CM_HOST, hcd->regs + USBMODE_OFFSET);
>> +
>> +		/* set up the PORTSCx register */
>> +		writel(pdata->portsc, hcd->regs + PORTSC_OFFSET);
>> +
>> +		/* setup USBCONTROL. */
>> +		ret = mxc_initialize_usb_hw(pdev->id, pdata->flags);
>> +		if (ret<  0)
>> +			goto err_init;
>> +	}
>> +
>>   	priv->hcd = hcd;
>>   	platform_set_drvdata(pdev, priv);
>>
>> --
>> 1.6.3.3
>>
>>
>


-- 
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp at epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEB3494, Station 9, CH-1015 Lausanne

  reply	other threads:[~2010-05-11  9:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-10 18:13 [PATCH 0/1] mx31: Fix usb otg host initialisation Philippe Rétornaz
2010-05-10 18:13 ` [PATCH 1/1] ehci-mxc: Fix mx31 OTG " Philippe Rétornaz
2010-05-10 18:35   ` Daniel Mack
2010-05-11 11:06     ` Philippe Rétornaz
2010-05-10 18:58   ` Nguyen Dinh-R00091
2010-05-11  9:11     ` Valentin Longchamp
2010-05-11 11:06     ` Philippe Rétornaz
2010-05-11  6:39   ` Sascha Hauer
2010-05-11  9:03     ` Valentin Longchamp [this message]
2010-05-11 11:05     ` Philippe Rétornaz

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=4BE91D6D.5010207@epfl.ch \
    --to=valentin.longchamp@epfl.ch \
    --cc=linux-arm-kernel@lists.infradead.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.