Skip to contentSkip to conversation

status of USB on omap35xx ?

DISCUSSION Jeff Steele 11 participants 32 messages Dec 10, 2008 – Dec 22, 2008

Subsystems (4)
Arm (32-bit) Arm sub-architectures OMAP2+ support OMAP clock framework support
lore
Share & tools
lore

Jeff Steele

author
#0 lore raw

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

#1 lore raw
Quoted 3 lines · ext Jeff Steele

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.

Quoted 2 lines

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

should be possible, they're different controllers.

Quoted 6 lines

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

Quoted 3 lines

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

Signature · 1 line
balbi
author
#2 lore raw
Quoted 5 lines · Felipe Balbi
Quoted 2 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#3 lore raw
Quoted 9 lines · Jeff Steele
Quoted 5 lines · Felipe Balbi
Quoted 2 lines

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

Quoted 5 lines

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.

Signature · 1 line
balbi
#4 lore raw

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

Quoted 2 lines · Felipe Balbi
Quoted 2 lines

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.

Quoted 3 lines

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

#5 lore raw
Quoted 9 lines · David Brownell

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

Signature · 1 line
balbi
#6 lore raw
Quoted 10 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Felipe Balbi
Sent: Wednesday, December 10, 2008 1:01 PM
To: David Brownell
Cc: [email protected]; Jeff Steele; linux-omap
Subject: Re: status of USB on omap35xx ?

Quoted 7 lines
Quoted 6 lines · David Brownell

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.

Quoted 7 lines
Quoted 3 lines

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

Quoted 13 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#7 lore raw
In reply to David Brownell
Quoted 11 lines · David Brownell

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

Quoted 2 lines · Felipe Balbi
Quoted 2 lines

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.

Quoted 9 lines

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.

Quoted 6 lines
Quoted 3 lines

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

maintainer
#8 lore raw
Quoted 43 lines · Steve Sakoman
Quoted 11 lines · David Brownell

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

Quoted 2 lines · Felipe Balbi
Quoted 2 lines

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.

Quoted 9 lines

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.

Quoted 6 lines
Quoted 3 lines

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.

Quoted 6 lines

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

Quoted 22 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#9 lore raw
Quoted 2 lines

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

#10 lore raw

Hi Grazvydas, Steve,

Quoted 11 lines · Grazvydas Ignotas
Quoted 2 lines

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(-)
arch/arm/mach-omap2/clock34xx.c +4 -0
index 2c655be..3b80667 100644
@@ -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
#11 lore raw
Quoted 16 lines · Paul Walmsley

Hi Grazvydas, Steve,

Quoted 11 lines · Grazvydas Ignotas
Quoted 2 lines

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

Quoted 5 lines

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

Quoted 28 lines

- 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(-)
arch/arm/mach-omap2/clock34xx.c +4 -0
index 2c655be..3b80667 100644
@@ -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
#12 lore raw
Quoted 17 lines · Steve Sakoman
Quoted 16 lines · Paul Walmsley

Hi Grazvydas, Steve,

Quoted 11 lines · Grazvydas Ignotas
Quoted 2 lines

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

Quoted 7 lines
Quoted 5 lines

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.

Quoted 4 lines

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

#13 lore raw
Quoted 5 lines · Grazvydas Ignotas
Quoted 1 line · Steve Sakoman

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

#14 lore raw
Quoted 4 lines · Paul Walmsley

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.

Quoted 3 lines

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.

maintainer
#15 lore raw

Hello Grazvydas,

Quoted 7 lines · Grazvydas Ignotas
Quoted 4 lines · Paul Walmsley

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.

Quoted 2 lines

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

#16 lore raw
Quoted 12 lines · Paul Walmsley

Hello Grazvydas,

Quoted 7 lines · Grazvydas Ignotas
Quoted 4 lines · Paul Walmsley

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.

Quoted 7 lines

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

Quoted 8 lines
Quoted 2 lines

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.

Quoted 11 lines · Steve Sakoman
Quoted 3 lines · Grazvydas Ignotas

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

maintainer
#17 lore raw

Hello Vikram,

Quoted 6 lines · Grazvydas Ignotas
Quoted 5 lines · Paul Walmsley
Quoted 2 lines · Grazvydas Ignotas

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

Quoted 7 lines
Quoted 5 lines

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

#18 lore raw

Paul

Quoted 20 lines

-----Original Message-----
From: Paul Walmsley [mailto:[email protected]]
Sent: Friday, December 12, 2008 2:33 PM
To: Pandita, Vikram
Cc: Grazvydas Ignotas; Steve Sakoman; Tony Lindgren; David Brownell; [email protected]; Jeff Steele; linux-omap
Subject: Re: status of USB on omap35xx ?

Hello Vikram,

Quoted 8 lines · Grazvydas Ignotas
Quoted 7 lines · Paul Walmsley
Quoted 2 lines · Grazvydas Ignotas

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

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

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

maintainer
#19 lore raw

Hello Vikram,

Quoted 8 lines · Vikram
Quoted 4 lines

From: Paul Walmsley [mailto:[email protected]]

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.

Quoted 6 lines

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

#20 lore raw
Quoted 27 lines

-----Original Message-----
From: Paul Walmsley [mailto:[email protected]]
Sent: Friday, December 12, 2008 3:13 PM
To: Pandita, Vikram
Cc: Grazvydas Ignotas; Steve Sakoman; Tony Lindgren; David Brownell; [email protected]; Kridner, Jason; [email protected]; Jeff Steele; linux-omap
Subject: RE: status of USB on omap35xx ?

Hello Vikram,

Quoted 7 lines · Vikram
Quoted 4 lines

From: Paul Walmsley [mailto:[email protected]]

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.

Quoted 5 lines

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

Quoted 6 lines
Quoted 2 lines

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.

Quoted 3 lines

- Paul

#21 lore raw
In reply to Paul Walmsley
Quoted 18 lines

Hello Vikram,

Quoted 5 lines · Vikram
Quoted 4 lines

From: Paul Walmsley [mailto:[email protected]]

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

Quoted 9 lines

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:

Quoted 8 lines

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.

#22 lore raw

Hi,

Quoted 4 lines · Anand Gadiyar

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

Signature · 1 line
balbi
#23 lore raw
In reply to Grazvydas Ignotas
Quoted 4 lines · Grazvydas Ignotas
Quoted 3 lines · Steve Sakoman

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

Quoted 3 lines
Quoted 1 line

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!

Quoted 5 lines

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

#24 lore raw
Quoted 8 lines · Steve Sakoman
Quoted 4 lines · Grazvydas Ignotas
Quoted 3 lines · Steve Sakoman

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

#25 lore raw
In reply to Grazvydas Ignotas
Quoted 4 lines · Grazvydas Ignotas

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

#26 lore raw
In reply to Grazvydas Ignotas
Quoted 29 lines · Grazvydas Ignotas
Quoted 17 lines · Steve Sakoman
Quoted 16 lines · Paul Walmsley

Hi Grazvydas, Steve,

Quoted 11 lines · Grazvydas Ignotas
Quoted 2 lines

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

Quoted 7 lines
Quoted 5 lines

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.

Quoted 8 lines
Quoted 4 lines

...
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 <[email protected]>
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
#27 lore raw
Quoted 1 line · Steve Sakoman

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

maintainer
#28 lore raw
In reply to Steve Sakoman
Quoted 35 lines · Steve Sakoman
Quoted 34 lines · Grazvydas Ignotas
Quoted 17 lines · Steve Sakoman
Quoted 16 lines · Paul Walmsley

Hi Grazvydas, Steve,

Quoted 11 lines · Grazvydas Ignotas
Quoted 2 lines

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

Quoted 7 lines
Quoted 5 lines

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.

Quoted 4 lines

...
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):

Quoted 7 lines
Quoted 3 lines

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

#29 lore raw
In reply to Grazvydas Ignotas
Quoted 12 lines · Grazvydas Ignotas
Quoted 2 lines

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:

arch/arm/mach-omap2/clock34xx.c +4 -2
@@ -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

maintainer
#30 lore raw

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);
#31 lore raw

Paul

Quoted 7 lines

-----Original Message-----
From: Paul Walmsley [mailto:[email protected]]
Sent: Thursday, December 11, 2008 12:15 PM
To: Pandita, Vikram
Cc: Steve Sakoman; Tony Lindgren; linux-omap; David Brownell; [email protected]; Jeff Steele
Subject: Re: status of USB on omap35xx ?

Quoted 6 lines

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.

Quoted 22 lines

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