[Question] Always got STALL in MUSB Host driver

[Question] Always got STALL in MUSB Host driver

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

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

Re: [Question] Always got STALL in MUSB Host driver

[Tony Lindgren]

Hi,

* Bryan Wu <bryan.wu@analog.com> [071115 02:56]:
> 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 :)

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

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

Re: [Question] Always got STALL in MUSB Host driver

[David Brownell]

On Thursday 15 November 2007, Tony Lindgren wrote:
> 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

Re: [Question] Always got STALL in MUSB Host driver

[Nazim Khan]

Hi Dave,

Was that in DMA mode or PIO Mode?

regards,
Nazim

On Nov 16, 2007 12:13 AM, David Brownell <david-b@pacbell.net> wrote:
> On Thursday 15 November 2007, Tony Lindgren wrote:
> > 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
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>

Re: [Question] Always got STALL in MUSB Host driver

[David Brownell]

On Sunday 18 November 2007, Nazim Khan wrote:
> 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


> regards,
> Nazim
> 
> On Nov 16, 2007 12:13 AM, David Brownell <david-b@pacbell.net> wrote:
> > On Thursday 15 November 2007, Tony Lindgren wrote:
> > > 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
> >
> 

Re: [Question] Always got STALL in MUSB Host driver

[Nazim Khan]

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

On Nov 19, 2007 12:04 PM, David Brownell <david-b@pacbell.net> wrote:
> On Sunday 18 November 2007, Nazim Khan wrote:
> > 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
>
>
>
> > regards,
> > Nazim
> >
> > On Nov 16, 2007 12:13 AM, David Brownell <david-b@pacbell.net> wrote:
> > > On Thursday 15 November 2007, Tony Lindgren wrote:
> > > > 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
> > >
> >
>

Re: [Question] Always got STALL in MUSB Host driver

[David Brownell]

On Sunday 18 November 2007, Nazim Khan wrote:
> 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.


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

DMA-only ... or also with PIO?


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

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


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


> 
> regards,
> Nazim
> 
> On Nov 19, 2007 12:04 PM, David Brownell <david-b@pacbell.net> wrote:
> > On Sunday 18 November 2007, Nazim Khan wrote:
> > > 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
> >
> >
> >
> > > regards,
> > > Nazim
> > >
> > > On Nov 16, 2007 12:13 AM, David Brownell <david-b@pacbell.net> wrote:
> > > > On Thursday 15 November 2007, Tony Lindgren wrote:
> > > > > 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
> > > >
> > >
> >
> 

Re: [Question] Always got STALL in MUSB Host driver

[Nazim Khan]

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

On Nov 19, 2007 12:53 PM, David Brownell <david-b@pacbell.net> wrote:
> On Sunday 18 November 2007, Nazim Khan wrote:
> > 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.
>
>
> > The driver works for sometime and then the Tx channel get snapped.
>
> DMA-only ... or also with PIO?
>
>
> > 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...
>
>
> > 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.
>
>
> > ----------------- 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
>
>
> >
> > regards,
> > Nazim
> >
> > On Nov 19, 2007 12:04 PM, David Brownell <david-b@pacbell.net> wrote:
> > > On Sunday 18 November 2007, Nazim Khan wrote:
> > > > 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
> > >
> > >
> > >
> > > > regards,
> > > > Nazim
> > > >
> > > > On Nov 16, 2007 12:13 AM, David Brownell <david-b@pacbell.net> wrote:
> > > > > On Thursday 15 November 2007, Tony Lindgren wrote:
> > > > > > 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
> > > > >
> > > >
> > >
> >
>
>
>