Message ID | 1242412851-16606-9-git-send-email-khilman@deeprootsystems.com (mailing list archive) |
---|---|
State | Awaiting Upstream, archived |
Headers | show |
On Fri, May 15, 2009 at 11:40:48AM -0700, Kevin Hilman wrote: > Otherwise, bootloaders may leave MUSB in a state which prevents > retention. Hmm, so what happens if a boot loader has touched this MUSB thing, but the kernel which is being run doesn't have CONFIG_USB_MUSB_SOC enabled? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Russell King - ARM Linux <linux@arm.linux.org.uk> writes: > On Fri, May 15, 2009 at 11:40:48AM -0700, Kevin Hilman wrote: >> Otherwise, bootloaders may leave MUSB in a state which prevents >> retention. > > Hmm, so what happens if a boot loader has touched this MUSB thing, but > the kernel which is being run doesn't have CONFIG_USB_MUSB_SOC enabled? Then the OMAP will not be able to hit retention. That Makefile change happened after this series was initially made. I think we should change the Makefile back to always compile usb-musb.c and move the #ifdef CONFIG_USB_MUSB_SOC into usb-musb.c Tony, any objections? Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Kevin Hilman <khilman@deeprootsystems.com> [090518 07:50]: > Russell King - ARM Linux <linux@arm.linux.org.uk> writes: > > > On Fri, May 15, 2009 at 11:40:48AM -0700, Kevin Hilman wrote: > >> Otherwise, bootloaders may leave MUSB in a state which prevents > >> retention. > > > > Hmm, so what happens if a boot loader has touched this MUSB thing, but > > the kernel which is being run doesn't have CONFIG_USB_MUSB_SOC enabled? > > Then the OMAP will not be able to hit retention. > > That Makefile change happened after this series was initially made. > I think we should change the Makefile back to always compile usb-musb.c > and move the #ifdef CONFIG_USB_MUSB_SOC into usb-musb.c > > Tony, any objections? Sounds good to me, I like patches that make things behave in a predictable way. We already have enough of these mysterious problems where "the same kernel behaves in a different way on my board" when some registers are only tweaked in the bootloader. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c index 215d463..57e857e 100644 --- a/arch/arm/mach-omap2/usb-musb.c +++ b/arch/arm/mach-omap2/usb-musb.c @@ -31,6 +31,8 @@ #include <mach/mux.h> #include <mach/usb.h> +#define OTG_SYSCONFIG (OMAP34XX_HSUSB_OTG_BASE + 0x404) + static struct resource musb_resources[] = { [0] = { /* start and end set dynamically */ .flags = IORESOURCE_MEM, @@ -183,4 +185,8 @@ void __init usb_musb_init(void) printk(KERN_ERR "Unable to register HS-USB (MUSB) device\n"); return; } + + /* Ensure force-idle mode for OTG controller */ + if (cpu_is_omap34xx()) + omap_writel(0, OTG_SYSCONFIG); }