status of USB on omap35xx ?

status of USB on omap35xx ?

[Jeff Steele]

Hi All,

I'm hoping to use a Gumstix Overo (OMAP 3503 chip) for a new project,
but I'm a little confused about what USB features are currently working
in the omap-git tree kernel.


Can someone tell me :


1) Is the USB OTG port working for HS bulk transfers when operating as a
device("gadget") ? For example, is there a version
of /drivers/usb/gadget/zero.c that works on 35xx processors ?


2) Is it possible to use the USB Host port and the OTG port
simultaneously ?

One scenario I'm envisioning is to read bulk data from a device via the
host port, process it, and then feed it out the OTG port to a "real"
host computer.

3) Is the Host port working pretty reliably, or are there any issues
still to be resolved ?


I don't mind if I need to apply patches or edit/re-compile a few lines
of kernel code, but I don't want to get stranded too deep in
un-supported territory...


Thanks,

Jeff

Re: status of USB on omap35xx ?

[Felipe Balbi]

On Tue, Dec 09, 2008 at 05:50:50PM -0700, ext Jeff Steele wrote:
> 1) Is the USB OTG port working for HS bulk transfers when operating as a
> device("gadget") ? For example, is there a version
> of /drivers/usb/gadget/zero.c that works on 35xx processors ?

yes.

> 2) Is it possible to use the USB Host port and the OTG port
> simultaneously ?

should be possible, they're different controllers.

> One scenario I'm envisioning is to read bulk data from a device via the
> host port, process it, and then feed it out the OTG port to a "real"
> host computer.
> 
> 3) Is the Host port working pretty reliably, or are there any issues
> still to be resolved ?

ehci driver still needs some work. You can help

> I don't mind if I need to apply patches or edit/re-compile a few lines
> of kernel code, but I don't want to get stranded too deep in
> un-supported territory...

-- 
balbi

Re: status of USB on omap35xx ?

[Jeff Steele]

On Wed, 2008-12-10 at 16:46 +0200, Felipe Balbi wrote:
> > 3) Is the Host port working pretty reliably, or are there any issues
> > still to be resolved ?
> 
> ehci driver still needs some work. You can help
> 



What are the issues ? 


I really only need to read bulk packets from one HS device that is
present at boot.



--
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

Re: status of USB on omap35xx ?

[Felipe Balbi]

On Wed, Dec 10, 2008 at 09:33:53AM -0700, Jeff Steele wrote:
> On Wed, 2008-12-10 at 16:46 +0200, Felipe Balbi wrote:
> > > 3) Is the Host port working pretty reliably, or are there any issues
> > > still to be resolved ?
> > 
> > ehci driver still needs some work. You can help
> > 
> 
> 
> 
> What are the issues ? 
> 
> ???
> ???I really only need to read bulk packets from one HS device that is
> present at boot.

It think it still has a problem during probe. If you read the driver
you'll see there are some infinite while loops without timeout actions.
And one of them is looping forever due to clock issues.

Donno if that's fixed by now. Worth trying.

-- 
balbi

Re: status of USB on omap35xx ?

[David Brownell]

The OTG link is in usable shape, but the EHCI one isn't.


On Wednesday 10 December 2008, Felipe Balbi wrote:
> > 
> > What are the issues ? 

I have a prototype Overo and one issue there is that the
GPIO to let the EHCI port supply VBUS power isn't hooked
up!  I know how to modify that board, but somehow that
keeps slipping off my radar ... :)

I don't know the details, but the big problem with EHCI
on OMAP3 is evidently some kind of silicon issue that
shows up through the transceiver hookup and prevents the
link from being reliable.  I'm told that some boards using
that without a transceiver -- for on-board communication,
not for an external link -- have been successful.

Folk at TI were looking at those issues; I don't know if
they've been resolved yet, e.g. in the ES 3.0 silicon.


> It think it still has a problem during probe. If you read the driver
> you'll see there are some infinite while loops without timeout actions.
> And one of them is looping forever due to clock issues.
 
That's a newish problem, but is not -- from what I've
been told -- the Real Issue with EHCI on OMAP3.

- Dave

Re: status of USB on omap35xx ?

[Felipe Balbi]

On Wed, Dec 10, 2008 at 10:28:25AM -0800, David Brownell wrote:
> I don't know the details, but the big problem with EHCI
> on OMAP3 is evidently some kind of silicon issue that
> shows up through the transceiver hookup and prevents the
> link from being reliable.  I'm told that some boards using
> that without a transceiver -- for on-board communication,
> not for an external link -- have been successful.
> 
> Folk at TI were looking at those issues; I don't know if
> they've been resolved yet, e.g. in the ES 3.0 silicon.

Oh yeah, that's right. There was some pin-incompatibility with ohci
which prevented port handoffs to be done reliably, or something like
that.

If I'm not wrong, once the port is handed over to ohci, it can never
switch back to ehci and it dies.

Can't really remember if this is the right issue since I haven't been
working too much with ehci :-p

-- 
balbi

RE: status of USB on omap35xx ?

[Pandita, Vikram]

>-----Original Message-----
>From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Felipe
>Balbi
>Sent: Wednesday, December 10, 2008 1:01 PM
>To: David Brownell
>Cc: me@felipebalbi.com; Jeff Steele; linux-omap
>Subject: Re: status of USB on omap35xx ?
>
>On Wed, Dec 10, 2008 at 10:28:25AM -0800, David Brownell wrote:
>> I don't know the details, but the big problem with EHCI
>> on OMAP3 is evidently some kind of silicon issue that
>> shows up through the transceiver hookup and prevents the
>> link from being reliable.  I'm told that some boards using
>> that without a transceiver -- for on-board communication,
>> not for an external link -- have been successful.

Internally in TI on SDP3430 we have EHCI working for PHY as well as TLL mode.
The PHY we used is ISP1504 for EHCI and ISP1301 for OHCI.

>>
>> Folk at TI were looking at those issues; I don't know if
>> they've been resolved yet, e.g. in the ES 3.0 silicon.
>
>Oh yeah, that's right. There was some pin-incompatibility with ohci
>which prevented port handoffs to be done reliably, or something like
>that.

USB-HOST core is primarily designed to support TLL mode.
Dynamic switch from EHCI to OHCI is not supported. It has to be statically set.

Eg:
Port1-EHCI
Port2-EHCI
Port3-OHCI

There was a limitation in earlier silicons that EHCI and OHCI cannot be used simultaneously, which has been resolved in ES3.0

>
>If I'm not wrong, once the port is handed over to ohci, it can never
>switch back to ehci and it dies.
>
>Can't really remember if this is the right issue since I haven't been
>working too much with ehci :-p
>
>--
>balbi
>--
>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

Re: status of USB on omap35xx ?

[Steve Sakoman]

On Wed, Dec 10, 2008 at 10:28 AM, David Brownell <david-b@pacbell.net> wrote:
> The OTG link is in usable shape, but the EHCI one isn't.
>
>
> On Wednesday 10 December 2008, Felipe Balbi wrote:
>> >
>> > What are the issues ?
>
> I have a prototype Overo and one issue there is that the
> GPIO to let the EHCI port supply VBUS power isn't hooked
> up!  I know how to modify that board, but somehow that
> keeps slipping off my radar ... :)

That issue is fixed on the shipping "Summit" boards.

> I don't know the details, but the big problem with EHCI
> on OMAP3 is evidently some kind of silicon issue that
> shows up through the transceiver hookup and prevents the
> link from being reliable.  I'm told that some boards using
> that without a transceiver -- for on-board communication,
> not for an external link -- have been successful.
>
> Folk at TI were looking at those issues; I don't know if
> they've been resolved yet, e.g. in the ES 3.0 silicon.

I see that Vikram has responded to this already.

>> It think it still has a problem during probe. If you read the driver
>> you'll see there are some infinite while loops without timeout actions.
>> And one of them is looping forever due to clock issues.
>
> That's a newish problem, but is not -- from what I've
> been told -- the Real Issue with EHCI on OMAP3.

This problem has actually been around since 2.6.27.

Prior to that, the EHCI port "sort of" worked - but not super
reliably.  It would enumerate devices on the bus, but then die
randomly afterwards.

Since somewhere during the 2.6.27 time frame we've been suffering from
the infinite loop at boot problem.

I patched around the loop that seemed to be causing the issue, but
didn't have great success getting back to even the "sort of" working
state.

I am far from being a USB expert, so the messages in the log don't
mean a whole lot to me :-)

ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: OMAP-EHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.28-rc7-omap1 ehci_hcd
usb usb2: SerialNumber: ehci-omap.0
<snip>
usb usb2: bus auto-suspend
usb usb2: uevent
usb 2-0:1.0: uevent
<snip>
usb usb2: usb auto-resume
usb usb2: bus auto-suspend

Steve

Re: status of USB on omap35xx ?

[Tony Lindgren]

* Steve Sakoman <sakoman@gmail.com> [081210 15:02]:
> On Wed, Dec 10, 2008 at 10:28 AM, David Brownell <david-b@pacbell.net> wrote:
> > The OTG link is in usable shape, but the EHCI one isn't.
> >
> >
> > On Wednesday 10 December 2008, Felipe Balbi wrote:
> >> >
> >> > What are the issues ?
> >
> > I have a prototype Overo and one issue there is that the
> > GPIO to let the EHCI port supply VBUS power isn't hooked
> > up!  I know how to modify that board, but somehow that
> > keeps slipping off my radar ... :)
> 
> That issue is fixed on the shipping "Summit" boards.
> 
> > I don't know the details, but the big problem with EHCI
> > on OMAP3 is evidently some kind of silicon issue that
> > shows up through the transceiver hookup and prevents the
> > link from being reliable.  I'm told that some boards using
> > that without a transceiver -- for on-board communication,
> > not for an external link -- have been successful.
> >
> > Folk at TI were looking at those issues; I don't know if
> > they've been resolved yet, e.g. in the ES 3.0 silicon.
> 
> I see that Vikram has responded to this already.
> 
> >> It think it still has a problem during probe. If you read the driver
> >> you'll see there are some infinite while loops without timeout actions.
> >> And one of them is looping forever due to clock issues.
> >
> > That's a newish problem, but is not -- from what I've
> > been told -- the Real Issue with EHCI on OMAP3.
> 
> This problem has actually been around since 2.6.27.
> 
> Prior to that, the EHCI port "sort of" worked - but not super
> reliably.  It would enumerate devices on the bus, but then die
> randomly afterwards.
> 
> Since somewhere during the 2.6.27 time frame we've been suffering from
> the infinite loop at boot problem.
> 
> I patched around the loop that seemed to be causing the issue, but
> didn't have great success getting back to even the "sort of" working
> state.
> 
> I am far from being a USB expert, so the messages in the log don't
> mean a whole lot to me :-)

Can you please post whatever patches you need to apply to make it work
occasionally so others can also look at the issue?

Thanks,

Tony


> ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
> usb usb2: configuration #1 chosen from 1 choice
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 3 ports detected
> usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
> usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb2: Product: OMAP-EHCI Host Controller
> usb usb2: Manufacturer: Linux 2.6.28-rc7-omap1 ehci_hcd
> usb usb2: SerialNumber: ehci-omap.0
> <snip>
> usb usb2: bus auto-suspend
> usb usb2: uevent
> usb 2-0:1.0: uevent
> <snip>
> usb usb2: usb auto-resume
> usb usb2: bus auto-suspend
> 
> Steve
> --
> 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

Re: status of USB on omap35xx ?

[Grazvydas Ignotas]

> Can you please post whatever patches you need to apply to make it work
> occasionally so others can also look at the issue?

For pandora, making infinite while loops finite doesn't help much,
kernel crashes later on. Steve had this too:
http://marc.info/?l=linux-omap&m=122378604027303&w=2

I did bisect and found that commit
8b1f0bd44fe490ec631230c8c040753a2bda8caa is causing the hang for me.
Reverting this makes EHCI work again on pandora.
http://marc.info/?l=linux-omap&m=122453174024860&w=2

Re: status of USB on omap35xx ?

[Paul Walmsley]

Hi Grazvydas, Steve,

On Thu, 11 Dec 2008, Grazvydas Ignotas wrote:

> > Can you please post whatever patches you need to apply to make it work
> > occasionally so others can also look at the issue?
> 
> For pandora, making infinite while loops finite doesn't help much,
> kernel crashes later on. Steve had this too:
> http://marc.info/?l=linux-omap&m=122378604027303&w=2
> 
> I did bisect and found that commit
> 8b1f0bd44fe490ec631230c8c040753a2bda8caa is causing the hang for me.
> Reverting this makes EHCI work again on pandora.
> http://marc.info/?l=linux-omap&m=122453174024860&w=2

Would one of you be willing to run with this patch and send back any debug 
output relating to dpll5_ck ?  (Unfortunately, I don't have access to any 
boards with EHCI hardware, so cannot try it myself)

This will help determine what fix should be applied


- Paul



Add debugging in omap3_noncore_dpll_enable() - for testing only.

---
 arch/arm/mach-omap2/clock34xx.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 2c655be..3b80667 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -275,6 +275,10 @@ static int omap3_noncore_dpll_enable(struct clk *clk)
 	if (!dd)
 		return -EINVAL;
 
+	pr_info("clock: %s: clk->rate = %ld, hdwr rate = %d, parent "
+		"rate = %ld\n", clk->name, clk->rate, 
+		omap2_get_dpll_rate(clk), dd->bypass_clk->rate);
+
 	if (clk->rate == dd->bypass_clk->rate)
 		r = _omap3_noncore_dpll_bypass(clk);
 	else

Re: status of USB on omap35xx ?

[Steve Sakoman]

On Thu, Dec 11, 2008 at 8:49 AM, Paul Walmsley <paul@booyaka.com> wrote:
> Hi Grazvydas, Steve,
>
> On Thu, 11 Dec 2008, Grazvydas Ignotas wrote:
>
>> > Can you please post whatever patches you need to apply to make it work
>> > occasionally so others can also look at the issue?
>>
>> For pandora, making infinite while loops finite doesn't help much,
>> kernel crashes later on. Steve had this too:
>> http://marc.info/?l=linux-omap&m=122378604027303&w=2
>>
>> I did bisect and found that commit
>> 8b1f0bd44fe490ec631230c8c040753a2bda8caa is causing the hang for me.
>> Reverting this makes EHCI work again on pandora.
>> http://marc.info/?l=linux-omap&m=122453174024860&w=2
>
> Would one of you be willing to run with this patch and send back any debug
> output relating to dpll5_ck ?  (Unfortunately, I don't have access to any
> boards with EHCI hardware, so cannot try it myself)
>
> This will help determine what fix should be applied

Here you go.  Note that no infinite loop!

ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
clock: dpll5_ck: clk->rate = 0, hdwr rate = 120000000, parent rate = 13000000
ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 2
ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
usb 1-1: new high speed USB device using musb_hdrc and address 2
ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: OMAP-EHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.28-rc7-omap1 ehci_hcd
usb usb2: SerialNumber: ehci-omap.0

Steve

> - Paul
>
>
>
> Add debugging in omap3_noncore_dpll_enable() - for testing only.
>
> ---
>  arch/arm/mach-omap2/clock34xx.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
> index 2c655be..3b80667 100644
> --- a/arch/arm/mach-omap2/clock34xx.c
> +++ b/arch/arm/mach-omap2/clock34xx.c
> @@ -275,6 +275,10 @@ static int omap3_noncore_dpll_enable(struct clk *clk)
>        if (!dd)
>                return -EINVAL;
>
> +       pr_info("clock: %s: clk->rate = %ld, hdwr rate = %d, parent "
> +               "rate = %ld\n", clk->name, clk->rate,
> +               omap2_get_dpll_rate(clk), dd->bypass_clk->rate);
> +
>        if (clk->rate == dd->bypass_clk->rate)
>                r = _omap3_noncore_dpll_bypass(clk);
>        else
>
>
>

Re: status of USB on omap35xx ?

[Steve Sakoman]

On Thu, Dec 11, 2008 at 2:38 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
>> Can you please post whatever patches you need to apply to make it work
>> occasionally so others can also look at the issue?
>
> For pandora, making infinite while loops finite doesn't help much,
> kernel crashes later on. Steve had this too:
> http://marc.info/?l=linux-omap&m=122378604027303&w=2
>
> I did bisect and found that commit
> 8b1f0bd44fe490ec631230c8c040753a2bda8caa is causing the hang for me.
> Reverting this makes EHCI work again on pandora.
> http://marc.info/?l=linux-omap&m=122453174024860&w=2
>

A simple revert of that commit resulted in a build failure, so I tried
the following patch:

--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -265,7 +265,7 @@ static int _omap3_noncore_dpll_stop(stru
 */
 static int omap3_noncore_dpll_enable(struct clk *clk)
 {
-       int r;
+       int r, rate;
       struct dpll_data *dd;

       if (clk == &dpll3_ck)
@@ -275,7 +275,9 @@ static int omap3_noncore_dpll_enable(str
       if (!dd)
               return -EINVAL;

-       if (clk->rate == dd->bypass_clk->rate)
+       rate = omap2_get_dpll_rate(clk);
+
+       if (dd->bypass_clk->rate == rate)
               r = _omap3_noncore_dpll_bypass(clk);
       else
               r = _omap3_noncore_dpll_lock(clk);

Result: no hang at boot, but I still end up with the auto suspend,
though the behavior is slightly different (dmesg output this time
since it contains more debug info):

ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci_hcd: block sizes: qh 128 qtd 96 itd 160 sitd 96
ehci-omap ehci-omap.0: ehci_hcd_omap_drv_probe()
ehci-omap ehci-omap.0: starting TI EHCI USB Controller
ehci-omap ehci-omap.0: idlest2 = 0x0
ehci-omap ehci-omap.0: idlest2 = 0x0
ehci-omap ehci-omap.0: idlest2 = 0x0
ehci-omap ehci-omap.0: idlest2 = 0x0
ehci-omap ehci-omap.0: idlest2 = 0x0
ehci-omap ehci-omap.0: idlest2 = 0x0
ehci-omap ehci-omap.0: idlest2 = 0x0
ehci-omap ehci-omap.0: idlest2 = 0x0
ehci-omap ehci-omap.0: idlest2 = 0x0
ehci-omap ehci-omap.0: idlest2 = 0x0
ehci-omap ehci-omap.0: idlest2 = 0x0
ehci-omap ehci-omap.0: idlest2 = 0x0
ehci-omap ehci-omap.0: idlest2 = 0x0
ehci-omap ehci-omap.0: idlest2 = 0x0
ehci-omap ehci-omap.0: idlest2 = 0x0
ehci-omap ehci-omap.0: TLL RESET DONE
ehci-omap ehci-omap.0: Entered ULPI PHY MODE: success
ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
drivers/usb/core/inode.c: creating file '002'
ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 2
ehci-omap ehci-omap.0: park 0
ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
ehci-omap ehci-omap.0: reset command 090b02 park=3 ithresh=9
period=1024 Reset HALT
ehci-omap ehci-omap.0: init command 010009 (park)=0 ithresh=1 period=256 RUN
usb 1-1: new high speed USB device using musb_hdrc and address 2
ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
usb usb2: default language 0x0409
usb usb2: uevent
usb usb2: usb_probe_device
usb usb2: configuration #1 chosen from 1 choice
usb usb2: adding 2-0:1.0 (config #1, interface 0)
usb 2-0:1.0: uevent
hub 2-0:1.0: usb_probe_interface
hub 2-0:1.0: usb_probe_interface - got id
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
hub 2-0:1.0: standalone hub
hub 2-0:1.0: individual port power switching
hub 2-0:1.0: individual port over-current protection
hub 2-0:1.0: power on to power good time: 20ms
hub 2-0:1.0: local power source is good
hub 2-0:1.0: enabling power on all ports
drivers/usb/core/inode.c: creating file '001'
usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: OMAP-EHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.28-rc7-omap1 ehci_hcd
usb usb2: SerialNumber: ehci-omap.0
<snip>
hub 2-0:1.0: state 7 ports 3 chg 0000 evt 0000
<snip>
usb usb2: uevent
usb 2-0:1.0: uevent
<snip>
hub 2-0:1.0: hub_suspend
usb usb2: bus auto-suspend
ehci-omap ehci-omap.0: suspend root hub
<snip>
usb usb2: usb auto-resume
ehci-omap ehci-omap.0: resume root hub
hub 2-0:1.0: hub_resume
hub 2-0:1.0: state 7 ports 3 chg 0000 evt 0000
hub 2-0:1.0: hub_suspend
usb usb2: bus auto-suspend
ehci-omap ehci-omap.0: suspend root hub

Re: status of USB on omap35xx ?

[Paul Walmsley]

Hi Vikram,

looking at ehci-omap.c lines 190-204.  Is there some reason why the 
USBHOST clockdomain needs to be in software-supervised mode?  Also, is 
there some reason why the interface clock must be prevented from 
auto-idling?  This will cause problems with power management.


- Paul

	/* PRCM settings for USBHOST:
	 * Interface clk un-related to domain transition
	 */
	cm_write_mod_reg(0 << OMAP3430ES2_AUTO_USBHOST_SHIFT,
				OMAP3430ES2_USBHOST_MOD, CM_AUTOIDLE);

	/* Disable sleep dependency with MPU and IVA */
	cm_write_mod_reg((0 << OMAP3430ES2_EN_MPU_SHIFT) |
				(0 << OMAP3430ES2_EN_IVA2_SHIFT),
				OMAP3430ES2_USBHOST_MOD, OMAP3430_CM_SLEEPDEP);

	/* Disable Automatic transition of clock */
	cm_write_mod_reg(0 << OMAP3430ES2_CLKTRCTRL_USBHOST_SHIFT,
				OMAP3430ES2_USBHOST_MOD, CM_CLKSTCTRL);

RE: status of USB on omap35xx ?

[Pandita, Vikram]

Paul

>-----Original Message-----
>From: Paul Walmsley [mailto:paul@pwsan.com]
>Sent: Thursday, December 11, 2008 12:15 PM
>To: Pandita, Vikram
>Cc: Steve Sakoman; Tony Lindgren; linux-omap; David Brownell; me@felipebalbi.com; Jeff Steele
>Subject: Re: status of USB on omap35xx ?
>
>Hi Vikram,
>
>looking at ehci-omap.c lines 190-204.  Is there some reason why the
>USBHOST clockdomain needs to be in software-supervised mode?  Also, is
>there some reason why the interface clock must be prevented from
>auto-idling?  This will cause problems with power management.

All these checks were in place for initial debugging. 
There is no need to keep these check now.

>
>
>- Paul
>
>	/* PRCM settings for USBHOST:
>	 * Interface clk un-related to domain transition
>	 */
>	cm_write_mod_reg(0 << OMAP3430ES2_AUTO_USBHOST_SHIFT,
>				OMAP3430ES2_USBHOST_MOD, CM_AUTOIDLE);
>
>	/* Disable sleep dependency with MPU and IVA */
>	cm_write_mod_reg((0 << OMAP3430ES2_EN_MPU_SHIFT) |
>				(0 << OMAP3430ES2_EN_IVA2_SHIFT),
>				OMAP3430ES2_USBHOST_MOD, OMAP3430_CM_SLEEPDEP);
>
>	/* Disable Automatic transition of clock */
>	cm_write_mod_reg(0 << OMAP3430ES2_CLKTRCTRL_USBHOST_SHIFT,
>				OMAP3430ES2_USBHOST_MOD, CM_CLKSTCTRL);
>
>
>
>

Re: status of USB on omap35xx ?

[Grazvydas Ignotas]

On Thu, Dec 11, 2008 at 7:38 PM, Steve Sakoman <sakoman@gmail.com> wrote:
> On Thu, Dec 11, 2008 at 8:49 AM, Paul Walmsley <paul@booyaka.com> wrote:
>> Hi Grazvydas, Steve,
>>
>> On Thu, 11 Dec 2008, Grazvydas Ignotas wrote:
>>
>>> > Can you please post whatever patches you need to apply to make it work
>>> > occasionally so others can also look at the issue?
>>>
>>> For pandora, making infinite while loops finite doesn't help much,
>>> kernel crashes later on. Steve had this too:
>>> http://marc.info/?l=linux-omap&m=122378604027303&w=2
>>>
>>> I did bisect and found that commit
>>> 8b1f0bd44fe490ec631230c8c040753a2bda8caa is causing the hang for me.
>>> Reverting this makes EHCI work again on pandora.
>>> http://marc.info/?l=linux-omap&m=122453174024860&w=2
>>
>> Would one of you be willing to run with this patch and send back any debug
>> output relating to dpll5_ck ?  (Unfortunately, I don't have access to any
>> boards with EHCI hardware, so cannot try it myself)
>>
>> This will help determine what fix should be applied
>
> Here you go.  Note that no infinite loop!

Ah, so it no longer needs that revert, probably recent clock changes
fixed that issue.

> ...
> Result: no hang at boot, but I still end up with the auto suspend,
> though the behavior is slightly different (dmesg output this time
> since it contains more debug info):

If your host uses PHY mode, have you hacked EXT_PHY_RESET_GPIO* in
drivers/usb/host/ehci-omap.c? BTW, if this stuff is really needed, it
should go to platform_data..

Re: status of USB on omap35xx ?

[Paul Walmsley]

On Thu, 11 Dec 2008, Grazvydas Ignotas wrote:

> On Thu, Dec 11, 2008 at 7:38 PM, Steve Sakoman <sakoman@gmail.com> wrote:
> > Here you go.  Note that no infinite loop!
> 
> Ah, so it no longer needs that revert, probably recent clock changes
> fixed that issue.

What is baffling is that it appears to be the presence of the 
omap2_get_dpll_rate() call before the conditional that seems to be the 
primary factor in whether the loop is infinite or not.  The expression in 
the conditional will evaluate to 0 in both cases (13000000 != 120000000 
and 0 != 13000000).

Gravyzdas, can you send us a commit ID that results in successful device 
enumeration (after reverting 
http://marc.info/?l=linux-omap&m=122453174024860&w=2 ?)  Sounds like it 
was working for you in late October with that revert.


- Paul

Re: status of USB on omap35xx ?

[Steve Sakoman]

On Thu, Dec 11, 2008 at 12:41 PM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> On Thu, Dec 11, 2008 at 7:38 PM, Steve Sakoman <sakoman@gmail.com> wrote:
>> On Thu, Dec 11, 2008 at 8:49 AM, Paul Walmsley <paul@booyaka.com> wrote:
>>> Hi Grazvydas, Steve,
>>>
>>> On Thu, 11 Dec 2008, Grazvydas Ignotas wrote:
>>>
>>>> > Can you please post whatever patches you need to apply to make it work
>>>> > occasionally so others can also look at the issue?
>>>>
>>>> For pandora, making infinite while loops finite doesn't help much,
>>>> kernel crashes later on. Steve had this too:
>>>> http://marc.info/?l=linux-omap&m=122378604027303&w=2
>>>>
>>>> I did bisect and found that commit
>>>> 8b1f0bd44fe490ec631230c8c040753a2bda8caa is causing the hang for me.
>>>> Reverting this makes EHCI work again on pandora.
>>>> http://marc.info/?l=linux-omap&m=122453174024860&w=2
>>>
>>> Would one of you be willing to run with this patch and send back any debug
>>> output relating to dpll5_ck ?  (Unfortunately, I don't have access to any
>>> boards with EHCI hardware, so cannot try it myself)
>>>
>>> This will help determine what fix should be applied
>>
>> Here you go.  Note that no infinite loop!
>
> Ah, so it no longer needs that revert, probably recent clock changes
> fixed that issue.
>
>> ...
>> Result: no hang at boot, but I still end up with the auto suspend,
>> though the behavior is slightly different (dmesg output this time
>> since it contains more debug info):
>
> If your host uses PHY mode, have you hacked EXT_PHY_RESET_GPIO* in
> drivers/usb/host/ehci-omap.c? BTW, if this stuff is really needed, it
> should go to platform_data..

I have hacked in the reset GPIO used on Overo.  I agree -- board
specific stuff has no place in ehci-omap, it really should be platform
data.

Sadly my ehci port still goes into auto suspend.  I've attached the
output of dmesg.  Can you take a look and see at what point my ehci
messages diverge from what you see?

Steve

root@overo:~# dmesg
76..383
twl4030: gpio (irq 368) chaining IRQs 384..401
i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz
twl4030_usb twl4030_usb: Initialized TWL4030 USB module
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
musb_hdrc: version 6.0, pio, host, debug=0
musb_hdrc: ConfigData=0x55 (UTMI-16, dyn FIFOs, bulk split (X), HB-ISO Rx (X))
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 PIO, 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: 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: 10ms
hub 1-0:1.0: 100mA bus power budget for each child
hub 1-0:1.0: local power source is good
hub 1-0:1.0: enabling power on all ports
drivers/usb/core/inode.c: creating file '001'
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.28-rc7-omap1 musb-hcd
usb usb1: SerialNumber: musb_hdrc
Bluetooth: Core ver 2.13
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
cfg80211: Using static regulatory domain info
cfg80211: Regulatory domain: US
	(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
	(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
	(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
	(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
	(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
	(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
	(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
cfg80211: Calling CRDA for country: US
NET: Registered protocol family 2
Switched to high resolution mode on CPU 0
hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
NET: Registered protocol family 1
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
JFFS2 version 2.2. (NAND) (SUMMARY)  (c) 2001-2006 Red Hat, Inc.
msgmni has been set to 497
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
omapfb: using mode 1024x768@60
omapfb: configured for panel overo
omapfb: DISPC version 3.0 initialized
Console: switching to colour frame buffer device 128x48
hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002
hub 1-0:1.0: port 1, status 0101, change 0001, 12 Mb/s
omapfb: Framebuffer initialized. Total vram 6291456 planes 2
omapfb: Pixclock 54000 kHz hfreq 45.6081 kHz vfreq 57.7 Hz
Serial: 8250/16550 driver4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654
serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654
serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654
console [ttyS2] enabled
brd: module loaded
loop: module loaded
usbcore: registered new interface driver asix
usbcore: registered new interface driver cdc_ether
i2c /dev entries driver
input: triton2-pwrbutton as /class/input/input0
triton2 power button driver initialized
Driver 'sd' needs updating - please use bus_type methods
omap2-nand driver initializing
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB
1,8V 16-bit)
hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101
cmdlinepart partition parsing not available
Creating 5 MTD partitions on "omap2-nand":
0x00000000-0x00080000 : "xloader"
0x00080000-0x00240000 : "uboot"
0x00240000-0x00280000 : "uboot environment"
0x00280000-0x00680000 : "linux"
0x00680000-0x10000000 : "rootfs"
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci_hcd: block sizes: qh 128 qtd 96 itd 160 sitd 96
ehci-omap ehci-omap.0: ehci_hcd_omap_drv_probe()
ehci-omap ehci-omap.0: starting TI EHCI USB Controller
clock: dpll5_ck: clk->rate = 120000000, hdwr rate = 120000000, parent
rate = 13000000
ehci-omap ehci-omap.0: TLL RESET DONE
ehci-omap ehci-omap.0: Entered ULPI PHY MODE: success
ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
drivers/usb/core/inode.c: creating file '002'
ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 2
ehci-omap ehci-omap.0: park 0
ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
ehci-omap ehci-omap.0: reset command 090b02 park=3 ithresh=9
period=1024 Reset HALT
ehci-omap ehci-omap.0: init command 010009 (park)=0 ithresh=1 period=256 RUN
usb 1-1: new high speed USB device using musb_hdrc and address 2
ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
usb usb2: default language 0x0409
usb usb2: uevent
usb usb2: usb_probe_device
usb usb2: configuration #1 chosen from 1 choice
usb usb2: adding 2-0:1.0 (config #1, interface 0)
usb 2-0:1.0: uevent
hub 2-0:1.0: usb_probe_interface
hub 2-0:1.0: usb_probe_interface - got id
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
hub 2-0:1.0: standalone hub
hub 2-0:1.0: individual port power switching
hub 2-0:1.0: individual port over-current protection
hub 2-0:1.0: power on to power good time: 20ms
hub 2-0:1.0: local power source is good
hub 2-0:1.0: enabling power on all ports
drivers/usb/core/inode.c: creating file '001'
usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: OMAP-EHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.28-rc7-omap1 ehci_hcd
usb usb2: SerialNumber: ehci-omap.0
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
twl4030_rtc twl4030_rtc: rtc core: registered twl4030_rtc as rtc0
OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
Bluetooth: HCI UART driver ver 2.2
Bluetooth: HCI H4 protocol initialized
Bluetooth: HCI BCSP protocol initialized
Bluetooth: Broadcom Blutonium firmware driver ver 1.2
usbcore: registered new interface driver bcm203x
Bluetooth: Digianswer Bluetooth USB driver ver 0.10
usbcore: registered new interface driver bpa10x
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
usb 1-1: uevent
usb 1-1: usb_probe_device
usb 1-1: configuration #1 chosen from 1 choice
usb 1-1: adding 1-1:1.0 (config #1, interface 0)
usb 1-1:1.0: uevent
hub 1-1:1.0: usb_probe_interface
hub 1-1:1.0: usb_probe_interface - got id
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
hub 1-1:1.0: standalone hub
hub 1-1:1.0: individual port power switching
hub 1-1:1.0: individual port over-current protection
hub 1-1:1.0: Single TT
hub 1-1:1.0: TT requires at most 16 FS bit times (1332 ns)
hub 1-1:1.0: Port indicators are supported
hub 1-1:1.0: power on to power good time: 100ms
hub 1-1:1.0: local power source is good
hub 1-1:1.0: enabling power on all ports
drivers/usb/core/inode.c: creating file '002'
usb 1-1: New USB device found, idVendor=0409, idProduct=005a
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002
hub 1-0:1.0: port 1 enable change, status 00000503
hub 2-0:1.0: state 7 ports 3 chg 0000 evt 0000
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
Advanced Linux Sound Architecture Driver Version 1.0.18rc3.
hub 1-1:1.0: port 4: status 0101 change 0001
usbcore: registered new interface driver snd-usb-audio
ASoC version 0.13.2
overo SoC init
TWL4030 Audio Codec init
asoc: twl4030 <-> omap-mcbsp-dai-(link_id) mapping ok
ALSA device list:
  #0: overo (twl4030)
oprofile: using arm/armv7
TCP cubic registered
NET: Registered protocol family 17
NET: Registered protocol family 15
Bluetooth: L2CAP ver 2.11
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO (Voice Link) ver 0.6
Bluetooth: SCO socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.10
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
ieee80211: 802.11 data/management/control stack, git-1.1.13
ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>
ieee80211_crypt: registered algorithm 'NULL'
ieee80211_crypt: registered algorithm 'WEP'
ieee80211_crypt: registered algorithm 'CCMP'
ieee80211_crypt: registered algorithm 'TKIP'
ThumbEE CPU extension supported.
Power Management for TI OMAP3.
hub 1-1:1.0: state 7 ports 4 chg 0010 evt 0000
hub 1-1:1.0: port 4, status 0101, change 0000, 12 Mb/s
SmartReflex driver initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
twl4030_rtc twl4030_rtc: setting system clock to 2008-12-11 21:41:45
UTC (1229031705)
Waiting for root device /dev/mmcblk0p2...
usb 1-1.4: new full speed USB device using musb_hdrc and address 3
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new SD card at address ee21
mmcblk0: mmc0:ee21 SU02G 1.89 GiB
 mmcblk0: p1 p2
usb 1-1.4: ep0 maxpacket = 8
usb 1-1.4: uevent
usb 1-1.4: usb_probe_device
usb 1-1.4: configuration #1 chosen from 1 choice
usb 1-1.4: adding 1-1.4:1.0 (config #1, interface 0)
usb 1-1.4:1.0: uevent
hub 1-1.4:1.0: usb_probe_interface
hub 1-1.4:1.0: usb_probe_interface - got id
hub 1-1.4:1.0: USB hub found
hub 1-1.4:1.0: 4 ports detected
hub 1-1.4:1.0: standalone hub
hub 1-1.4:1.0: individual port power switching
hub 1-1.4:1.0: individual port over-current protection
hub 1-1.4:1.0: power on to power good time: 100ms
hub 1-1.4:1.0: local power source is good
hub 1-1.4:1.0: enabling power on all ports
drivers/usb/core/inode.c: creating file '003'
usb 1-1.4: New USB device found, idVendor=0557, idProduct=7000
usb 1-1.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
mmc1: new SDIO card at address 0001
hub 1-1.4:1.0: port 1: status 0301 change 0001
hub 1-1.4:1.0: state 7 ports 4 chg 0002 evt 0000
hub 1-1.4:1.0: port 1, status 0301, change 0000, 1.5 Mb/s
usb 1-1.4.1: new low speed USB device using musb_hdrc and address 4
usb 1-1.4.1: skipped 1 descriptor after interface
usb 1-1.4.1: skipped 1 descriptor after interface
usb 1-1.4.1: skipped 1 descriptor after interface
usb 1-1.4.1: default language 0x0409
usb 1-1.4.1: uevent
usb 1-1.4.1: usb_probe_device
usb 1-1.4.1: configuration #1 chosen from 1 choice
usb 1-1.4.1: adding 1-1.4.1:1.0 (config #1, interface 0)
usb 1-1.4.1:1.0: uevent
usbhid 1-1.4.1:1.0: usb_probe_interface
usbhid 1-1.4.1:1.0: usb_probe_interface - got id
input: BTC USB Multimedia Cordless Kit as /class/input/input1
generic-usb 0003:046E:5520.0001: input: USB HID v1.10 Keyboard [BTC
USB Multimedia Cordless Kit] on usb-musb_hdrc-1.4.1/input0
usb 1-1.4.1: adding 1-1.4.1:1.1 (config #1, interface 1)
usb 1-1.4.1:1.1: uevent
usbhid 1-1.4.1:1.1: usb_probe_interface
usbhid 1-1.4.1:1.1: usb_probe_interface - got id
generic-usb 0003:046E:5520.0002: claimed by neither input, hiddev nor hidraw
usb 1-1.4.1: adding 1-1.4.1:1.2 (config #1, interface 2)
usb 1-1.4.1:1.2: uevent
usbhid 1-1.4.1:1.2: usb_probe_interface
usbhid 1-1.4.1:1.2: usb_probe_interface - got id
generic-usb 0003:046E:5520.0003: claimed by neither input, hiddev nor hidraw
kjournald starting.  Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on mmcblk0p2, internal journal
EXT3-fs: recovery complete.
drivers/usb/core/inode.c: creating file '004'
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem).
Freeing init memory: 920K
usb 1-1.4.1: New USB device found, idVendor=046e, idProduct=5520
usb 1-1.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.4.1: Product: USB Multimedia Cordless Kit
usb 1-1.4.1: Manufacturer: BTC
udevd version 124 started
usb usb2: uevent
usb 2-0:1.0: uevent
usb usb1: uevent
usb 1-0:1.0: uevent
usb 1-1: uevent
usb 1-1.4: uevent
usb 1-1.4.1: uevent
usb 1-1.4.1:1.0: uevent
usb 1-1.4.1:1.1: uevent
usb 1-1.4.1:1.2: uevent
usb 1-1.4:1.0: uevent
usb 1-1:1.0: uevent
hub 2-0:1.0: hub_suspend
usb usb2: bus auto-suspend
ehci-omap ehci-omap.0: suspend root hub
end_request: I/O error, dev mtdblock0, sector 0
Buffer I/O error on device mtdblock0, logical block 0
uncorrectable error : <3>end_request: I/O error, dev mtdblock0, sector 8
Buffer I/O error on device mtdblock0, logical block 1
uncorrectable error : <3>end_request: I/O error, dev mtdblock0, sector 16
Buffer I/O error on device mtdblock0, logical block 2
end_request: I/O error, dev mtdblock0, sector 24
Buffer I/O error on device mtdblock0, logical block 3
end_request: I/O error, dev mtdblock0, sector 0
Buffer I/O error on device mtdblock0, logical block 0
libertas_sdio: Libertas SDIO driver
libertas_sdio: Copyright Pierre Ossman
libertas_sdio mmc1:0001:1: firmware: requesting sd8686_helper.bin
libertas_sdio mmc1:0001:1: firmware: requesting sd8686.bin
NET: Registered protocol family 10
libertas: 00:19:88:05:96:ca, fw 9.70.3p24, cap 0x00000303
ADDRCONF(NETDEV_UP): eth0: link is not ready
libertas: PREP_CMD: command 0x00a3 failed: 2
libertas: PREP_CMD: command 0x00a3 failed: 2
libertas: eth0: Marvell WLAN 802.11 adapter
usb usb2: usb auto-resume
ehci-omap ehci-omap.0: resume root hub
hub 2-0:1.0: hub_resume
hub 2-0:1.0: state 7 ports 3 chg 0000 evt 0000
hub 2-0:1.0: hub_suspend
usb usb2: bus auto-suspend
ehci-omap ehci-omap.0: suspend root hub

Re: status of USB on omap35xx ?

[David Brownell]

On Thursday 11 December 2008, Steve Sakoman wrote:
> Sadly my ehci port still goes into auto suspend.

And that's a problem ... why?  It's not supposed to
do that unless all the child devices are either
gone, or suspended.  The log you showed had them
all suspended, I believe...

- Dave

Re: status of USB on omap35xx ?

[Grazvydas Ignotas]

On Thu, Dec 11, 2008 at 11:07 PM, Paul Walmsley <paul@booyaka.com> wrote:
> Gravyzdas, can you send us a commit ID that results in successful device
> enumeration (after reverting
> http://marc.info/?l=linux-omap&m=122453174024860&w=2 ?)  Sounds like it
> was working for you in late October with that revert.

There is no need to - EHCI works (almost) fine on pandora with current HEAD.

> Sadly my ehci port still goes into auto suspend.  I've attached the
> output of dmesg.  Can you take a look and see at what point my ehci
> messages diverge from what you see?

I'm also getting suspend/resume related problems if I plug a hub
without any devices connected (29sec), and then a device (52sec):

[   22.324002] Freeing init memory: 136K
[   22.455317] mmc0: new SD card at address 8001
[   22.480738] mmcblk0: mmc0:8001 SD512 483 MiB (ro)
[   22.485743]  mmcblk0: p1 p2 p3 < p5 >
[   23.457061] hub 1-0:1.0: hub_suspend
[   23.457122] usb usb1: bus auto-suspend
[   23.457122] ehci-omap ehci-omap.0: suspend root hub
[   23.457457] hub 2-0:1.0: hub_suspend
[   23.457488] usb usb2: bus auto-suspend
[   29.576384] usb usb1: usb resume
[   29.576415] ehci-omap ehci-omap.0: resume root hub
[   29.620879] hub 1-0:1.0: hub_resume
[   29.620940] ehci-omap ehci-omap.0: GetStatus port 2 status 001803
POWER sig=j CSC CONNECT
[   29.620970] hub 1-0:1.0: port 2: status 0501 change 0001
[   29.730345] hub 1-0:1.0: state 7 ports 3 chg 0004 evt 0000
[   29.730376] hub 1-0:1.0: port 2, status 0501, change 0000, 480 Mb/s
[   29.792845] ehci-omap ehci-omap.0: port 2 high speed
[   29.792876] ehci-omap ehci-omap.0: GetStatus port 2 status 001005
POWER sig=se0 PE CONNECT
[   29.855315] usb 1-2: new high speed USB device using ehci-omap and address 2
[   29.917723] ehci-omap ehci-omap.0: port 2 high speed
[   29.917723] ehci-omap ehci-omap.0: GetStatus port 2 status 001005
POWER sig=se0 PE CONNECT
[   30.012968] usb 1-2: default language 0x0409
[   30.013761] usb 1-2: uevent
[   30.022152] usb 1-2: usb_probe_device
[   30.022183] usb 1-2: configuration #1 chosen from 1 choice
[   30.028102] usb 1-2: adding 1-2:1.0 (config #1, interface 0)
[   30.028316] usb 1-2:1.0: uevent
[   30.034084] hub 1-2:1.0: usb_probe_interface
[   30.034114] hub 1-2:1.0: usb_probe_interface - got id
[   30.034114] hub 1-2:1.0: USB hub found
[   30.038355] hub 1-2:1.0: 4 ports detected
[   30.042384] hub 1-2:1.0: standalone hub
[   30.042414] hub 1-2:1.0: ganged power switching
[   30.042414] hub 1-2:1.0: global over-current protection
[   30.042445] hub 1-2:1.0: Single TT
[   30.042445] hub 1-2:1.0: TT requires at most 32 FS bit times (2664 ns)
[   30.042475] hub 1-2:1.0: Port indicators are supported
[   30.042475] hub 1-2:1.0: power on to power good time: 100ms
[   30.043089] hub 1-2:1.0: local power source is good
[   30.043089] hub 1-2:1.0: no over-current condition exists
[   30.043120] hub 1-2:1.0: enabling power on all ports
[   30.062010] drivers/usb/core/inode.c: creating file '002'
[   30.070952] usb 1-2: New USB device found, idVendor=05e3, idProduct=0608
[   30.077788] usb 1-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[   30.085021] usb 1-2: Product: USB2.0 Hub
[   30.145781] usb 1-2: link qh256-0001/ffa00100 start 255 [1/0 us]
[   30.145842] hub 1-2:1.0: state 7 ports 4 chg 0000 evt 0000
[   32.457060] hub 1-2:1.0: hub_suspend
[   32.457091] usb 1-2: unlink qh256-0001/ffa00100 start 255 [1/0 us]
[   32.457518] usb 1-2: usb auto-suspend
[   34.480192] hub 1-0:1.0: hub_suspend
[   34.480223] usb usb1: bus auto-suspend
[   34.480254] ehci-omap ehci-omap.0: suspend root hub
[   52.507176] ehci-omap ehci-omap.0: port 2 remote wakeup
[   52.507237] usb usb1: usb resume
[   52.507237] ehci-omap ehci-omap.0: resume root hub
[   52.558339] hub 1-0:1.0: hub_resume
[   52.558400] ehci-omap ehci-omap.0: GetStatus port 2 status 001005
POWER sig=se0 PE CONNECT
[   52.558431] hub 1-0:1.0: port 2: status 0503 change 0004
[   52.558461] hub 1-0:1.0: state 7 ports 3 chg 0004 evt 0000
[   52.558522] ehci-omap ehci-omap.0: GetStatus port 2 status 001809
POWER sig=j PEC CONNECT
[   52.558553] usb 1-2: usb wakeup-resume
[   52.558583] usb 1-2: finish reset-resume
[   52.620868] ehci-omap ehci-omap.0: port 2 full speed --> companion
[   52.620898] ehci-omap ehci-omap.0: GetStatus port 2 status 003801
POWER OWNER sig=j CONNECT
[   52.620929] hub 1-0:1.0: port 2 not reset yet, waiting 50ms
[   52.683429] ehci-omap ehci-omap.0: GetStatus port 2 status 003002
POWER OWNER sig=se0 CSC
[   52.683459] hub 1-0:1.0: logical disconnect on port 2
[   52.683490] usb 1-2: gone after usb resume? status -19
[   52.683490] usb 1-2: can't resume, status -19
[   52.683520] hub 1-0:1.0: logical disconnect on port 2
[   52.683551] hub 1-0:1.0: resume on port 2, status -19
[   52.683551] hub 1-0:1.0: port 2, status 0501, change 0006, 480 Mb/s
[   52.683581] usb 1-2: USB disconnect, address 2
[   52.688037] usb 1-2: unregistering device
[   52.688068] usb 1-2: usb_disable_device nuking all URBs
[   52.688068] usb 1-2: unregistering interface 1-2:1.0
[   52.696641] usb 1-2:1.0: uevent
[   52.720508] usb 1-2: uevent
[   52.878711] hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms
status 0x100
[   52.878741] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0004
[   55.456891] hub 1-0:1.0: hub_suspend
[   55.456921] usb usb1: bus auto-suspend
[   55.456952] ehci-omap ehci-omap.0: suspend root hub

After that kernel no longer reacts to any replugs (both device-hub and
hub-board).

But if I first plug some device to my ext hub, and then hub to
pandora, everything goes fine (on fresh boot, not after "suspend root
hub" problem above):
[   22.323209] Freeing init memory: 136K
[   22.454890] mmc0: new SD card at address 8001
[   22.480616] mmcblk0: mmc0:8001 SD512 483 MiB (ro)
[   22.485651]  mmcblk0: p1 p2 p3 < p5 >
[   23.456938] hub 1-0:1.0: hub_suspend
[   23.456999] usb usb1: bus auto-suspend
[   23.456999] ehci-omap ehci-omap.0: suspend root hub
[   23.457183] hub 2-0:1.0: hub_suspend
[   23.457213] usb usb2: bus auto-suspend
[   37.455616] usb usb1: usb resume
[   37.455647] ehci-omap ehci-omap.0: resume root hub
[   37.503489] hub 1-0:1.0: hub_resume
[   37.503580] ehci-omap ehci-omap.0: GetStatus port 2 status 001803
POWER sig=j CSC CONNECT
[   37.503611] hub 1-0:1.0: port 2: status 0501 change 0001
[   37.613023] hub 1-0:1.0: state 7 ports 3 chg 0004 evt 0000
[   37.613054] hub 1-0:1.0: port 2, status 0501, change 0000, 480 Mb/s
[   37.675523] ehci-omap ehci-omap.0: port 2 high speed
[   37.675554] ehci-omap ehci-omap.0: GetStatus port 2 status 001005
POWER sig=se0 PE CONNECT
[   37.737993] usb 1-2: new high speed USB device using ehci-omap and address 2
[   37.800372] ehci-omap ehci-omap.0: port 2 high speed
[   37.800372] ehci-omap ehci-omap.0: GetStatus port 2 status 001005
POWER sig=se0 PE CONNECT
[   37.895586] usb 1-2: default language 0x0409
[   37.896379] usb 1-2: uevent
[   37.904862] usb 1-2: usb_probe_device
[   37.904862] usb 1-2: configuration #1 chosen from 1 choice
[   37.910844] usb 1-2: adding 1-2:1.0 (config #1, interface 0)
[   37.911058] usb 1-2:1.0: uevent
[   37.916856] hub 1-2:1.0: usb_probe_interface
[   37.916856] hub 1-2:1.0: usb_probe_interface - got id
[   37.916887] hub 1-2:1.0: USB hub found
[   37.921219] hub 1-2:1.0: 4 ports detected
[   37.925247] hub 1-2:1.0: standalone hub
[   37.925278] hub 1-2:1.0: ganged power switching
[   37.925278] hub 1-2:1.0: global over-current protection
[   37.925278] hub 1-2:1.0: Single TT
[   37.925308] hub 1-2:1.0: TT requires at most 32 FS bit times (2664 ns)
[   37.925308] hub 1-2:1.0: Port indicators are supported
[   37.925371] hub 1-2:1.0: power on to power good time: 100ms
[   37.925951] hub 1-2:1.0: local power source is good
[   37.925951] hub 1-2:1.0: no over-current condition exists
[   37.925981] hub 1-2:1.0: enabling power on all ports
[   37.944902] drivers/usb/core/inode.c: creating file '002'
[   37.953812] usb 1-2: New USB device found, idVendor=05e3, idProduct=0608
[   37.960649] usb 1-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[   37.967880] usb 1-2: Product: USB2.0 Hub
[   38.028458] hub 1-2:1.0: port 4: status 0301 change 0001
[   38.128525] usb 1-2: link qh256-0001/ffa00100 start 255 [1/0 us]
[   38.128586] hub 1-2:1.0: state 7 ports 4 chg 0010 evt 0000
[   38.128983] hub 1-2:1.0: port 4, status 0301, change 0000, 1.5 Mb/s
[   38.214829] usb 1-2.4: new low speed USB device using ehci-omap and address 3
[   38.353499] usb 1-2.4: skipped 1 descriptor after interface
[   38.353530] usb 1-2.4: skipped 1 descriptor after interface
[   38.355086] usb 1-2.4: default language 0x0409
[   38.365371] usb 1-2.4: uevent
[   38.373671] usb 1-2.4: usb_probe_device
[   38.373671] usb 1-2.4: configuration #1 chosen from 1 choice
[   38.380873] usb 1-2.4: adding 1-2.4:1.0 (config #1, interface 0)
[   38.381057] usb 1-2.4:1.0: uevent
[   38.386489] usbhid 1-2.4:1.0: usb_probe_interface
[   38.386519] usbhid 1-2.4:1.0: usb_probe_interface - got id
[   38.412214] input: Logitech HID compliant keyboard as /class/input/input1
[   38.448925] usb 1-2.4: link qh8-0601/ffa00200 start 7 [1/2 us]
[   38.480204] generic-usb 0003:046D:C30E.0001: input: USB HID v1.10
Keyboard [Logitech HID compliant keyboard] on usb-ehci-omap.0-2.4/inp0
[   38.516274] usb 1-2.4: adding 1-2.4:1.1 (config #1, interface 1)
[   38.516487] usb 1-2.4:1.1: uevent
[   38.523108] usbhid 1-2.4:1.1: usb_probe_interface
[   38.523139] usbhid 1-2.4:1.1: usb_probe_interface - got id
[   38.557554] input: Logitech HID compliant keyboard as /class/input/input2
[   38.589750] usb 1-2.4: link qh8-3008/ffa00280 start 7 [1/2 us]
[   38.620848] generic-usb 0003:046D:C30E.0002: input: USB HID v1.10
Device [Logitech HID compliant keyboard] on usb-ehci-omap.0-2.4/input1
[   38.666289] drivers/usb/core/inode.c: creating file '003'
[   38.675230] usb 1-2.4: New USB device found, idVendor=046d, idProduct=c30e
[   38.682219] usb 1-2.4: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[   38.689665] usb 1-2.4: Product: HID compliant keyboard
[   38.694852] usb 1-2.4: Manufacturer: Logitech
[   38.699277] hub 1-2:1.0: state 7 ports 4 chg 0000 evt 0010

Curiously at this point I can plug/unplug to my ext hub any additional
devices as much as I want, as long as I keep the first device plugged.
If I unplug all devices from ext hub, I get suspend and kernel no
longer reacts to any replugs.

Re: status of USB on omap35xx ?

[Paul Walmsley]

Hello Grazvydas,

On Fri, 12 Dec 2008, Grazvydas Ignotas wrote:

> On Thu, Dec 11, 2008 at 11:07 PM, Paul Walmsley <paul@booyaka.com> wrote:
> > Gravyzdas, can you send us a commit ID that results in successful device
> > enumeration (after reverting
> > http://marc.info/?l=linux-omap&m=122453174024860&w=2 ?)  Sounds like it
> > was working for you in late October with that revert.
> 
> There is no need to - EHCI works (almost) fine on pandora with current HEAD.

Might you be willing to try a build with the first two patches
from this series posted earlier today with the subject:

[PATCH 0/3 NOT FOR MERGING] ehci-omap clock rewrite test patches

and see if things still almost work?  If so, then we can get the nasty
direct CM writes out of that driver.

> I'm also getting suspend/resume related problems if I plug a hub
> without any devices connected (29sec), and then a device (52sec):

If you disable USB autosuspend with no devices connected via

echo -1 > /sys/module/usbcore/parameters/autosuspend

and then repeat the same test as above, do your devices stay alive?


- Paul

Re: status of USB on omap35xx ?

[Tony Lindgren]

* Steve Sakoman <sakoman@gmail.com> [081211 13:54]:
> On Thu, Dec 11, 2008 at 12:41 PM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> > On Thu, Dec 11, 2008 at 7:38 PM, Steve Sakoman <sakoman@gmail.com> wrote:
> >> On Thu, Dec 11, 2008 at 8:49 AM, Paul Walmsley <paul@booyaka.com> wrote:
> >>> Hi Grazvydas, Steve,
> >>>
> >>> On Thu, 11 Dec 2008, Grazvydas Ignotas wrote:
> >>>
> >>>> > Can you please post whatever patches you need to apply to make it work
> >>>> > occasionally so others can also look at the issue?
> >>>>
> >>>> For pandora, making infinite while loops finite doesn't help much,
> >>>> kernel crashes later on. Steve had this too:
> >>>> http://marc.info/?l=linux-omap&m=122378604027303&w=2
> >>>>
> >>>> I did bisect and found that commit
> >>>> 8b1f0bd44fe490ec631230c8c040753a2bda8caa is causing the hang for me.
> >>>> Reverting this makes EHCI work again on pandora.
> >>>> http://marc.info/?l=linux-omap&m=122453174024860&w=2
> >>>
> >>> Would one of you be willing to run with this patch and send back any debug
> >>> output relating to dpll5_ck ?  (Unfortunately, I don't have access to any
> >>> boards with EHCI hardware, so cannot try it myself)
> >>>
> >>> This will help determine what fix should be applied
> >>
> >> Here you go.  Note that no infinite loop!
> >
> > Ah, so it no longer needs that revert, probably recent clock changes
> > fixed that issue.
> >
> >> ...
> >> Result: no hang at boot, but I still end up with the auto suspend,
> >> though the behavior is slightly different (dmesg output this time
> >> since it contains more debug info):
> >
> > If your host uses PHY mode, have you hacked EXT_PHY_RESET_GPIO* in
> > drivers/usb/host/ehci-omap.c? BTW, if this stuff is really needed, it
> > should go to platform_data..
> 
> I have hacked in the reset GPIO used on Overo.  I agree -- board
> specific stuff has no place in ehci-omap, it really should be platform
> data.

What's the patch you have for the GPIO? At least I don't seem to get
any VBUS on overo EHCI port.

<snip>

Regards,

Tony

Re: status of USB on omap35xx ?

[David Brownell]

On Thursday 11 December 2008, Grazvydas Ignotas wrote:
> Curiously at this point I can plug/unplug to my ext hub any additional
> devices as much as I want, as long as I keep the first device plugged.
> If I unplug all devices from ext hub, I get suspend and kernel no
> longer reacts to any replugs.

Sounds like one issue might be that EHCI isn't waking up the
way it should, when it gets "remote wakeup" signaling from USB.

The USB host drivers go to some effort to put themselves in as
low a runtime power state as practical, and rely on the hardware
to wake up given events like insertion/removal of an external
device, or the downstream device issuing wakeup signaling (e.g.
press a key on a keyboard that went to sleep).

OMAP has been known to need special attention to kick in such
wakeup mechanisms.  Maybe this is another such case.

- Dave

Re: status of USB on omap35xx ?

[Grazvydas Ignotas]

On Fri, Dec 12, 2008 at 1:09 AM, Paul Walmsley <paul@pwsan.com> wrote:
> Hello Grazvydas,
>
> On Fri, 12 Dec 2008, Grazvydas Ignotas wrote:
>
>> On Thu, Dec 11, 2008 at 11:07 PM, Paul Walmsley <paul@booyaka.com> wrote:
>> > Gravyzdas, can you send us a commit ID that results in successful device
>> > enumeration (after reverting
>> > http://marc.info/?l=linux-omap&m=122453174024860&w=2 ?)  Sounds like it
>> > was working for you in late October with that revert.
>>
>> There is no need to - EHCI works (almost) fine on pandora with current HEAD.
>
> Might you be willing to try a build with the first two patches
> from this series posted earlier today with the subject:
>
> [PATCH 0/3 NOT FOR MERGING] ehci-omap clock rewrite test patches
>
> and see if things still almost work?  If so, then we can get the nasty
> direct CM writes out of that driver.
Yes, with those it works exactly as without them (at least I haven't
noticed any difference).

>> I'm also getting suspend/resume related problems if I plug a hub
>> without any devices connected (29sec), and then a device (52sec):
>
> If you disable USB autosuspend with no devices connected via
>
> echo -1 > /sys/module/usbcore/parameters/autosuspend
>
> and then repeat the same test as above, do your devices stay alive?
Yep, this seems to resolve that issue, I can plug the devices any way
I want with this. Thanks for showing this.

On Fri, Dec 12, 2008 at 7:59 PM, Steve Sakoman <sakoman@gmail.com> wrote:
> On Thu, Dec 11, 2008 at 12:41 PM, Grazvydas Ignotas <notasas@gmail.com> wrote:
>
>> If your host uses PHY mode, have you hacked EXT_PHY_RESET_GPIO* in
>> drivers/usb/host/ehci-omap.c? BTW, if this stuff is really needed, it
>> should go to platform_data..
>
> What PHY chip are you using on Pandora?
>
> From the schematic it appears that Gumstix is using USB3320.
>
> I'm really puzzled by the difference in behavior :-(
Unfortunately I don't know, will need to ask out hardware designer.
The chip is so small that I can't see any markings on it.

Does your PHY chip heat? There was actually a similar problem with
rev2 pandora boards, where it would not detect devices and that tiny
PHY chip would heat really badly. It later turned out to be a bad
batch of PHY chips, so after switching to another and reflowing the
boards USB would work fine (almost, with issues above).

Re: status of USB on omap35xx ?

[Paul Walmsley]

Hello Vikram,

On Fri, 12 Dec 2008, Grazvydas Ignotas wrote:

> On Fri, Dec 12, 2008 at 1:09 AM, Paul Walmsley <paul@pwsan.com> wrote:
> > On Fri, 12 Dec 2008, Grazvydas Ignotas wrote:
> 
> >> I'm also getting suspend/resume related problems if I plug a hub
> >> without any devices connected (29sec), and then a device (52sec):
> >
> > If you disable USB autosuspend with no devices connected via
> >
> > echo -1 > /sys/module/usbcore/parameters/autosuspend
> >
> > and then repeat the same test as above, do your devices stay alive?
> Yep, this seems to resolve that issue, I can plug the devices any way
> I want with this. Thanks for showing this.

Were you able to get USB remote wakeup or auto-suspend working on
ehci-omap.c with the 3430SDP?


- Paul

Re: status of USB on omap35xx ?

[Steve Sakoman]

On Fri, Dec 12, 2008 at 12:15 PM, Grazvydas Ignotas <notasas@gmail.com> wrote:

> On Fri, Dec 12, 2008 at 7:59 PM, Steve Sakoman <sakoman@gmail.com> wrote:
>> What PHY chip are you using on Pandora?
>>
>> From the schematic it appears that Gumstix is using USB3320.

I misread the markings, it is USB3326

>> I'm really puzzled by the difference in behavior :-(
> Unfortunately I don't know, will need to ask out hardware designer.
> The chip is so small that I can't see any markings on it.

No kidding!

> Does your PHY chip heat? There was actually a similar problem with
> rev2 pandora boards, where it would not detect devices and that tiny
> PHY chip would heat really badly. It later turned out to be a bad
> batch of PHY chips, so after switching to another and reflowing the
> boards USB would work fine (almost, with issues above).

No, the chip is cool.  I just reviewed the schematic with data sheet
in hand and it certainly looks like everything is connected properly.

I also compared our u-boot pinmux setup with pandora and we are
identical there.

The mystery deepens . . .

Steve

RE: status of USB on omap35xx ?

[Pandita, Vikram]

Paul

>-----Original Message-----
>From: Paul Walmsley [mailto:paul@pwsan.com]
>Sent: Friday, December 12, 2008 2:33 PM
>To: Pandita, Vikram
>Cc: Grazvydas Ignotas; Steve Sakoman; Tony Lindgren; David Brownell; me@felipebalbi.com; Jeff Steele;
>linux-omap
>Subject: Re: status of USB on omap35xx ?
>
>Hello Vikram,
>
>On Fri, 12 Dec 2008, Grazvydas Ignotas wrote:
>
>> On Fri, Dec 12, 2008 at 1:09 AM, Paul Walmsley <paul@pwsan.com> wrote:
>> > On Fri, 12 Dec 2008, Grazvydas Ignotas wrote:
>>
>> >> I'm also getting suspend/resume related problems if I plug a hub
>> >> without any devices connected (29sec), and then a device (52sec):
>> >
>> > If you disable USB autosuspend with no devices connected via
>> >
>> > echo -1 > /sys/module/usbcore/parameters/autosuspend
>> >
>> > and then repeat the same test as above, do your devices stay alive?
>> Yep, this seems to resolve that issue, I can plug the devices any way
>> I want with this. Thanks for showing this.
>
>Were you able to get USB remote wakeup or auto-suspend working on
>ehci-omap.c with the 3430SDP?

For remote-wakeup: 
There was a long discussion with USBHOST IP vendor. We were observing a device disconnect on a remote-wakeup as well as host initiated wakeup.

It turned out to be an issue with the IP block and will be fixed in 3430 ES3.1 finally.
And a software workaround for waiting for USB micro frame boundary. 
Now the workaround has been done in USB EHCI stack code which is not the best way ... 

Take a look at Zoom GIT tree for the reference implementation: 
http://git.omapzoom.com/?p=omapkernel.git;a=commitdiff;h=baa196583f4af08d15da0389fed8f9005b0f812d

RE: status of USB on omap35xx ?

[Paul Walmsley]

Hello Vikram,

On Sat, 13 Dec 2008, Pandita, Vikram wrote:

> >From: Paul Walmsley [mailto:paul@pwsan.com]
> >
> >Were you able to get USB remote wakeup or auto-suspend working on
> >ehci-omap.c with the 3430SDP?
> 
> For remote-wakeup: 
> There was a long discussion with USBHOST IP vendor. We were observing a device disconnect on a remote-wakeup as well as host initiated wakeup.
> 
> It turned out to be an issue with the IP block and will be fixed in 3430 ES3.1 finally.
> And a software workaround for waiting for USB micro frame boundary. 
> Now the workaround has been done in USB EHCI stack code which is not the best way ... 
> 
> Take a look at Zoom GIT tree for the reference implementation: 
> http://git.omapzoom.com/?p=omapkernel.git;a=commitdiff;h=baa196583f4af08d15da0389fed8f9005b0f812d

Thanks for the info; that's quite helpful.  Do you happen to know if there 
are any projects ongoing inside TI to send patches for the existing 
ehci-omap.c driver in linux-omap?


- Paul

RE: status of USB on omap35xx ?

[Pandita, Vikram]

>-----Original Message-----
>From: Paul Walmsley [mailto:paul@pwsan.com]
>Sent: Friday, December 12, 2008 3:13 PM
>To: Pandita, Vikram
>Cc: Grazvydas Ignotas; Steve Sakoman; Tony Lindgren; David Brownell; me@felipebalbi.com; Kridner,
>Jason; sakari.poussa@nokia.com; Jeff Steele; linux-omap
>Subject: RE: status of USB on omap35xx ?
>
>Hello Vikram,
>
>On Sat, 13 Dec 2008, Pandita, Vikram wrote:
>
>> >From: Paul Walmsley [mailto:paul@pwsan.com]
>> >
>> >Were you able to get USB remote wakeup or auto-suspend working on
>> >ehci-omap.c with the 3430SDP?
>>
>> For remote-wakeup:
>> There was a long discussion with USBHOST IP vendor. We were observing a device disconnect on a
>remote-wakeup as well as host initiated wakeup.
>>
>> It turned out to be an issue with the IP block and will be fixed in 3430 ES3.1 finally.
>> And a software workaround for waiting for USB micro frame boundary.
>> Now the workaround has been done in USB EHCI stack code which is not the best way ...
>>
>> Take a look at Zoom GIT tree for the reference implementation:
>> http://git.omapzoom.com/?p=omapkernel.git;a=commitdiff;h=baa196583f4af08d15da0389fed8f9005b0f812d
>
>Thanks for the info; that's quite helpful.  Do you happen to know if there
>are any projects ongoing inside TI to send patches for the existing
>ehci-omap.c driver in linux-omap?

It should be submitted to usb tree and that activity will start soon.

>
>
>- Paul

Re: status of USB on omap35xx ?

[Grazvydas Ignotas]

On Fri, Dec 12, 2008 at 10:35 PM, Steve Sakoman <sakoman@gmail.com> wrote:
> On Fri, Dec 12, 2008 at 12:15 PM, Grazvydas Ignotas <notasas@gmail.com> wrote:
>
>> On Fri, Dec 12, 2008 at 7:59 PM, Steve Sakoman <sakoman@gmail.com> wrote:
>>> What PHY chip are you using on Pandora?
>>>
>>> From the schematic it appears that Gumstix is using USB3320.
>
> I misread the markings, it is USB3326

I've received a response from our hardware designer:

The USB3326 is garbage.  That is the chip that was overheating for us on
these rev2 boards.  Tell them to switch to the USB3322 like Pandora and
Beagle now officially use. ;)  The Beagle had issues on the 26 as well.

:-D

RE: status of USB on omap35xx ?

[Gadiyar, Anand]

> Hello Vikram,
> 
> On Sat, 13 Dec 2008, Pandita, Vikram wrote:
> 
> > >From: Paul Walmsley [mailto:paul@pwsan.com]
> > >
> > >Were you able to get USB remote wakeup or auto-suspend working on
> > >ehci-omap.c with the 3430SDP?
> > 
> > For remote-wakeup: 
> > There was a long discussion with USBHOST IP vendor. We were observing a device disconnect on a remote-wakeup as well as host initiated wakeup.
> > 
> > It turned out to be an issue with the IP block and will be fixed in 3430 ES3.1 finally.
> > And a software workaround for waiting for USB micro frame boundary. 
> > Now the workaround has been done in USB EHCI stack code which is not the best way ... 
> > 
> > Take a look at Zoom GIT tree for the reference implementation: 
> > 
> http://git.omapzoom.com/?p=omapkernel.git;a=commitdiff;h=baa196583f4af08d15da0389fed8f9005b0f812d
> 
> Thanks for the info; that's quite helpful.  Do you happen to know if there 
> are any projects ongoing inside TI to send patches for the existing 
> ehci-omap.c driver in linux-omap?
> 
> 
> - Paul

Yes, but only if Tony will accept them. And he won't - it
will only increase the diff between linux-omap and mainline.

The EHCI driver should actually go to linux-usb. If you look
at the list archives, you will find that I had said I would
do that - ages ago. Unfortunately I have not been able to do
that so far. It's high on the priority list however.

Also, that reference patch is not complete either. It uses
ehci_get_frame() which returns the current frame number,
instead of the EHCI FrameIndex register value (which is all
we need - so we end up waiting longer). Also, it's a while
loop without a timeout, which is bad.

This patch does get EHCI suspend-resume working however, so
feel free to take it if you need it. It's a hack for now.

Re: status of USB on omap35xx ?

[Felipe Balbi]

Hi,

On Mon, Dec 22, 2008 at 03:55:26AM +0530, Anand Gadiyar wrote:
> The EHCI driver should actually go to linux-usb. If you look
> at the list archives, you will find that I had said I would
> do that - ages ago. Unfortunately I have not been able to do
> that so far. It's high on the priority list however.

Sure, but still we need some cleanups to EHCI driver before sending it
to linux-usb. Do you guys have plans to do that ? Unfortunately I don't
have hw to test it so that makes it difficult for me to patch ehci-omap

-- 
balbi