lkml.org 
[lkml]   [2013]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
Date
From
> 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:
+#define OMAP_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






\
 
 \ /
  Last update: 2013-11-29 15:01    [W:0.106 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site