Always got STALL in MUSB Host driver

Question Bryan Wu 4 participants 8 messages Nov 15, 2007 – Nov 19, 2007

Share & tools

Bryan Wu

author

2007-11-15 10:48 UTC #0 lore raw

Dear Tony and David,

I struggled in MUSB driver of Blackfin for a long time. Currently, usb device mode should be ok, but USB host mode driver still got weird response.

Blackfin BF54x USB OTG contoller is a single port OTG controller, which has EP0 to EP7 8 bi-directional endpoints. And EP0 FIFO size is 64 x 2, EP1 to EP4 FIFO size is 128 x 2 and EP5 to EP7 is 1024 x 2, totally 7232 bytes. So EP5 is selected as musb->bulk_ep.

Double buffering is automatically as Hardware manual said:

"Each endpoint FIFO can buffer one or two packets (in double-buffered mode). The double buffered mode is automatically enabled when the soft- ware programs a maximum packet size for an endpoint that is less than half the actual FIFO size for that endpoint. Double-buffering is recom- mended for most applications to improve efficiency by reducing the frequency with which each endpoint needs to be serviced."

I noticed the comments of musb_host.c:
"+ double buffered OUT/TX endpoints saw stalls(!) with certain usbtest
* configurations, but otherwise double buffering passes basic
tests."

And my driver always got STALL in IN/RX endpoints as below (USB device is a high-speed 1G USB Flash disk):
---
Start INQUIRY SCSI command:
1. send out 31 bytes to ep2out-bulk (though hardware EP5 OUT)

musb_start_urb 214: qh 03bfd520 urb 03b79800 dev2 ep2out-bulk, hw_ep 5, 03bfda60/31 musb_ep_program 653: --> hw5 urb 03b79800 spd3 dev2 ep2out h_addr00 h_port00 bytes 31 musb_write_fifo 112: TX ep5 fifo ffc03ca8 count 31 buf 03bfda60 musb_start_urb 256: Start TX5 pio
musb_interrupt 1582: ** IRQ host usb0008 tx0020 rx0000
musb_host_tx 1194: OUT/TX5 end, csr 2000
__musb_giveback 304: complete 03b79800 (0), dev2 ep2out, 31/31

2. wait for 36 bytes from ep1in-bulk (though hardware EP5 IN) musb_start_urb 214: qh 03bfd520 urb 0301d200 dev2 ep1in-bulk, hw_ep 5, 030000c0/36 musb_ep_program 653: <-- hw5 urb 0301d200 spd3 dev2 ep1in h_addr00 h_port00 bytes 36 musb_interrupt 1582: ** IRQ host usb0008 tx0000 rx0020
musb_host_rx 1419: <== hw 5 rxcsr 0040, urb actual 0 (+dma 0) musb_host_rx 1424: RX end 5 STALL
__musb_giveback 304: complete 0301d200 (-32), dev2 ep1in, 0/36

Got STALL here

musb_start_urb 214: qh 03bfd520 urb 03b79800 dev2 ep0out, hw_ep 0, 0300a500/8 musb_ep_program 653: --> hw0 urb 03b79800 spd3 dev2 ep0out h_addr00 h_port00 bytes 8 musb_write_fifo 112: TX ep0 fifo ffc03c80 count 8 buf 0300a500 musb_start_urb 256: Start TX0 pio
musb_interrupt 1582: ** IRQ host usb0008 tx0001 rx0000
musb_h_ep0_irq 1043: <== csr0 0000, qh 03bfd520, count 0, urb 03b79800, stage 1 musb_h_ep0_continue 978: start no-DATA
musb_h_ep0_irq 1132: ep0 STATUS, csr 0060
musb_interrupt 1582: ** IRQ host usb0008 tx0001 rx0000
musb_h_ep0_irq 1043: <== csr0 0041, qh 03bfd520, count 0, urb 03b79800, stage 4 __musb_giveback 304: complete 03b79800 (0), dev2 ep0out, 0/0

3. wait for 13 bytes from ep1in-bulk (though hardware EP5 IN) musb_start_urb 214: qh 03bfd520 urb 03b79800 dev2 ep1in-bulk, hw_ep 5, 03bfda60/13 musb_ep_program 653: <-- hw5 urb 03b79800 spd3 dev2 ep1in h_addr00 h_port00 bytes 13 musb_interrupt 1582: ** IRQ host usb0008 tx0000 rx0020
musb_host_rx 1419: <== hw 5 rxcsr 0040, urb actual 0 (+dma 0) musb_host_rx 1424: RX end 5 STALL
__musb_giveback 304: complete 03b79800 (-32), dev2 ep1in, 0/13

Got STALL again.
----

Is this issue related with double buffering or other setting?
If you guys got any idea, please give me some help.
Because my USB protocol analyzer is broken, I can't get some help from the instrument.

Thanks a lot
-Bryan Wu

Tony Lindgren

2007-11-15 18:01 UTC #1 lore raw

Hi,

Quoted 5 lines · Bryan Wu

Dear Tony and David,
I struggled in MUSB driver of Blackfin for a long time. Currently, usb device mode should be ok, but USB host mode driver still got weird response.

Nice to hear you got some things working :)

Quoted 63 lines

Blackfin BF54x USB OTG contoller is a single port OTG controller, which has EP0 to EP7 8 bi-directional endpoints. And EP0 FIFO size is 64 x 2, EP1 to EP4 FIFO size is 128 x 2 and EP5 to EP7 is 1024 x 2, totally 7232 bytes. So EP5 is selected as musb->bulk_ep.
Double buffering is automatically as Hardware manual said:
"Each endpoint FIFO can buffer one or two packets (in double-buffered mode). The double buffered mode is automatically enabled when the soft- ware programs a maximum packet size for an endpoint that is less than half the actual FIFO size for that endpoint. Double-buffering is recom- mended for most applications to improve efficiency by reducing the frequency with which each endpoint needs to be serviced."
I noticed the comments of musb_host.c:
"+ double buffered OUT/TX endpoints saw stalls(!) with certain usbtest
* configurations, but otherwise double buffering passes basic
tests."
And my driver always got STALL in IN/RX endpoints as below (USB device is a high-speed 1G USB Flash disk):
---
Start INQUIRY SCSI command:
1. send out 31 bytes to ep2out-bulk (though hardware EP5 OUT)
musb_start_urb 214: qh 03bfd520 urb 03b79800 dev2 ep2out-bulk, hw_ep 5, 03bfda60/31 musb_ep_program 653: --> hw5 urb 03b79800 spd3 dev2 ep2out h_addr00 h_port00 bytes 31 musb_write_fifo 112: TX ep5 fifo ffc03ca8 count 31 buf 03bfda60 musb_start_urb 256: Start TX5 pio
musb_interrupt 1582: ** IRQ host usb0008 tx0020 rx0000
musb_host_tx 1194: OUT/TX5 end, csr 2000
__musb_giveback 304: complete 03b79800 (0), dev2 ep2out, 31/31
2. wait for 36 bytes from ep1in-bulk (though hardware EP5 IN) musb_start_urb 214: qh 03bfd520 urb 0301d200 dev2 ep1in-bulk, hw_ep 5, 030000c0/36 musb_ep_program 653: <-- hw5 urb 0301d200 spd3 dev2 ep1in h_addr00 h_port00 bytes 36 musb_interrupt 1582: ** IRQ host usb0008 tx0000 rx0020
musb_host_rx 1419: <== hw 5 rxcsr 0040, urb actual 0 (+dma 0) musb_host_rx 1424: RX end 5 STALL
__musb_giveback 304: complete 0301d200 (-32), dev2 ep1in, 0/36
Got STALL here
musb_start_urb 214: qh 03bfd520 urb 03b79800 dev2 ep0out, hw_ep 0, 0300a500/8 musb_ep_program 653: --> hw0 urb 03b79800 spd3 dev2 ep0out h_addr00 h_port00 bytes 8 musb_write_fifo 112: TX ep0 fifo ffc03c80 count 8 buf 0300a500 musb_start_urb 256: Start TX0 pio
musb_interrupt 1582: ** IRQ host usb0008 tx0001 rx0000
musb_h_ep0_irq 1043: <== csr0 0000, qh 03bfd520, count 0, urb 03b79800, stage 1 musb_h_ep0_continue 978: start no-DATA
musb_h_ep0_irq 1132: ep0 STATUS, csr 0060
musb_interrupt 1582: ** IRQ host usb0008 tx0001 rx0000
musb_h_ep0_irq 1043: <== csr0 0041, qh 03bfd520, count 0, urb 03b79800, stage 4 __musb_giveback 304: complete 03b79800 (0), dev2 ep0out, 0/0
3. wait for 13 bytes from ep1in-bulk (though hardware EP5 IN) musb_start_urb 214: qh 03bfd520 urb 03b79800 dev2 ep1in-bulk, hw_ep 5, 03bfda60/13 musb_ep_program 653: <-- hw5 urb 03b79800 spd3 dev2 ep1in h_addr00 h_port00 bytes 13 musb_interrupt 1582: ** IRQ host usb0008 tx0000 rx0020
musb_host_rx 1419: <== hw 5 rxcsr 0040, urb actual 0 (+dma 0) musb_host_rx 1424: RX end 5 STALL
__musb_giveback 304: complete 03b79800 (-32), dev2 ep1in, 0/13

Quoted 6 lines

Got STALL again.
----
Is this issue related with double buffering or other setting?
If you guys got any idea, please give me some help.
Because my USB protocol analyzer is broken, I can't get some help from the instrument.

Hmm, I never got double buffering to reliably work on tusb as far as I remember. I guess Dave got it working on DaVinci, so maybe he has some pointers.

Does playing with fifo_mode module parameter have any effect?

Regards,

Tony

David Brownell

2007-11-15 18:43 UTC #2 lore raw

Quoted 3 lines · Tony Lindgren

Hmm, I never got double buffering to reliably work on tusb as far as I remember. I guess Dave got it working on DaVinci, so maybe he has some pointers.

It's been some time since I tried that. What I vaguely recall is that it worked on the peripheral side, but on the host side there was a issue if for example both sides (tx, rx) of a given FIFO tried to do things at the same time.

The driver code has improved a lot since I saw those failures, so I wouldn't trust those memories to indicate anything specific about current behavior.

- Dave

Nazim Khan

2007-11-19 06:08 UTC #3 lore raw

Hi Dave,

Was that in DMA mode or PIO Mode?

regards,
Nazim

Quoted 23 lines · David Brownell

Quoted 3 lines · Tony Lindgren
Hmm, I never got double buffering to reliably work on tusb as far as I remember. I guess Dave got it working on DaVinci, so maybe he has some pointers.
It's been some time since I tried that. What I vaguely recall is that it worked on the peripheral side, but on the host side there was a issue if for example both sides (tx, rx) of a given FIFO tried to do things at the same time.
The driver code has improved a lot since I saw those failures, so I wouldn't trust those memories to indicate anything specific about current behavior.
- Dave
_______________________________________________
Linux-omap-open-source mailing list
[email protected]
http://linux.omap.com/mailman/listinfo/linux-omap-open-source

David Brownell

2007-11-19 06:34 UTC #4 lore raw

Quoted 3 lines · Nazim Khan

Hi Dave,
Was that in DMA mode or PIO Mode?

Probably PIO, since that's usually the first stage of debugging given a choice of modes.

I vaguely recall it was one of those two modes, but don't recall which one. If it was DMA, I sure don't recall which of the several DMA engine wass involved. ;)

- Dave

Quoted 21 lines

regards,
Nazim
Quoted 16 lines · David Brownell
Quoted 3 lines · Tony Lindgren
Hmm, I never got double buffering to reliably work on tusb as far as I remember. I guess Dave got it working on DaVinci, so maybe he has some pointers.
It's been some time since I tried that. What I vaguely recall is that it worked on the peripheral side, but on the host side there was a issue if for example both sides (tx, rx) of a given FIFO tried to do things at the same time.
The driver code has improved a lot since I saw those failures, so I wouldn't trust those memories to indicate anything specific about current behavior.
- Dave

Nazim Khan

2007-11-19 06:49 UTC #5 lore raw

Currently I am trying to get the DMA Mode (cppi dma) working in High Speed. The driver works for sometime and then the Tx channel get snapped. I am working on 2.6.18 Davinci kernel and tried to see the updates on musb driver in 2.6.23 driver of both (omap and davinci). On davinci I don't see much changes except the musb
driver falling in kernel coding convention.

Unfortunately I also don't USB analyzer to really heck out what exactly happening there.

----------------- Error Log ------------------------ <4>eth1: Tx timed out.
<4>We are going to usb_kill_urb @ kevent
<0>Calling cppi_channel_abort
<7>musb_cleanup_urb 2374: abort TX1 DMA for urb c2dbb380 --> 0 <7>__musb_giveback 310: complete c2dbb380 (-2), dev2 ep1out, 1543/1543 <3>Tx status: -2error in tx submit urb: -1Clear Tx Busy <4>error in tx submit urb: -1Clear Tx Busy
<6>NETDEV WATCHDOG: eth1: transmit timed out
____________________________________

regards,
Nazim

Quoted 38 lines · David Brownell

Quoted 3 lines · Nazim Khan
Hi Dave,
Was that in DMA mode or PIO Mode?
Probably PIO, since that's usually the first stage of debugging given a choice of modes.
I vaguely recall it was one of those two modes, but don't recall which one. If it was DMA, I sure don't recall which of the several DMA engine wass involved. ;)
- Dave
Quoted 21 lines
regards,
Nazim
Quoted 16 lines · David Brownell
Quoted 3 lines · Tony Lindgren
Hmm, I never got double buffering to reliably work on tusb as far as I remember. I guess Dave got it working on DaVinci, so maybe he has some pointers.
It's been some time since I tried that. What I vaguely recall is that it worked on the peripheral side, but on the host side there was a issue if for example both sides (tx, rx) of a given FIFO tried to do things at the same time.
The driver code has improved a lot since I saw those failures, so I wouldn't trust those memories to indicate anything specific about current behavior.
- Dave

David Brownell

2007-11-19 07:23 UTC #6 lore raw

Quoted 1 line · Nazim Khan

Currently I am trying to get the DMA Mode (cppi dma) working in High Speed.

CPPI being what I class as a hardward design goof, especially for packet RX. Certain traffic patterns seem almost OK, others don't.

Quoted 1 line

The driver works for sometime and then the Tx channel get snapped.

DMA-only ... or also with PIO?

Quoted 4 lines

I am working on 2.6.18 Davinci kernel and tried to see the updates on musb driver in 2.6.23 driver of both (omap and davinci). On davinci I don't see much changes except the musb
driver falling in kernel coding convention.

There are many more changes than that ... though certainly there's a high volume of cleanup changes, and you may easily have missed the other changes in the middle of those.

A more current kernel would be to your advantage...

Quoted 2 lines

Unfortunately I also don't USB analyzer to really heck out what exactly happening there.

If your budget allows, www.totalphase.com has a rather inexpensive one ($US 1200, what just a few wasted days could cost) that handles high speed.

Quoted 10 lines

----------------- Error Log ------------------------ <4>eth1: Tx timed out.
<4>We are going to usb_kill_urb @ kevent
<0>Calling cppi_channel_abort
<7>musb_cleanup_urb 2374: abort TX1 DMA for urb c2dbb380 --> 0 <7>__musb_giveback 310: complete c2dbb380 (-2), dev2 ep1out, 1543/1543 <3>Tx status: -2error in tx submit urb: -1Clear Tx Busy <4>error in tx submit urb: -1Clear Tx Busy
<6>NETDEV WATCHDOG: eth1: transmit timed out
____________________________________

It's not clear what that' supposed to indicate. It looks like some TX DMA completion logic didn't trigger, which caused the TX timeout and urb cancelation ... which then reported that everything had been transmitted.

- Dave

Quoted 44 lines

regards,
Nazim
Quoted 38 lines · David Brownell
Quoted 3 lines · Nazim Khan
Hi Dave,
Was that in DMA mode or PIO Mode?
Probably PIO, since that's usually the first stage of debugging given a choice of modes.
I vaguely recall it was one of those two modes, but don't recall which one. If it was DMA, I sure don't recall which of the several DMA engine wass involved. ;)
- Dave
Quoted 21 lines
regards,
Nazim
Quoted 16 lines · David Brownell
Quoted 3 lines · Tony Lindgren
Hmm, I never got double buffering to reliably work on tusb as far as I remember. I guess Dave got it working on DaVinci, so maybe he has some pointers.
It's been some time since I tried that. What I vaguely recall is that it worked on the peripheral side, but on the host side there was a issue if for example both sides (tx, rx) of a given FIFO tried to do things at the same time.
The driver code has improved a lot since I saw those failures, so I wouldn't trust those memories to indicate anything specific about current behavior.
- Dave

Nazim Khan

2007-11-19 10:25 UTC #7 lore raw

I am working in DMA Mode (PIO mode works fine)

Quoted 100 lines · David Brownell

Quoted 1 line · Nazim Khan
Currently I am trying to get the DMA Mode (cppi dma) working in High Speed.
CPPI being what I class as a hardward design goof, especially for packet RX. Certain traffic patterns seem almost OK, others don't.
Quoted 1 line
The driver works for sometime and then the Tx channel get snapped.
DMA-only ... or also with PIO?
Quoted 4 lines
I am working on 2.6.18 Davinci kernel and tried to see the updates on musb driver in 2.6.23 driver of both (omap and davinci). On davinci I don't see much changes except the musb
driver falling in kernel coding convention.
There are many more changes than that ... though certainly there's a high volume of cleanup changes, and you may easily have missed the other changes in the middle of those.
A more current kernel would be to your advantage...
Quoted 2 lines
Unfortunately I also don't USB analyzer to really heck out what exactly happening there.
If your budget allows, www.totalphase.com has a rather inexpensive one ($US 1200, what just a few wasted days could cost) that handles high speed.
Quoted 10 lines
----------------- Error Log ------------------------ <4>eth1: Tx timed out.
<4>We are going to usb_kill_urb @ kevent
<0>Calling cppi_channel_abort
<7>musb_cleanup_urb 2374: abort TX1 DMA for urb c2dbb380 --> 0 <7>__musb_giveback 310: complete c2dbb380 (-2), dev2 ep1out, 1543/1543 <3>Tx status: -2error in tx submit urb: -1Clear Tx Busy <4>error in tx submit urb: -1Clear Tx Busy
<6>NETDEV WATCHDOG: eth1: transmit timed out
____________________________________
It's not clear what that' supposed to indicate. It looks like some TX DMA completion logic didn't trigger, which caused the TX timeout and urb cancelation ... which then reported that everything had been transmitted.
- Dave
Quoted 44 lines
regards,
Nazim
Quoted 38 lines · David Brownell
Quoted 3 lines · Nazim Khan
Hi Dave,
Was that in DMA mode or PIO Mode?
Probably PIO, since that's usually the first stage of debugging given a choice of modes.
I vaguely recall it was one of those two modes, but don't recall which one. If it was DMA, I sure don't recall which of the several DMA engine wass involved. ;)
- Dave
Quoted 21 lines
regards,
Nazim
Quoted 16 lines · David Brownell
Quoted 3 lines · Tony Lindgren
Hmm, I never got double buffering to reliably work on tusb as far as I remember. I guess Dave got it working on DaVinci, so maybe he has some pointers.
It's been some time since I tried that. What I vaguely recall is that it worked on the peripheral side, but on the host side there was a issue if for example both sides (tx, rx) of a given FIFO tried to do things at the same time.
The driver code has improved a lot since I saw those failures, so I wouldn't trust those memories to indicate anything specific about current behavior.
- Dave