Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-12-03 Thread Roger Quadros
On 12/02/2013 06:28 PM, David Laight wrote:
 From: Roger Quadros [mailto:rog...@ti.com]
 On 11/29/2013 03:17 PM, David Laight wrote:
 ...
 +  timeout = jiffies + msecs_to_jiffies(100);
 +  while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
 +   OMAP_UHH_SYSSTATUS_RESETDONE)) {
 +  cpu_relax();

 You mean use msleep(1) here instead of cpu_relax()?
 Shouldn't be a problem IMO, but can you please tell me why that is better
 as the reset seems to complete usually in the first iteration.
 
 If it doesn't finish in the first iteration you don't want to
 spin the cpu for 100ms.
 
 If it hasn't finished in the first millisecond, you probably expect
 it to actually time out - so you might as well look (say) every 10ms.
 

Understood now. Thanks.

cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-12-02 Thread Roger Quadros
Hi David,

On 11/29/2013 03:17 PM, David Laight wrote:
 From: Of Roger Quadros
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.
 ...
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -43,14 +43,18 @@
  /* UHH Register Set */
  #define OMAP_UHH_REVISION   (0x00)
  #define OMAP_UHH_SYSCONFIG  (0x10)
 -#define OMAP_UHH_SYSCONFIG_MIDLEMODE(1  12)
 +#define OMAP_UHH_SYSCONFIG_MIDLEMASK(3  12)
 +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT   (12)
 
 (tab/space issue)

Weird, original code seems to use a tab instead of space after #define. 

 
 Wouldn't it be clearer to define these in the opposite order with:
 +#define  OMAP_UHH_SYSCONFIG_MIDLEMASK(3  
 OMAP_UHH_SYSCONFIG_MIDLESHIFT)

Right.

 
 ... 
 +static void omap_usbhs_rev1_reset(struct device *dev)
 +{
 +struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +u32 reg;
 +unsigned long timeout;
 +
 +reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
 +
 +/* Soft Reset */
 +usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG,
 +reg | OMAP_UHH_SYSCONFIG_SOFTRESET);
 +
 +timeout = jiffies + msecs_to_jiffies(100);
 +while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
 + OMAP_UHH_SYSSTATUS_RESETDONE)) {
 +cpu_relax();

You mean use msleep(1) here instead of cpu_relax()?
Shouldn't be a problem IMO, but can you please tell me why that is better
as the reset seems to complete usually in the first iteration.

 +
 +if (time_after(jiffies, timeout)) {
 +dev_err(dev, Soft RESET operation timed out\n);
 +break;
 +}
 +}
 +
 +/* Set No-Standby */
 +reg = ~OMAP_UHH_SYSCONFIG_MIDLEMASK;
 +reg |= OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY
 + OMAP_UHH_SYSCONFIG_MIDLESHIFT;
 +
 +/* Set No-Idle */
 +reg = ~OMAP_UHH_SYSCONFIG_SIDLEMASK;
 +reg |= OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE
 + OMAP_UHH_SYSCONFIG_SIDLESHIFT;
 
 Why not pass in the mask and value and avoid replicating the
 entire function. I can't see any other significant differences,
 the udelay(2) won't be significant.

OK, I can pass the mask and value, but still there is a difference
in the way reset complete is checked between v1 and v2. But that
be in omap_usbhs_softreset() and the individual reset functions can be
replaced by a single omap_usbhs_set_sysconfig().

It seems the udelay() is not required for the USB Host module, so I'll
get rid of that.

 
 I'm not sure of the context this code runs in, but if the reset
 is likely to take a significant portion of the 100ms timeout
 period, why not just sleep for a few ms between status polls.

covered in the related code above.

cheers,
-roger

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-12-02 Thread Roger Quadros
+Benoit, Tony, Paul.

Hi Michael,

On 11/30/2013 06:48 AM, Michael Trimarchi wrote:
 Hi Roger
 
 On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.

 Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: sta...@vger.kernel.org # 3.10+
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  drivers/mfd/omap-usb-host.c | 115 
 +---
  1 file changed, 109 insertions(+), 6 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 142650f..d4bd464 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -43,14 +43,18 @@
  /* UHH Register Set */
  #defineOMAP_UHH_REVISION   (0x00)
  #defineOMAP_UHH_SYSCONFIG  (0x10)
 -#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1  12)
 +#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3  12)
 +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT  (12)
  #defineOMAP_UHH_SYSCONFIG_CACTIVITY(1  8)
 -#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT   (3)
  #defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1  2)
  #defineOMAP_UHH_SYSCONFIG_SOFTRESET(1  1)
  #defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1  0)

  #defineOMAP_UHH_SYSSTATUS  (0x14)
 +#define OMAP_UHH_SYSSTATUS_RESETDONE   (1  0)
 +
  #defineOMAP_UHH_HOSTCONFIG (0x40)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1  0)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS  (1  0)
 @@ -66,10 +70,10 @@
  #define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1  31)

  /* OMAP4-specific defines */
 -#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3  2)
 -#define OMAP4_UHH_SYSCONFIG_NOIDLE (1  2)
 -#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3  4)
 -#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1  4)
 +#define OMAP4_UHH_SYSCONFIG_MIDLEMASK  (3  2)
 +#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2)
 +#define OMAP4_UHH_SYSCONFIG_SIDLEMASK  (3  4)
 +#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4)
  #define OMAP4_UHH_SYSCONFIG_SOFTRESET  (1  0)

  #define OMAP4_P1_MODE_CLEAR(3  16)
 @@ -81,6 +85,12 @@

  #defineOMAP_UHH_DEBUG_CSR  (0x44)

 +/* MIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1)
 +
 +/* SIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1)
 +
  /* Values of UHH_REVISION - Note: these are not given in the TRM */
  #define OMAP_USBHS_REV10x0010  /* OMAP3 */
  #define OMAP_USBHS_REV20x50700100  /* OMAP4 */
 @@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct 
 usbhs_hcd_omap *omap,
 return reg;
  }

 
 I'm digging in the code but as I understand this should be done by
 omap_hwmod and
 i660 avoid reset of the ehci module. This is done by ocp_softreset?
 

It won't be done by omap_hwmod as we set HWMOD_INIT_NO_RESET flag in the hwmod 
data [1].

Question is do we do it in the driver of leave it to hwmod?

The other concern about i660 is in this comment [1]

/*
 * During system boot; If the hwmod framework resets the module
 * the module will have smart idle settings; which can lead to deadlock
 * (above Errata Id:i660); so, dont reset the module during boot;
 * Use HWMOD_INIT_NO_RESET.
 */

But if you look at the errata document [2], Advisory 1.108, it doesn't say that 
we can't be in smart-idle, but
only that we should put the module in force-idle, before cutting the module's 
functional clock. It also states
that the only way to recover from a lockup condition is to soft reset the 
module. So I'm not sure if the above comment
in the code is really valid. What if the lockup happens in the bootloader? In 
that case we will have to reset the module in
the kernel.

Doing the reset in probe does solve a problem for now i.e. eliminates 
dependency on bootloader.

[1] - 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c#n2024
[2] - http://www.ti.com/litv/pdf/sprz318e

 
 +static void omap_usbhs_rev1_reset(struct device *dev)
 +{
 +   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +   u32 

Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-12-02 Thread Roger Quadros
Michael,

On 11/29/2013 05:32 PM, Michael Trimarchi wrote:
 Hi Roger
 
 On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.

 
 Do you think that we need something similar of usb musb?
 I have seen the OTG_SYSCONFIG is touched in uboot and
 only readed in omap2430.c.

I'm not sure about musb. Maybe Sebastian/Felipe have better idea.
In general I believe that all modules must be reset by the kernel.

cheers,
-roger
 
 Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: sta...@vger.kernel.org # 3.10+
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  drivers/mfd/omap-usb-host.c | 115 
 +---
  1 file changed, 109 insertions(+), 6 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 142650f..d4bd464 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -43,14 +43,18 @@
  /* UHH Register Set */
  #defineOMAP_UHH_REVISION   (0x00)
  #defineOMAP_UHH_SYSCONFIG  (0x10)
 -#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1  12)
 +#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3  12)
 +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT  (12)
  #defineOMAP_UHH_SYSCONFIG_CACTIVITY(1  8)
 -#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT   (3)
  #defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1  2)
  #defineOMAP_UHH_SYSCONFIG_SOFTRESET(1  1)
  #defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1  0)

  #defineOMAP_UHH_SYSSTATUS  (0x14)
 +#define OMAP_UHH_SYSSTATUS_RESETDONE   (1  0)
 +
  #defineOMAP_UHH_HOSTCONFIG (0x40)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1  0)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS  (1  0)
 @@ -66,10 +70,10 @@
  #define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1  31)

  /* OMAP4-specific defines */
 -#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3  2)
 -#define OMAP4_UHH_SYSCONFIG_NOIDLE (1  2)
 -#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3  4)
 -#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1  4)
 +#define OMAP4_UHH_SYSCONFIG_MIDLEMASK  (3  2)
 +#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2)
 +#define OMAP4_UHH_SYSCONFIG_SIDLEMASK  (3  4)
 +#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4)
  #define OMAP4_UHH_SYSCONFIG_SOFTRESET  (1  0)

  #define OMAP4_P1_MODE_CLEAR(3  16)
 @@ -81,6 +85,12 @@

  #defineOMAP_UHH_DEBUG_CSR  (0x44)

 +/* MIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1)
 +
 +/* SIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1)
 +
  /* Values of UHH_REVISION - Note: these are not given in the TRM */
  #define OMAP_USBHS_REV10x0010  /* OMAP3 */
  #define OMAP_USBHS_REV20x50700100  /* OMAP4 */
 @@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct 
 usbhs_hcd_omap *omap,
 return reg;
  }

 +static void omap_usbhs_rev1_reset(struct device *dev)
 +{
 +   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +   u32 reg;
 +   unsigned long timeout;
 +
 +   reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
 +
 +   /* Soft Reset */
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG,
 +   reg | OMAP_UHH_SYSCONFIG_SOFTRESET);
 +
 +   timeout = jiffies + msecs_to_jiffies(100);
 +   while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
 +OMAP_UHH_SYSSTATUS_RESETDONE)) {
 +   cpu_relax();
 +
 +   if (time_after(jiffies, timeout)) {
 +   dev_err(dev, Soft RESET operation timed out\n);
 +   break;
 +   }
 +   }
 +
 +   /* Set No-Standby */
 +   reg = ~OMAP_UHH_SYSCONFIG_MIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY
 +OMAP_UHH_SYSCONFIG_MIDLESHIFT;
 +
 +   /* Set No-Idle */
 +   reg = ~OMAP_UHH_SYSCONFIG_SIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE
 +OMAP_UHH_SYSCONFIG_SIDLESHIFT;
 +
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG, reg);
 +}
 +
 +static void omap_usbhs_rev2_reset(struct device *dev)
 +{

Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-12-02 Thread Michael Trimarchi
Hi Roger

On Mon, Dec 2, 2013 at 10:39 AM, Roger Quadros rog...@ti.com wrote:
 +Benoit, Tony, Paul.

 Hi Michael,

 On 11/30/2013 06:48 AM, Michael Trimarchi wrote:
 Hi Roger

 On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.

 Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: sta...@vger.kernel.org # 3.10+
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  drivers/mfd/omap-usb-host.c | 115 
 +---
  1 file changed, 109 insertions(+), 6 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 142650f..d4bd464 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -43,14 +43,18 @@
  /* UHH Register Set */
  #defineOMAP_UHH_REVISION   (0x00)
  #defineOMAP_UHH_SYSCONFIG  (0x10)
 -#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1  12)
 +#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3  12)
 +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT  (12)
  #defineOMAP_UHH_SYSCONFIG_CACTIVITY(1  8)
 -#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT   (3)
  #defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1  2)
  #defineOMAP_UHH_SYSCONFIG_SOFTRESET(1  1)
  #defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1  0)

  #defineOMAP_UHH_SYSSTATUS  (0x14)
 +#define OMAP_UHH_SYSSTATUS_RESETDONE   (1  0)
 +
  #defineOMAP_UHH_HOSTCONFIG (0x40)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1  0)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS  (1  0)
 @@ -66,10 +70,10 @@
  #define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1  31)

  /* OMAP4-specific defines */
 -#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3  2)
 -#define OMAP4_UHH_SYSCONFIG_NOIDLE (1  2)
 -#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3  4)
 -#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1  4)
 +#define OMAP4_UHH_SYSCONFIG_MIDLEMASK  (3  2)
 +#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2)
 +#define OMAP4_UHH_SYSCONFIG_SIDLEMASK  (3  4)
 +#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4)
  #define OMAP4_UHH_SYSCONFIG_SOFTRESET  (1  0)

  #define OMAP4_P1_MODE_CLEAR(3  16)
 @@ -81,6 +85,12 @@

  #defineOMAP_UHH_DEBUG_CSR  (0x44)

 +/* MIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1)
 +
 +/* SIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1)
 +
  /* Values of UHH_REVISION - Note: these are not given in the TRM */
  #define OMAP_USBHS_REV10x0010  /* OMAP3 */
  #define OMAP_USBHS_REV20x50700100  /* OMAP4 */
 @@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct 
 usbhs_hcd_omap *omap,
 return reg;
  }


 I'm digging in the code but as I understand this should be done by
 omap_hwmod and
 i660 avoid reset of the ehci module. This is done by ocp_softreset?


 It won't be done by omap_hwmod as we set HWMOD_INIT_NO_RESET flag in the 
 hwmod data [1].

 Question is do we do it in the driver of leave it to hwmod?

 The other concern about i660 is in this comment [1]


I don't find any description of this errata for omap4. Is this errata valid?

My change was to remove the NO_INIT and add 2uS as you have done

 /*
  * During system oot; If the hwmod framework resets the module
  * the module will have smart idle settings; which can lead to 
 deadlock
  * (above Errata Id:i660); so, dont reset the module during boot;
  * Use HWMOD_INIT_NO_RESET.
  */

 But if you look at the errata document [2], Advisory 1.108, it doesn't say 
 that we can't be in smart-idle, but
 only that we should put the module in force-idle, before cutting the module's 
 functional clock. It also states
 that the only way to recover from a lockup condition is to soft reset the 
 module. So I'm not sure if the above comment
 in the code is really valid. What if the lockup happens in the bootloader? In 
 that case we will have to reset the module in
 the kernel.

Michael


 Doing the reset in probe does solve a problem for now i.e. eliminates 
 dependency on bootloader.

 [1] - 
 

Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-12-02 Thread Sebastian Andrzej Siewior
- sta...@vger.kernel.org since they probably don't care about this
  unless the patch is merged.

On 12/02/2013 10:41 AM, Roger Quadros wrote:
 Michael,
 
 On 11/29/2013 05:32 PM, Michael Trimarchi wrote:
 Hi Roger

 On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.


 Do you think that we need something similar of usb musb?
 I have seen the OTG_SYSCONFIG is touched in uboot and
 only readed in omap2430.c.
 
 I'm not sure about musb. Maybe Sebastian/Felipe have better idea.
 In general I believe that all modules must be reset by the kernel.
 

based on the code at the bottom it touches the first few register(s)
sysconfig. Isn't hwmod actually doing this idle stuff and resting the
device during boot?

 cheers,
 -roger


Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-12-02 Thread Roger Quadros
Michael,

On 12/02/2013 11:51 AM, Michael Trimarchi wrote:
 Hi Roger
 
 On Mon, Dec 2, 2013 at 10:39 AM, Roger Quadros rog...@ti.com wrote:
 +Benoit, Tony, Paul.

 Hi Michael,

 On 11/30/2013 06:48 AM, Michael Trimarchi wrote:
 Hi Roger

 On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.

 Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: sta...@vger.kernel.org # 3.10+
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  drivers/mfd/omap-usb-host.c | 115 
 +---
  1 file changed, 109 insertions(+), 6 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 142650f..d4bd464 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -43,14 +43,18 @@
  /* UHH Register Set */
  #defineOMAP_UHH_REVISION   (0x00)
  #defineOMAP_UHH_SYSCONFIG  (0x10)
 -#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1  12)
 +#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3  12)
 +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT  (12)
  #defineOMAP_UHH_SYSCONFIG_CACTIVITY(1  8)
 -#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT   (3)
  #defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1  2)
  #defineOMAP_UHH_SYSCONFIG_SOFTRESET(1  1)
  #defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1  0)

  #defineOMAP_UHH_SYSSTATUS  (0x14)
 +#define OMAP_UHH_SYSSTATUS_RESETDONE   (1  0)
 +
  #defineOMAP_UHH_HOSTCONFIG (0x40)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1  0)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS  (1  0)
 @@ -66,10 +70,10 @@
  #define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1  31)

  /* OMAP4-specific defines */
 -#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3  2)
 -#define OMAP4_UHH_SYSCONFIG_NOIDLE (1  2)
 -#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3  4)
 -#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1  4)
 +#define OMAP4_UHH_SYSCONFIG_MIDLEMASK  (3  2)
 +#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2)
 +#define OMAP4_UHH_SYSCONFIG_SIDLEMASK  (3  4)
 +#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4)
  #define OMAP4_UHH_SYSCONFIG_SOFTRESET  (1  0)

  #define OMAP4_P1_MODE_CLEAR(3  16)
 @@ -81,6 +85,12 @@

  #defineOMAP_UHH_DEBUG_CSR  (0x44)

 +/* MIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1)
 +
 +/* SIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1)
 +
  /* Values of UHH_REVISION - Note: these are not given in the TRM */
  #define OMAP_USBHS_REV10x0010  /* OMAP3 */
  #define OMAP_USBHS_REV20x50700100  /* OMAP4 */
 @@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct 
 usbhs_hcd_omap *omap,
 return reg;
  }


 I'm digging in the code but as I understand this should be done by
 omap_hwmod and
 i660 avoid reset of the ehci module. This is done by ocp_softreset?


 It won't be done by omap_hwmod as we set HWMOD_INIT_NO_RESET flag in the 
 hwmod data [1].

 Question is do we do it in the driver of leave it to hwmod?

 The other concern about i660 is in this comment [1]

 
 I don't find any description of this errata for omap4. Is this errata valid?

I can't say for sure. You might have to try it out without those flags and see 
if it works
reliably.

 
 My change was to remove the NO_INIT and add 2uS as you have done

The 2uS delay that I added was my mistake and I don't think it is required.
Just removing HWMOD_INIT_NO_RESET should work.

cheers,
-roger

 
 /*
  * During system oot; If the hwmod framework resets the module
  * the module will have smart idle settings; which can lead to 
 deadlock
  * (above Errata Id:i660); so, dont reset the module during boot;
  * Use HWMOD_INIT_NO_RESET.
  */

 But if you look at the errata document [2], Advisory 1.108, it doesn't say 
 that we can't be in smart-idle, but
 only that we should put the module in force-idle, before cutting the 
 module's functional clock. It also states
 that the only way to recover from a lockup condition is to soft reset the 
 module. So I'm not sure if the 

Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-12-02 Thread Roger Quadros
On 12/02/2013 02:01 PM, Sebastian Andrzej Siewior wrote:
 - sta...@vger.kernel.org since they probably don't care about this
   unless the patch is merged.
 
 On 12/02/2013 10:41 AM, Roger Quadros wrote:
 Michael,

 On 11/29/2013 05:32 PM, Michael Trimarchi wrote:
 Hi Roger

 On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.


 Do you think that we need something similar of usb musb?
 I have seen the OTG_SYSCONFIG is touched in uboot and
 only readed in omap2430.c.

 I'm not sure about musb. Maybe Sebastian/Felipe have better idea.
 In general I believe that all modules must be reset by the kernel.

 
 based on the code at the bottom it touches the first few register(s)
 sysconfig. Isn't hwmod actually doing this idle stuff and resting the
 device during boot?
 

You are right. The musb hwmod data doesn't have the HWMOD_INIT_NO_RESET
flag, so hwmod should reset it during boot.

Maybe I too should just remove HWMOD_INIT_NO_RESET flag from the USB Host
hwmod data, then we don't need to change this driver at all.

Benoit, Tony any comments?

cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-12-02 Thread Sebastian Andrzej Siewior
On 12/02/2013 01:12 PM, Roger Quadros wrote:
 You are right. The musb hwmod data doesn't have the HWMOD_INIT_NO_RESET
 flag, so hwmod should reset it during boot.
 
 Maybe I too should just remove HWMOD_INIT_NO_RESET flag from the USB Host
 hwmod data, then we don't need to change this driver at all.
 
 Benoit, Tony any comments?

Almost two years ago in commit de231388 (ARM: OMAP: USB: EHCI and OHCI
hwmod structures for OMAP3) the don't reset flag has been added by
Keshava.

It refers to Errata Id:i660 why it is required. Once you figured what
why it has been added you could have an idea if it is okay to remove it
and if the reset you do here might lead to it (I dunno).

 
 cheers,
 -roger

Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-12-02 Thread Roger Quadros
On 12/02/2013 03:04 PM, Sebastian Andrzej Siewior wrote:
 On 12/02/2013 01:12 PM, Roger Quadros wrote:
 You are right. The musb hwmod data doesn't have the HWMOD_INIT_NO_RESET
 flag, so hwmod should reset it during boot.

 Maybe I too should just remove HWMOD_INIT_NO_RESET flag from the USB Host
 hwmod data, then we don't need to change this driver at all.

 Benoit, Tony any comments?
 
 Almost two years ago in commit de231388 (ARM: OMAP: USB: EHCI and OHCI
 hwmod structures for OMAP3) the don't reset flag has been added by
 Keshava.
 
 It refers to Errata Id:i660 why it is required. Once you figured what
 why it has been added you could have an idea if it is okay to remove it
 and if the reset you do here might lead to it (I dunno).
 

Keshava no longer works @TI. I have no other means to check why it was added
other than doing dome tests and making sure nothing breaks if we remove it.

So far, things are going fine for about 50 or so boots divided between OMAP3 
and 4
platforms. If more people can test and give feedback it'd be great.

For the present situation, omap4 panda USB host doesn't work without the reset
with u-boot v2013.10.

cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-12-02 Thread Sebastian Andrzej Siewior
On 12/02/2013 02:35 PM, Roger Quadros wrote:
 It refers to Errata Id:i660 why it is required. Once you figured what
 why it has been added you could have an idea if it is okay to remove it
 and if the reset you do here might lead to it (I dunno).

 
 Keshava no longer works @TI. I have no other means to check why it was added
 other than doing dome tests and making sure nothing breaks if we remove it.
 
 So far, things are going fine for about 50 or so boots divided between OMAP3 
 and 4
 platforms. If more people can test and give feedback it'd be great.

Hmm. Can't you lookup the errata he revers to?

 cheers,
 -roger
 

Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-12-02 Thread Roger Quadros
On 12/02/2013 03:39 PM, Sebastian Andrzej Siewior wrote:
 On 12/02/2013 02:35 PM, Roger Quadros wrote:
 It refers to Errata Id:i660 why it is required. Once you figured what
 why it has been added you could have an idea if it is okay to remove it
 and if the reset you do here might lead to it (I dunno).


 Keshava no longer works @TI. I have no other means to check why it was added
 other than doing dome tests and making sure nothing breaks if we remove it.

 So far, things are going fine for about 50 or so boots divided between OMAP3 
 and 4
 platforms. If more people can test and give feedback it'd be great.
 
 Hmm. Can't you lookup the errata he revers to?
 

Sure, but it was not making sense why RESET was avoided.
It doesn't say anything about not using RESET. In fact it says that RESET _is_ 
the
recovery procedure.

Pasting the errata description below for easy reference.

Errata id: i660
DESCRIPTION
In the following configuration :
• USBHOST module is set to smart-idle mode
• PRCM asserts idle_req to the USBHOST module. (This typically happens when the 
system is going to
a low power mode : all ports have been suspended, the master part of the 
USBHOST module has
entered the standby state, and SW has cut the functional clocks.)
• an USBHOST interrupt occurs before the module is able to answer idle_ack, 
typically a remote wakeup
IRQ.
Then the USB HOST module will enter a deadlock situation where it is no more 
accessible nor functional.
The only way to recover will be to perform a software reset of the module.

WORKAROUND
The best workaround consists in switching the module to force idle mode right 
before cutting the
module's FCLK.
• the bus has reached the suspend state.
• write SYSCONFIG:Idlemode= ForceIdle and read it back to ensure the write has 
been taken into
account in case of posted writes.
• cut the FCLK
• Idle_req will be asserted and idle_ack answered within one L3 clock cycle.
Upon resume or remote wakeup, switch back the module to smart-idle.
This workaround reduces the failure window to only one L3 clock cycle. The 
probability for an interrupt to
fire at this exact time is considered extremely low, and the case has never 
been hit on board.

Based on this, I don't see anything wrong in Resetting the module at probe or 
at boot.

cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-12-02 Thread Sebastian Andrzej Siewior
On 12/02/2013 02:44 PM, Roger Quadros wrote:
 Errata id: i660
 DESCRIPTION
 In the following configuration :
 • USBHOST module is set to smart-idle mode
 • PRCM asserts idle_req to the USBHOST module. (This typically happens when 
 the system is going to
 a low power mode : all ports have been suspended, the master part of the 
 USBHOST module has
 entered the standby state, and SW has cut the functional clocks.)
 • an USBHOST interrupt occurs before the module is able to answer idle_ack, 
 typically a remote wakeup
 IRQ.
 Then the USB HOST module will enter a deadlock situation where it is no more 
 accessible nor functional.
 The only way to recover will be to perform a software reset of the module.
 
 WORKAROUND
 The best workaround consists in switching the module to force idle mode right 
 before cutting the
 module's FCLK.
 • the bus has reached the suspend state.
 • write SYSCONFIG:Idlemode= ForceIdle and read it back to ensure the write 
 has been taken into
 account in case of posted writes.
 • cut the FCLK
 • Idle_req will be asserted and idle_ack answered within one L3 clock cycle.
 Upon resume or remote wakeup, switch back the module to smart-idle.
 This workaround reduces the failure window to only one L3 clock cycle. The 
 probability for an interrupt to
 fire at this exact time is considered extremely low, and the case has never 
 been hit on board.
 
 Based on this, I don't see anything wrong in Resetting the module at probe or 
 at boot.

If u-boot configured USB into something not smart-idle and the reset
would bring it back then the reset should remain.
If you could tell hwmod not use smart-idle nor smart-standby and you
make sure that the suspend code manually puts the device into suspend
via forceidle then I think could get rid of the do-not-reset-thingy.

 
 cheers,
 -roger
 

Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-12-02 Thread Paul Walmsley
On Mon, 2 Dec 2013, Roger Quadros wrote:

 It won't be done by omap_hwmod as we set HWMOD_INIT_NO_RESET flag in the 
 hwmod data [1].
 
 Question is do we do it in the driver of leave it to hwmod?

It should be done by hwmod (or more broadly, some OMAP bus code).  That 
way the device can be brought to a known state even if there's no driver 
present (e.g., if the driver was built as a module).

 The other concern about i660 is in this comment [1]
 
   /*
* During system boot; If the hwmod framework resets the module
* the module will have smart idle settings; which can lead to deadlock
* (above Errata Id:i660); so, dont reset the module during boot;
* Use HWMOD_INIT_NO_RESET.
*/
 
 But if you look at the errata document [2], Advisory 1.108, it doesn't 
 say that we can't be in smart-idle, but only that we should put the 
 module in force-idle, before cutting the module's functional clock.

Yes, that looks to be correct.  There shouldn't be any problem with the 
module being in smart-idle mode if the PRCM doesn't try to put it into a 
low-power mode.  It already has the HWMOD_SWSUP_SIDLE flag set, so seems 
to me it should work fine without HWMOD_INIT_NO_RESET, if i660 is the only 
issue.

Most of the IP blocks that are marked with HWMOD_INIT_NO_RESET are only 
that way due to laziness, or lack of time, etc., and should be closely 
reviewed.


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-12-02 Thread Roger Quadros
On 12/02/2013 04:03 PM, Sebastian Andrzej Siewior wrote:
 On 12/02/2013 02:44 PM, Roger Quadros wrote:
 Errata id: i660
 DESCRIPTION
 In the following configuration :
 • USBHOST module is set to smart-idle mode
 • PRCM asserts idle_req to the USBHOST module. (This typically happens when 
 the system is going to
 a low power mode : all ports have been suspended, the master part of the 
 USBHOST module has
 entered the standby state, and SW has cut the functional clocks.)
 • an USBHOST interrupt occurs before the module is able to answer idle_ack, 
 typically a remote wakeup
 IRQ.
 Then the USB HOST module will enter a deadlock situation where it is no more 
 accessible nor functional.
 The only way to recover will be to perform a software reset of the module.

 WORKAROUND
 The best workaround consists in switching the module to force idle mode 
 right before cutting the
 module's FCLK.
 • the bus has reached the suspend state.
 • write SYSCONFIG:Idlemode= ForceIdle and read it back to ensure the write 
 has been taken into
 account in case of posted writes.
 • cut the FCLK
 • Idle_req will be asserted and idle_ack answered within one L3 clock cycle.
 Upon resume or remote wakeup, switch back the module to smart-idle.
 This workaround reduces the failure window to only one L3 clock cycle. The 
 probability for an interrupt to
 fire at this exact time is considered extremely low, and the case has never 
 been hit on board.

 Based on this, I don't see anything wrong in Resetting the module at probe 
 or at boot.
 
 If u-boot configured USB into something not smart-idle and the reset
 would bring it back then the reset should remain.
 If you could tell hwmod not use smart-idle nor smart-standby and you
 make sure that the suspend code manually puts the device into suspend
 via forceidle then I think could get rid of the do-not-reset-thingy.
 

We are already telling hwmod to not use smart-idle or smart-standby.
So the device is always put in no-idle,no-standby during resume and 
force-idle,force-standby
during suspend.

I'll send a new patch to remove do-not-reset flag from hwmod data and then we
don't need this patch.

cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-12-02 Thread David Laight
 From: Roger Quadros [mailto:rog...@ti.com]
 On 11/29/2013 03:17 PM, David Laight wrote:
...
  +  timeout = jiffies + msecs_to_jiffies(100);
  +  while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
  +   OMAP_UHH_SYSSTATUS_RESETDONE)) {
  +  cpu_relax();
 
 You mean use msleep(1) here instead of cpu_relax()?
 Shouldn't be a problem IMO, but can you please tell me why that is better
 as the reset seems to complete usually in the first iteration.

If it doesn't finish in the first iteration you don't want to
spin the cpu for 100ms.

If it hasn't finished in the first millisecond, you probably expect
it to actually time out - so you might as well look (say) every 10ms.

David



--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-11-30 Thread Michael Trimarchi
Hi

On Sat, Nov 30, 2013 at 6:10 AM, Michael Trimarchi
mich...@amarulasolutions.com wrote:
 Hi

 On Sat, Nov 30, 2013 at 5:48 AM, Michael Trimarchi
 mich...@amarulasolutions.com wrote:
 Hi Roger

 On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.

 Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: sta...@vger.kernel.org # 3.10+
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  drivers/mfd/omap-usb-host.c | 115 
 +---
  1 file changed, 109 insertions(+), 6 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 142650f..d4bd464 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -43,14 +43,18 @@
  /* UHH Register Set */
  #defineOMAP_UHH_REVISION   (0x00)
  #defineOMAP_UHH_SYSCONFIG  (0x10)
 -#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1  12)
 +#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3  12)
 +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT  (12)
  #defineOMAP_UHH_SYSCONFIG_CACTIVITY(1  8)
 -#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT   (3)
  #defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1  2)
  #defineOMAP_UHH_SYSCONFIG_SOFTRESET(1  1)
  #defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1  0)

  #defineOMAP_UHH_SYSSTATUS  (0x14)
 +#define OMAP_UHH_SYSSTATUS_RESETDONE   (1  0)
 +
  #defineOMAP_UHH_HOSTCONFIG (0x40)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1  0)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS  (1  0)
 @@ -66,10 +70,10 @@
  #define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1  31)

  /* OMAP4-specific defines */
 -#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3  2)
 -#define OMAP4_UHH_SYSCONFIG_NOIDLE (1  2)
 -#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3  4)
 -#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1  4)
 +#define OMAP4_UHH_SYSCONFIG_MIDLEMASK  (3  2)
 +#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2)
 +#define OMAP4_UHH_SYSCONFIG_SIDLEMASK  (3  4)
 +#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4)
  #define OMAP4_UHH_SYSCONFIG_SOFTRESET  (1  0)

  #define OMAP4_P1_MODE_CLEAR(3  16)
 @@ -81,6 +85,12 @@

  #defineOMAP_UHH_DEBUG_CSR  (0x44)

 +/* MIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1)
 +
 +/* SIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1)
 +
  /* Values of UHH_REVISION - Note: these are not given in the TRM */
  #define OMAP_USBHS_REV10x0010  /* OMAP3 */
  #define OMAP_USBHS_REV20x50700100  /* OMAP4 */
 @@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct 
 usbhs_hcd_omap *omap,
 return reg;
  }


 I'm digging in the code but as I understand this should be done by
 omap_hwmod and
 i660 avoid reset of the ehci module. This is done by ocp_softreset?


 +static void omap_usbhs_rev1_reset(struct device *dev)
 +{
 +   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +   u32 reg;
 +   unsigned long timeout;
 +
 +   reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
 +
 +   /* Soft Reset */
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG,
 +   reg | OMAP_UHH_SYSCONFIG_SOFTRESET);
 +
 +   timeout = jiffies + msecs_to_jiffies(100);
 +   while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
 +OMAP_UHH_SYSSTATUS_RESETDONE)) {
 +   cpu_relax();
 +
 +   if (time_after(jiffies, timeout)) {
 +   dev_err(dev, Soft RESET operation timed out\n);
 +   break;
 +   }
 +   }
 +
 +   /* Set No-Standby */
 +   reg = ~OMAP_UHH_SYSCONFIG_MIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY
 +OMAP_UHH_SYSCONFIG_MIDLESHIFT;
 +
 +   /* Set No-Idle */
 +   reg = ~OMAP_UHH_SYSCONFIG_SIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE
 +OMAP_UHH_SYSCONFIG_SIDLESHIFT;
 +
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG, reg);
 +}
 +
 +static void omap_usbhs_rev2_reset(struct device *dev)
 +{
 +   

RE: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-11-29 Thread David Laight
 From: Of Roger Quadros
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.
...
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -43,14 +43,18 @@
  /* UHH Register Set */
  #define  OMAP_UHH_REVISION   (0x00)
  #define  OMAP_UHH_SYSCONFIG  (0x10)
 -#define  OMAP_UHH_SYSCONFIG_MIDLEMODE(1  12)
 +#define  OMAP_UHH_SYSCONFIG_MIDLEMASK(3  12)
 +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT(12)

(tab/space issue)

Wouldn't it be clearer to define these in the opposite order with:
+#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3  
OMAP_UHH_SYSCONFIG_MIDLESHIFT)

... 
 +static void omap_usbhs_rev1_reset(struct device *dev)
 +{
 + struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 + u32 reg;
 + unsigned long timeout;
 +
 + reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
 +
 + /* Soft Reset */
 + usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG,
 + reg | OMAP_UHH_SYSCONFIG_SOFTRESET);
 +
 + timeout = jiffies + msecs_to_jiffies(100);
 + while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
 +  OMAP_UHH_SYSSTATUS_RESETDONE)) {
 + cpu_relax();
 +
 + if (time_after(jiffies, timeout)) {
 + dev_err(dev, Soft RESET operation timed out\n);
 + break;
 + }
 + }
 +
 + /* Set No-Standby */
 + reg = ~OMAP_UHH_SYSCONFIG_MIDLEMASK;
 + reg |= OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY
 +  OMAP_UHH_SYSCONFIG_MIDLESHIFT;
 +
 + /* Set No-Idle */
 + reg = ~OMAP_UHH_SYSCONFIG_SIDLEMASK;
 + reg |= OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE
 +  OMAP_UHH_SYSCONFIG_SIDLESHIFT;

Why not pass in the mask and value and avoid replicating the
entire function. I can't see any other significant differences,
the udelay(2) won't be significant.

I'm not sure of the context this code runs in, but if the reset
is likely to take a significant portion of the 100ms timeout
period, why not just sleep for a few ms between status polls.

David




--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-11-29 Thread Michael Trimarchi
Hi Roger

On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.


Do you think that we need something similar of usb musb?
I have seen the OTG_SYSCONFIG is touched in uboot and
only readed in omap2430.c.

Michael

 Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: sta...@vger.kernel.org # 3.10+
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  drivers/mfd/omap-usb-host.c | 115 
 +---
  1 file changed, 109 insertions(+), 6 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 142650f..d4bd464 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -43,14 +43,18 @@
  /* UHH Register Set */
  #defineOMAP_UHH_REVISION   (0x00)
  #defineOMAP_UHH_SYSCONFIG  (0x10)
 -#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1  12)
 +#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3  12)
 +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT  (12)
  #defineOMAP_UHH_SYSCONFIG_CACTIVITY(1  8)
 -#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT   (3)
  #defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1  2)
  #defineOMAP_UHH_SYSCONFIG_SOFTRESET(1  1)
  #defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1  0)

  #defineOMAP_UHH_SYSSTATUS  (0x14)
 +#define OMAP_UHH_SYSSTATUS_RESETDONE   (1  0)
 +
  #defineOMAP_UHH_HOSTCONFIG (0x40)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1  0)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS  (1  0)
 @@ -66,10 +70,10 @@
  #define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1  31)

  /* OMAP4-specific defines */
 -#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3  2)
 -#define OMAP4_UHH_SYSCONFIG_NOIDLE (1  2)
 -#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3  4)
 -#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1  4)
 +#define OMAP4_UHH_SYSCONFIG_MIDLEMASK  (3  2)
 +#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2)
 +#define OMAP4_UHH_SYSCONFIG_SIDLEMASK  (3  4)
 +#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4)
  #define OMAP4_UHH_SYSCONFIG_SOFTRESET  (1  0)

  #define OMAP4_P1_MODE_CLEAR(3  16)
 @@ -81,6 +85,12 @@

  #defineOMAP_UHH_DEBUG_CSR  (0x44)

 +/* MIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1)
 +
 +/* SIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1)
 +
  /* Values of UHH_REVISION - Note: these are not given in the TRM */
  #define OMAP_USBHS_REV10x0010  /* OMAP3 */
  #define OMAP_USBHS_REV20x50700100  /* OMAP4 */
 @@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct 
 usbhs_hcd_omap *omap,
 return reg;
  }

 +static void omap_usbhs_rev1_reset(struct device *dev)
 +{
 +   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +   u32 reg;
 +   unsigned long timeout;
 +
 +   reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
 +
 +   /* Soft Reset */
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG,
 +   reg | OMAP_UHH_SYSCONFIG_SOFTRESET);
 +
 +   timeout = jiffies + msecs_to_jiffies(100);
 +   while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
 +OMAP_UHH_SYSSTATUS_RESETDONE)) {
 +   cpu_relax();
 +
 +   if (time_after(jiffies, timeout)) {
 +   dev_err(dev, Soft RESET operation timed out\n);
 +   break;
 +   }
 +   }
 +
 +   /* Set No-Standby */
 +   reg = ~OMAP_UHH_SYSCONFIG_MIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY
 +OMAP_UHH_SYSCONFIG_MIDLESHIFT;
 +
 +   /* Set No-Idle */
 +   reg = ~OMAP_UHH_SYSCONFIG_SIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE
 +OMAP_UHH_SYSCONFIG_SIDLESHIFT;
 +
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG, reg);
 +}
 +
 +static void omap_usbhs_rev2_reset(struct device *dev)
 +{
 +   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +   u32 reg;
 +   unsigned long timeout;
 +
 +   reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
 +
 +   /* Soft Reset */
 + 

Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-11-29 Thread Michael Trimarchi
Hi Roger

On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.

 Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: sta...@vger.kernel.org # 3.10+
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  drivers/mfd/omap-usb-host.c | 115 
 +---
  1 file changed, 109 insertions(+), 6 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 142650f..d4bd464 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -43,14 +43,18 @@
  /* UHH Register Set */
  #defineOMAP_UHH_REVISION   (0x00)
  #defineOMAP_UHH_SYSCONFIG  (0x10)
 -#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1  12)
 +#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3  12)
 +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT  (12)
  #defineOMAP_UHH_SYSCONFIG_CACTIVITY(1  8)
 -#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT   (3)
  #defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1  2)
  #defineOMAP_UHH_SYSCONFIG_SOFTRESET(1  1)
  #defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1  0)

  #defineOMAP_UHH_SYSSTATUS  (0x14)
 +#define OMAP_UHH_SYSSTATUS_RESETDONE   (1  0)
 +
  #defineOMAP_UHH_HOSTCONFIG (0x40)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1  0)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS  (1  0)
 @@ -66,10 +70,10 @@
  #define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1  31)

  /* OMAP4-specific defines */
 -#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3  2)
 -#define OMAP4_UHH_SYSCONFIG_NOIDLE (1  2)
 -#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3  4)
 -#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1  4)
 +#define OMAP4_UHH_SYSCONFIG_MIDLEMASK  (3  2)
 +#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2)
 +#define OMAP4_UHH_SYSCONFIG_SIDLEMASK  (3  4)
 +#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4)
  #define OMAP4_UHH_SYSCONFIG_SOFTRESET  (1  0)

  #define OMAP4_P1_MODE_CLEAR(3  16)
 @@ -81,6 +85,12 @@

  #defineOMAP_UHH_DEBUG_CSR  (0x44)

 +/* MIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1)
 +
 +/* SIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1)
 +
  /* Values of UHH_REVISION - Note: these are not given in the TRM */
  #define OMAP_USBHS_REV10x0010  /* OMAP3 */
  #define OMAP_USBHS_REV20x50700100  /* OMAP4 */
 @@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct 
 usbhs_hcd_omap *omap,
 return reg;
  }


I'm digging in the code but as I understand this should be done by
omap_hwmod and
i660 avoid reset of the ehci module. This is done by ocp_softreset?


 +static void omap_usbhs_rev1_reset(struct device *dev)
 +{
 +   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +   u32 reg;
 +   unsigned long timeout;
 +
 +   reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
 +
 +   /* Soft Reset */
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG,
 +   reg | OMAP_UHH_SYSCONFIG_SOFTRESET);
 +
 +   timeout = jiffies + msecs_to_jiffies(100);
 +   while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
 +OMAP_UHH_SYSSTATUS_RESETDONE)) {
 +   cpu_relax();
 +
 +   if (time_after(jiffies, timeout)) {
 +   dev_err(dev, Soft RESET operation timed out\n);
 +   break;
 +   }
 +   }
 +
 +   /* Set No-Standby */
 +   reg = ~OMAP_UHH_SYSCONFIG_MIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY
 +OMAP_UHH_SYSCONFIG_MIDLESHIFT;
 +
 +   /* Set No-Idle */
 +   reg = ~OMAP_UHH_SYSCONFIG_SIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE
 +OMAP_UHH_SYSCONFIG_SIDLESHIFT;
 +
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG, reg);
 +}
 +
 +static void omap_usbhs_rev2_reset(struct device *dev)
 +{
 +   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +   u32 reg;
 +   unsigned long timeout;
 +
 +   reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
 +
 +   /* Soft Reset 

Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-11-29 Thread Michael Trimarchi
Hi

On Sat, Nov 30, 2013 at 5:48 AM, Michael Trimarchi
mich...@amarulasolutions.com wrote:
 Hi Roger

 On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.

 Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: sta...@vger.kernel.org # 3.10+
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  drivers/mfd/omap-usb-host.c | 115 
 +---
  1 file changed, 109 insertions(+), 6 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 142650f..d4bd464 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -43,14 +43,18 @@
  /* UHH Register Set */
  #defineOMAP_UHH_REVISION   (0x00)
  #defineOMAP_UHH_SYSCONFIG  (0x10)
 -#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1  12)
 +#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3  12)
 +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT  (12)
  #defineOMAP_UHH_SYSCONFIG_CACTIVITY(1  8)
 -#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT   (3)
  #defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1  2)
  #defineOMAP_UHH_SYSCONFIG_SOFTRESET(1  1)
  #defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1  0)

  #defineOMAP_UHH_SYSSTATUS  (0x14)
 +#define OMAP_UHH_SYSSTATUS_RESETDONE   (1  0)
 +
  #defineOMAP_UHH_HOSTCONFIG (0x40)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1  0)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS  (1  0)
 @@ -66,10 +70,10 @@
  #define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1  31)

  /* OMAP4-specific defines */
 -#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3  2)
 -#define OMAP4_UHH_SYSCONFIG_NOIDLE (1  2)
 -#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3  4)
 -#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1  4)
 +#define OMAP4_UHH_SYSCONFIG_MIDLEMASK  (3  2)
 +#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2)
 +#define OMAP4_UHH_SYSCONFIG_SIDLEMASK  (3  4)
 +#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4)
  #define OMAP4_UHH_SYSCONFIG_SOFTRESET  (1  0)

  #define OMAP4_P1_MODE_CLEAR(3  16)
 @@ -81,6 +85,12 @@

  #defineOMAP_UHH_DEBUG_CSR  (0x44)

 +/* MIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1)
 +
 +/* SIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1)
 +
  /* Values of UHH_REVISION - Note: these are not given in the TRM */
  #define OMAP_USBHS_REV10x0010  /* OMAP3 */
  #define OMAP_USBHS_REV20x50700100  /* OMAP4 */
 @@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct 
 usbhs_hcd_omap *omap,
 return reg;
  }


 I'm digging in the code but as I understand this should be done by
 omap_hwmod and
 i660 avoid reset of the ehci module. This is done by ocp_softreset?


 +static void omap_usbhs_rev1_reset(struct device *dev)
 +{
 +   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +   u32 reg;
 +   unsigned long timeout;
 +
 +   reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
 +
 +   /* Soft Reset */
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG,
 +   reg | OMAP_UHH_SYSCONFIG_SOFTRESET);
 +
 +   timeout = jiffies + msecs_to_jiffies(100);
 +   while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
 +OMAP_UHH_SYSSTATUS_RESETDONE)) {
 +   cpu_relax();
 +
 +   if (time_after(jiffies, timeout)) {
 +   dev_err(dev, Soft RESET operation timed out\n);
 +   break;
 +   }
 +   }
 +
 +   /* Set No-Standby */
 +   reg = ~OMAP_UHH_SYSCONFIG_MIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY
 +OMAP_UHH_SYSCONFIG_MIDLESHIFT;
 +
 +   /* Set No-Idle */
 +   reg = ~OMAP_UHH_SYSCONFIG_SIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE
 +OMAP_UHH_SYSCONFIG_SIDLESHIFT;
 +
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG, reg);
 +}
 +
 +static void omap_usbhs_rev2_reset(struct device *dev)
 +{
 +   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +   u32 reg;
 +   unsigned long