Re: [PATCH] usb: disable OTG AUTOIDLE only with omap3430
On Wed, Aug 26, 2009 at 2:47 PM, Gupta, Ajay Kumar wrote: >> -Original Message- >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- >> ow...@vger.kernel.org] On Behalf Of Woodruff, Richard >> Sent: Tuesday, May 19, 2009 12:53 AM >> To: Niilo Minkkinen; linux-...@vger.kernel.org >> Cc: linux-omap@vger.kernel.org; t...@atomide.com >> Subject: RE: [PATCH] usb: disable OTG AUTOIDLE only with omap3430 >> >> >> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >> > ow...@vger.kernel.org] On Behalf Of Niilo Minkkinen >> > Sent: Monday, May 18, 2009 9:54 AM >> >> > Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG >> > register prevents the device from going into retention. >> > This is a workaround (by Richard Woodruff/TI), as his comment : >> > > A new MUSB bug which is a match to data below was identified very >> > > recently (on hardware and in simulation). >> > > This bug is in 3430 and not 3630. >> > > As a priority test (and as new default) you should have engineers >> > > disable autoidle for MUSB block. >> > > This is the workaround which will show up in next errata. >> > >> > Signed-off-by: Niilo Minkkinen >> >> Signed-off-by: Richard Woodruff >> >> Yes this is needed for 34xx. Side note is this cost around 1mW of power >> during active mode of MUSB. When device is not active cost is not >> significant. System impact depends on duty cycle of MUSB in usecase. > > Richard/Niilo, > This should also be applicable to 35xx (right?) and so we got to > update the fix with below patch. > > Regards, > Ajay > Don't have access to spec/errata of 35xx just now ;). Could Richard confirm, if this also applies (as original comment said) . -niilo- > == patch = > There is an issue with MUSB AUTOIDLE as reported by Niilo Minkkinen in below > commit. > > 9a4b5e36ce58febdd2039dd4d129ee7edf4f5536 > usb: musb: disable OTG AUTOIDLE only with omap3430 > > As OMAP35x is just a variant of OMAP34xx chip thus the fix is also applicable > for OMAP35x so updating it for OMAP35x. > > Signed-off-by: Ajay Kumar Gupta > --- > drivers/usb/musb/omap2430.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index > 453796c..ab8336d 100644 > --- a/drivers/usb/musb/omap2430.c > +++ b/drivers/usb/musb/omap2430.c > @@ -233,7 +233,7 @@ int __init musb_platform_init(struct musb *musb) > * MUSB AUTOIDLE don't work in 3430. > * Workaround by Richard Woodruff/TI > */ > - if (!cpu_is_omap3430()) > + if (!cpu_is_omap3430() && !cpu_is_omap35xx()) > l |= AUTOIDLE; /* enable auto idle */ > omap_writel(l, OTG_SYSCONFIG); > > -- > 1.6.2.4 > == > >> >> Regards, >> Richard W. >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-usb" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > 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 > -- - Niilo Minkkinen Kalhontie 69C 40950 MUURAME +358407324526 niilo.minkki...@iki.fi -- -- 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] OMAP3: PM: reset USB OTG module on boot
On Wed, 2009-06-24 at 16:07 +0200, ext Kevin Hilman wrote:
> Niilo Minkkinen writes:
>
> > On Wed, 2009-06-24 at 15:21 +0200, ext Kevin Hilman wrote:
> >> Niilo Minkkinen writes:
> >>
> >> > On Wed, 2009-06-24 at 02:27 +0200, ext Kevin Hilman wrote:
> >> >> Rather than simply setting force-idle mode on boot, do a reset of the
> >> >> OTG module. This really ensures that any bootloader/bootstrap code
> >> >> that leaves it active will not prevent future retention. After reset,
> >> >> OTG module will be in force-idle, force-standby mode.
> >> >>
> >> >> In addition, ensure that the iclk is enabled before attempting a write
> >> >> to the module SYSCONFIG register.
> >> >>
> >> >> Problem reported by Mike Chan
> >> >>
> >> >> Tested-by: Mike Chan
> >> >> Signed-off-by: Kevin Hilman
> >> >> ---
> >> >> If no comments/issues, this will be applied to PM branch and
> >> >> backported to pm-2.6.29.
> >> >>
> >> >> arch/arm/mach-omap2/usb-musb.c | 21 ++---
> >> >> 1 files changed, 18 insertions(+), 3 deletions(-)
> >> >>
> >> >> diff --git a/arch/arm/mach-omap2/usb-musb.c
> >> >> b/arch/arm/mach-omap2/usb-musb.c
> >> >> index d85296d..85731b8 100644
> >> >> --- a/arch/arm/mach-omap2/usb-musb.c
> >> >> +++ b/arch/arm/mach-omap2/usb-musb.c
> >> >> @@ -32,12 +32,27 @@
> >> >> #include
> >> >>
> >> >> #define OTG_SYSCONFIG (OMAP34XX_HSUSB_OTG_BASE + 0x404)
> >> >> +#define OTG_SYSC_SOFTRESET BIT(1)
> >> >>
> >> >> static void __init usb_musb_pm_init(void)
> >> >> {
> >> >> - /* Ensure force-idle mode for OTG controller */
> >> >> - if (cpu_is_omap34xx())
> >> >> - omap_writel(0, OTG_SYSCONFIG);
> >> >> + struct clk *iclk;
> >> >> +
> >> >> + if (!cpu_is_omap34xx())
> >> >> + return;
> >> >> +
> >> >> + iclk = clk_get(NULL, "hsotgusb_ick");
> >> >> + if (WARN_ON(!iclk))
> >> >> + return;
> >> >> +
> >> >> + clk_enable(iclk);
> >> >> +
> >> >> + /* Reset OTG controller. After reset, it will be in
> >> >> +* force-idle, force-standby mode. */
> >> >> + omap_writel(OTG_SYSC_SOFTRESET, OTG_SYSCONFIG);
> >> >
> >> > Do you think, this is safe to do w/o waiting reset to be finished
> >> > like : ?
> >> >
> >> > + omap_writel( SOFTRST, OTG_SYSCONFIG ); /* acquire RESET */
> >> > + start = jiffies;
> >> > + timeout = start + msecs_to_jiffies(10); /* max 10 ms */
> >> > + while (!time_after(jiffies, timeout)) /* wait until RESET OK */
> >> > + if ( omap_readl(OTG_SYSSTATUS) & RESETDONE )
> >> > + break;
> >>
> >> I thought about waiting for reset, but I decided that it wasn't
> >> necessary to wait since I wasn't going to write any other values
> >> after. Why hold up the boot process when nothing else will be
> >> writing?
> >>
> >> Kevin
> >>
> >
> > Sure you are right.
> > Thing I don't know, how near is the next access to musb ...
>
> Next access of MUSB isn't until the driver starts, and even then,
> there should be a clk_get(), clk_enable() before any other access to
> the MUSB regs.
>
> Kevin
>
Ok. This clears things.
Sorry for consuming bandwidth.
-niilo-
> > In my tests, this wait hasn't take even 1 ms (in units of jiffies), so I
> > don't know duration of it.
> > My comment anyhow can be think as a face-up.
> >
> > -niilo-
> >
> >> > SOFTRST & RESETDONE already defined in omap2430.h
> >> >
> >> >> +
> >> >> + clk_disable(iclk);
> >> >> + clk_put(iclk);
> >> >> }
> >> >>
> >> >> #ifdef CONFIG_USB_MUSB_SOC
> >
> > --
> > 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
--
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] OMAP3: PM: reset USB OTG module on boot
On Wed, 2009-06-24 at 15:21 +0200, ext Kevin Hilman wrote:
> Niilo Minkkinen writes:
>
> > On Wed, 2009-06-24 at 02:27 +0200, ext Kevin Hilman wrote:
> >> Rather than simply setting force-idle mode on boot, do a reset of the
> >> OTG module. This really ensures that any bootloader/bootstrap code
> >> that leaves it active will not prevent future retention. After reset,
> >> OTG module will be in force-idle, force-standby mode.
> >>
> >> In addition, ensure that the iclk is enabled before attempting a write
> >> to the module SYSCONFIG register.
> >>
> >> Problem reported by Mike Chan
> >>
> >> Tested-by: Mike Chan
> >> Signed-off-by: Kevin Hilman
> >> ---
> >> If no comments/issues, this will be applied to PM branch and
> >> backported to pm-2.6.29.
> >>
> >> arch/arm/mach-omap2/usb-musb.c | 21 ++---
> >> 1 files changed, 18 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-omap2/usb-musb.c
> >> b/arch/arm/mach-omap2/usb-musb.c
> >> index d85296d..85731b8 100644
> >> --- a/arch/arm/mach-omap2/usb-musb.c
> >> +++ b/arch/arm/mach-omap2/usb-musb.c
> >> @@ -32,12 +32,27 @@
> >> #include
> >>
> >> #define OTG_SYSCONFIG (OMAP34XX_HSUSB_OTG_BASE + 0x404)
> >> +#define OTG_SYSC_SOFTRESET BIT(1)
> >>
> >> static void __init usb_musb_pm_init(void)
> >> {
> >> - /* Ensure force-idle mode for OTG controller */
> >> - if (cpu_is_omap34xx())
> >> - omap_writel(0, OTG_SYSCONFIG);
> >> + struct clk *iclk;
> >> +
> >> + if (!cpu_is_omap34xx())
> >> + return;
> >> +
> >> + iclk = clk_get(NULL, "hsotgusb_ick");
> >> + if (WARN_ON(!iclk))
> >> + return;
> >> +
> >> + clk_enable(iclk);
> >> +
> >> + /* Reset OTG controller. After reset, it will be in
> >> + * force-idle, force-standby mode. */
> >> + omap_writel(OTG_SYSC_SOFTRESET, OTG_SYSCONFIG);
> >
> > Do you think, this is safe to do w/o waiting reset to be finished
> > like : ?
> >
> > + omap_writel( SOFTRST, OTG_SYSCONFIG ); /* acquire RESET */
> > + start = jiffies;
> > + timeout = start + msecs_to_jiffies(10); /* max 10 ms */
> > + while (!time_after(jiffies, timeout)) /* wait until RESET OK */
> > + if ( omap_readl(OTG_SYSSTATUS) & RESETDONE )
> > + break;
>
> I thought about waiting for reset, but I decided that it wasn't
> necessary to wait since I wasn't going to write any other values
> after. Why hold up the boot process when nothing else will be
> writing?
>
> Kevin
>
Sure you are right.
Thing I don't know, how near is the next access to musb ...
In my tests, this wait hasn't take even 1 ms (in units of jiffies), so I
don't know duration of it.
My comment anyhow can be think as a face-up.
-niilo-
> > SOFTRST & RESETDONE already defined in omap2430.h
> >
> >> +
> >> + clk_disable(iclk);
> >> + clk_put(iclk);
> >> }
> >>
> >> #ifdef CONFIG_USB_MUSB_SOC
--
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] OMAP3: PM: reset USB OTG module on boot
On Wed, 2009-06-24 at 02:27 +0200, ext Kevin Hilman wrote:
> Rather than simply setting force-idle mode on boot, do a reset of the
> OTG module. This really ensures that any bootloader/bootstrap code
> that leaves it active will not prevent future retention. After reset,
> OTG module will be in force-idle, force-standby mode.
>
> In addition, ensure that the iclk is enabled before attempting a write
> to the module SYSCONFIG register.
>
> Problem reported by Mike Chan
>
> Tested-by: Mike Chan
> Signed-off-by: Kevin Hilman
> ---
> If no comments/issues, this will be applied to PM branch and
> backported to pm-2.6.29.
>
> arch/arm/mach-omap2/usb-musb.c | 21 ++---
> 1 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
> index d85296d..85731b8 100644
> --- a/arch/arm/mach-omap2/usb-musb.c
> +++ b/arch/arm/mach-omap2/usb-musb.c
> @@ -32,12 +32,27 @@
> #include
>
> #define OTG_SYSCONFIG(OMAP34XX_HSUSB_OTG_BASE + 0x404)
> +#define OTG_SYSC_SOFTRESET BIT(1)
>
> static void __init usb_musb_pm_init(void)
> {
> - /* Ensure force-idle mode for OTG controller */
> - if (cpu_is_omap34xx())
> - omap_writel(0, OTG_SYSCONFIG);
> + struct clk *iclk;
> +
> + if (!cpu_is_omap34xx())
> + return;
> +
> + iclk = clk_get(NULL, "hsotgusb_ick");
> + if (WARN_ON(!iclk))
> + return;
> +
> + clk_enable(iclk);
> +
> + /* Reset OTG controller. After reset, it will be in
> + * force-idle, force-standby mode. */
> + omap_writel(OTG_SYSC_SOFTRESET, OTG_SYSCONFIG);
Do you think, this is safe to do w/o waiting reset to be finished
like : ?
+ omap_writel( SOFTRST, OTG_SYSCONFIG ); /* acquire RESET */
+ start = jiffies;
+ timeout = start + msecs_to_jiffies(10); /* max 10 ms */
+ while (!time_after(jiffies, timeout)) /* wait until RESET OK */
+ if ( omap_readl(OTG_SYSSTATUS) & RESETDONE )
+ break;
SOFTRST & RESETDONE already defined in omap2430.h
> +
> + clk_disable(iclk);
> + clk_put(iclk);
> }
>
> #ifdef CONFIG_USB_MUSB_SOC
--
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] usb: disable OTG AUTOIDLE only with omap3430
Things considering tranceiver suspend/wakeup are welcom, cause it seems to be mysteric, how to operate with. Sometimes clock aren't shutoff in suspend. Sometimes, wakeup is not succesfull. On 6/19/09, David Brownell wrote: > On Monday 18 May 2009, Woodruff, Richard wrote: >> >> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >> > ow...@vger.kernel.org] On Behalf Of Niilo Minkkinen >> > Sent: Monday, May 18, 2009 9:54 AM >> >> > Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG >> > register prevents the device from going into retention. >> > This is a workaround (by Richard Woodruff/TI), as his comment : >> > > A new MUSB bug which is a match to data below was identified very >> > > recently (on hardware and in simulation). >> > > This bug is in 3430 and not 3630. >> > > As a priority test (and as new default) you should have engineers >> > > disable autoidle for MUSB block. >> > > This is the workaround which will show up in next errata. >> > >> > Signed-off-by: Niilo Minkkinen >> >> Signed-off-by: Richard Woodruff >> >> Yes this is needed for 34xx. Side note is this cost around 1mW of power >> during active mode of MUSB. When device is not active cost is not >> significant. System impact depends on duty cycle of MUSB in usecase. > > There's also some initialization goofiness in that code ... it's supposed > to set initialize the transceiver with several distinct writes, of which > setting AUTOIDLE (to auto-gate the L3 clock) is ISTR the last step. > > The goofiness shows up with OTG initialization, which is documented as > needing a slightly different sequence ... my notes have it as being > an extra write to set ENABLEFORCE. > > - Dave > -- > 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 > -- - Niilo Minkkinen Kalhontie 69C 40950 MUURAME +358407324526 niilo.minkki...@iki.fi Arvokkainta ihmiselle on vapaus tehdä omia päätöksiä, jotka ovat joskus vääriäkin - Gottfried Leibniz (1646–1716) - -- -- 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: USB Host on OMAP3 EVM, 2.6.29
Hi Eikka. Am not familiar with OMAP35xx. Also don't know, what's the config of EVM (if it uses twl4030 tranceiver or external). Can it play as a HOST which is the case to supply VBUS ? Otherwise external self-powered hub might be needed. -niilo- On Wed, 2009-05-27 at 02:59 +0200, ext Eino-Ville Talvala wrote: > Hi, > > We're trying to get basic USB host mode up and running on a OMAP3530 > EVM, with no success. We're (now, after many permutations of kernels > and .config settings) using the vanilla 2.6.29-omap1 kernel plus the > AUTOIDLE fix from Niilo Minkkinen), with slight additions to > board-omap3evm to allow the MMC slot to work since it hosts the rootfs > (missing regulator setup, as per dfoley's mail on 3/25). > > All we've done with configuration past omap3_evm_defconfig, is to > compile in the MMC driver (to allow boot from it), enabling the EHCI > host driver (doesn't work with it off, either), and setting the > integrated USB driver to Host mode. Listed below is the resulting > .config file. We've tried many other configurations, but nothing has > worked any better. > > I'd very much appreciate it if anyone knows what magic sauce might be > missing here - the USB bus debug messages indicate that the bus is being > discovered, and powered up, but no voltage appears on the USB VBus line, > and no devices are detected when they're plugged in. Sometimes we've > seen auto-suspend messages indicating that the bus is auto-suspending, > and other times we've seen nothing - but no matter what, it doesn't seem > to work. > > Below is the output of "dmesg | grep 'usb\|hub' " for the above > configuration with a USB keyboard plugged in, followed by the .config file: > > Thanks, > > Eino-Ville Talvala > Graduate Research Assistant > Computer Graphics Laboratory > Stanford University > > > -- > twl4030_usb twl4030_usb: HW_CONDITIONS 0x50/80; link 1 > twl4030_usb twl4030_usb: Initialized TWL4030 USB module > usbcore: registered new interface driver usbfs > usbcore: registered new interface driver hub > usbcore: registered new device driver usb > musb_hdrc: version 6.0, musb-dma, host, debug=0 > musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine (X), bulk > split (X), HB-ISO Rx (X), HB-ISO Tx (X), SoftConn) > musb_hdrc: MHDRC RTL version 1.400 > musb_hdrc: setup fifo_mode 4 > musb_hdrc: 29/31 max ep, 15424/16384 memory > musb_hdrc: hw_ep 0shared, max 64 > musb_hdrc: hw_ep 1tx, max 512 > musb_hdrc: hw_ep 1rx, max 512 > musb_hdrc: hw_ep 2tx, max 512 > musb_hdrc: hw_ep 2rx, max 512 > musb_hdrc: hw_ep 3tx, max 512 > musb_hdrc: hw_ep 3rx, max 512 > musb_hdrc: hw_ep 4tx, max 512 > musb_hdrc: hw_ep 4rx, max 512 > musb_hdrc: hw_ep 5tx, max 512 > musb_hdrc: hw_ep 5rx, max 512 > musb_hdrc: hw_ep 6tx, max 512 > musb_hdrc: hw_ep 6rx, max 512 > musb_hdrc: hw_ep 7tx, max 512 > musb_hdrc: hw_ep 7rx, max 512 > musb_hdrc: hw_ep 8tx, max 512 > musb_hdrc: hw_ep 8rx, max 512 > musb_hdrc: hw_ep 9tx, max 512 > musb_hdrc: hw_ep 9rx, max 512 > musb_hdrc: hw_ep 10tx, max 512 > musb_hdrc: hw_ep 10rx, max 512 > musb_hdrc: hw_ep 11tx, max 512 > musb_hdrc: hw_ep 11rx, max 512 > musb_hdrc: hw_ep 12tx, max 512 > musb_hdrc: hw_ep 12rx, max 512 > musb_hdrc: hw_ep 13tx, max 512 > musb_hdrc: hw_ep 13rx, max 512 > musb_hdrc: hw_ep 14shared, max 1024 > musb_hdrc: hw_ep 15shared, max 1024 > musb_hdrc: USB Host mode controller at d80ab000 using DMA, IRQ 92 > musb_hdrc musb_hdrc: MUSB HDRC host driver > drivers/usb/core/inode.c: creating file 'devices' > drivers/usb/core/inode.c: creating file '001' > musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 > usb usb1: default language 0x0409 > usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 > usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb1: Product: MUSB HDRC host driver > usb usb1: Manufacturer: Linux 2.6.29-omap1-05531-g0dfe43a-dirty musb-hcd > usb usb1: SerialNumber: musb_hdrc > usb usb1: uevent > usb usb1: usb_probe_device > usb usb1: configuration #1 chosen from 1 choice > usb usb1: adding 1-0:1.0 (config #1, interface 0) > usb 1-0:1.0: uevent > hub 1-0:1.0: usb_probe_interface > hub 1-0:1.0: usb_probe_interface - got id > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 1 port detected > hub 1-0:1.0: standalone hub > hub 1-0:1.0: individual port power switching > hub 1-0:1.0: no over-current protection > hub 1-0:1.0: power on to power good time: 1
[PATCH] usb: disable OTG AUTOIDLE only with omap3430
Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG register prevents the device from going into retention. This is a workaround (by Richard Woodruff/TI), as his comment : > A new MUSB bug which is a match to data below was identified very > recently (on hardware and in simulation). > This bug is in 3430 and not 3630. > As a priority test (and as new default) you should have engineers > disable autoidle for MUSB block. > This is the workaround which will show up in next errata. Signed-off-by: Niilo Minkkinen --- drivers/usb/musb/omap2430.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 901dffd..396fc6d 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -241,7 +241,12 @@ int __init musb_platform_init(struct musb *musb) l &= ~AUTOIDLE; /* disable auto idle */ l &= ~NOIDLE; /* remove possible noidle */ l |= SMARTIDLE; /* enable smart idle */ - l |= AUTOIDLE; /* enable auto idle */ + /* +* MUSB AUTOIDLE don't work in 3430. +* Workaround by Richard Woodruff/TI +*/ + if (!cpu_is_omap3430()) + l |= AUTOIDLE; /* enable auto idle */ omap_writel(l, OTG_SYSCONFIG); l = omap_readl(OTG_INTERFSEL); -- 1.6.0.4 -- 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
