diff mbox

[08/11] OMAP3: PM: Ensure MUSB block can idle when driver not loaded

Message ID 1242412851-16606-9-git-send-email-khilman@deeprootsystems.com (mailing list archive)
State Awaiting Upstream, archived
Headers show

Commit Message

Kevin Hilman May 15, 2009, 6:40 p.m. UTC
From: Peter 'p2' De Schrijver <peter.de-schrijver@nokia.com>

Otherwise, bootloaders may leave MUSB in a state which prevents
retention.

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-omap2/usb-musb.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

Comments

Russell King - ARM Linux May 18, 2009, 1:16 p.m. UTC | #1
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
Kevin Hilman May 18, 2009, 2:50 p.m. UTC | #2
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
Tony Lindgren May 18, 2009, 3:04 p.m. UTC | #3
* 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 mbox

Patch

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);
 }