AM335x USB DMA seems broken on ISOC URBs

AM335x USB DMA seems broken on ISOC URBs

[Ezequiel Garcia]

Hello,

While doing some experiments with the stk1160 driver (for "Easycap" TV video
capture devices), ran into problems using v3.13-rc4. The problem is that the
stk1160 IRQ handler receives no URBs at all.

When configuring with CONFIG_MUSB_PIO_ONLY this looks solved, but the
bandwidth requirements are too large for PIO (it's a raw video device) and the
video can't get captured.

Interesting enough, using an old backported for v3.2 stk1160 driver, this same
setup works with TI PSP v3.2 kernel. So, I guess it's some software bug in
either the cppi41 dmaengine or the musb.

I tried to compare the PSP to the mainline drivers but they seems *very*
different and really beyond my understanding.

Any ideas on how can I help debugging this?

Thanks!
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AM335x USB DMA seems broken on ISOC URBs

[Ezequiel Garcia]

On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote:
> Hello,
> 
> While doing some experiments with the stk1160 driver (for "Easycap" TV video
> capture devices), ran into problems using v3.13-rc4. The problem is that the
> stk1160 IRQ handler receives no URBs at all.
> 
> When configuring with CONFIG_MUSB_PIO_ONLY this looks solved, but the
> bandwidth requirements are too large for PIO (it's a raw video device) and the
> video can't get captured.
> 
> Interesting enough, using an old backported for v3.2 stk1160 driver, this same
> setup works with TI PSP v3.2 kernel. So, I guess it's some software bug in
> either the cppi41 dmaengine or the musb.
> 
> I tried to compare the PSP to the mainline drivers but they seems *very*
> different and really beyond my understanding.
> 
> Any ideas on how can I help debugging this?
> 

Ping? It would be good to hunt thig bug down. The TI PSP provided USB driver
works fine so at least that's a starting point...

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AM335x USB DMA seems broken on ISOC URBs

[Daniel Mack]

Hi Ezequiel,

On 01/17/2014 05:27 PM, Ezequiel Garcia wrote:
> On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote:
>> Hello,
>>
>> While doing some experiments with the stk1160 driver (for "Easycap" TV video
>> capture devices), ran into problems using v3.13-rc4. The problem is that the
>> stk1160 IRQ handler receives no URBs at all.
>>
>> When configuring with CONFIG_MUSB_PIO_ONLY this looks solved, but the
>> bandwidth requirements are too large for PIO (it's a raw video device) and the
>> video can't get captured.
>>
>> Interesting enough, using an old backported for v3.2 stk1160 driver, this same
>> setup works with TI PSP v3.2 kernel. So, I guess it's some software bug in
>> either the cppi41 dmaengine or the musb.
>>
>> I tried to compare the PSP to the mainline drivers but they seems *very*
>> different and really beyond my understanding.
>>
>> Any ideas on how can I help debugging this?
>>
> 
> Ping? It would be good to hunt thig bug down. The TI PSP provided USB driver
> works fine so at least that's a starting point...
> 

Did you try this with a different type of peripheral hardware, a USB
audio device for example? You could also check whether the packets are
actually received by the DMA driver but dropped before the USB subsys
gets to see them for whatever reason.

Let me know if you find anything - I hope to find some time to do
similar tests on AM33xx based hardware.


Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AM335x USB DMA seems broken on ISOC URBs

[Daniel Mack]

On 01/18/2014 04:12 PM, Daniel Mack wrote:
> On 01/17/2014 05:27 PM, Ezequiel Garcia wrote:
>> On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote:

>>> While doing some experiments with the stk1160 driver (for "Easycap" TV video
>>> capture devices), ran into problems using v3.13-rc4. The problem is that the
>>> stk1160 IRQ handler receives no URBs at all.

[...]

> Let me know if you find anything - I hope to find some time to do
> similar tests on AM33xx based hardware.

I tried using an USB headset connected to a AM33xx based board, using
kernel v3.13.

The good news is that aplay gives me sound, so there's nothing generally
wrong with isochronous streams on musb_dsps/cppi41.

I can also do some simple 'arecord | aplay' loopback, and I can hear the
microphone signal, but the stream breaks down after a couple of seconds,
showing the following error:

[  433.671757] ALSA sound/core/pcm_lib.c:1945 capture write error (DMA
or IRQ trouble?)

Also, when tearing down the aplay stream, the cppi41 driver spits a
number of the warnings below.

Sebastian, do you have any pending patches that might be worth testing?



Thanks,
Daniel



[  340.255651] ------------[ cut here ]------------
[  340.262828] WARNING: CPU: 0 PID: 112 at drivers/dma/cppi41.c:605
cppi41_dma_control+0x2a8/0x2d4()
[  340.272086] Modules linked in:
[  340.287140] CPU: 0 PID: 112 Comm: aplay Tainted: G        W
3.13.0-00051-gff62d1c #1661
[  340.295798] [<c00137b8>] (unwind_backtrace+0x0/0xf4) from
[<c001158c>] (show_stack+0x10/0x14)
[  340.304712] [<c001158c>] (show_stack+0x10/0x14) from [<c0037154>]
(warn_slowpath_common+0x6c/0x84)
[  340.314070] [<c0037154>] (warn_slowpath_common+0x6c/0x84) from
[<c0037208>] (warn_slowpath_null+0x1c/0x24)
[  340.324153] [<c0037208>] (warn_slowpath_null+0x1c/0x24) from
[<c02b50d8>] (cppi41_dma_control+0x2a8/0x2d4)
[  340.334255] [<c02b50d8>] (cppi41_dma_control+0x2a8/0x2d4) from
[<c0375f0c>] (cppi41_dma_channel_abort+0xcc/0)
[  340.344976] [<c0375f0c>] (cppi41_dma_channel_abort+0xcc/0x140) from
[<c037187c>] (musb_cleanup_urb.isra.16+0)
[  340.356147] [<c037187c>] (musb_cleanup_urb.isra.16+0x58/0x11c) from
[<c0371b80>] (musb_urb_dequeue+0xe8/0x12)
[  340.366595] [<c0371b80>] (musb_urb_dequeue+0xe8/0x128) from
[<c035aa74>] (unlink1+0x2c/0x110)
[  340.375497] [<c035aa74>] (unlink1+0x2c/0x110) from [<c035b2e0>]
(usb_hcd_unlink_urb+0x50/0xc4)
[  340.384496] [<c035b2e0>] (usb_hcd_unlink_urb+0x50/0xc4) from
[<c03db53c>] (deactivate_urbs+0xd8/0xf4)
[  340.394126] [<c03db53c>] (deactivate_urbs+0xd8/0xf4) from
[<c03dc614>] (snd_usb_endpoint_stop+0x30/0x70)
[  340.404032] [<c03dc614>] (snd_usb_endpoint_stop+0x30/0x70) from
[<c03e3d40>] (stop_endpoints+0x70/0x88)
[  340.413843] [<c03e3d40>] (stop_endpoints+0x70/0x88) from [<c03e3ea0>]
(snd_usb_substream_playback_trigger+0x)
[  340.424836] [<c03e3ea0>]
(snd_usb_substream_playback_trigger+0x9c/0xb8) from [<c03cdb40>]
(snd_pcm_do_stop+0)
[  340.435917] [<c03cdb40>] (snd_pcm_do_stop+0x54/0x58) from
[<c03cd768>] (snd_pcm_action_single+0x38/0x78)
[  340.445816] [<c03cd768>] (snd_pcm_action_single+0x38/0x78) from
[<c03cd970>] (snd_pcm_drop+0x6c/0xc4)
[  340.455443] [<c03cd970>] (snd_pcm_drop+0x6c/0xc4) from [<c03cf22c>]
(snd_pcm_common_ioctl1+0xc90/0x109c)
[  340.465344] [<c03cf22c>] (snd_pcm_common_ioctl1+0xc90/0x109c) from
[<c03cf7f0>] (snd_pcm_playback_ioctl1+0x1)
[  340.476434] [<c03cf7f0>] (snd_pcm_playback_ioctl1+0x1b8/0x4b0) from
[<c00e7a60>] (do_vfs_ioctl+0x3fc/0x5f0)
[  340.486607] [<c00e7a60>] (do_vfs_ioctl+0x3fc/0x5f0) from [<c00e7cc4>]
(SyS_ioctl+0x70/0x80)
[  340.495331] [<c00e7cc4>] (SyS_ioctl+0x70/0x80) from [<c000e340>]
(ret_fast_syscall+0x0/0x48)
[  340.504136] ---[ end trace 521a83c0d2567bbb ]---

Re: AM335x USB DMA seems broken on ISOC URBs

[Ezequiel Garcia]

On Mon, Jan 20, 2014 at 12:15:40PM +0100, Daniel Mack wrote:
> On 01/18/2014 04:12 PM, Daniel Mack wrote:
> > On 01/17/2014 05:27 PM, Ezequiel Garcia wrote:
> >> On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote:
> 
> >>> While doing some experiments with the stk1160 driver (for "Easycap" TV video
> >>> capture devices), ran into problems using v3.13-rc4. The problem is that the
> >>> stk1160 IRQ handler receives no URBs at all.
> 
> [...]
> 
> > Let me know if you find anything - I hope to find some time to do
> > similar tests on AM33xx based hardware.
> 
> I tried using an USB headset connected to a AM33xx based board, using
> kernel v3.13.
> 
> The good news is that aplay gives me sound, so there's nothing generally
> wrong with isochronous streams on musb_dsps/cppi41.
> 

Hm.. interesting. I wonder what's the difference between those URBs and
the video URBs involved in stk1160 operation. Maybe the size of each
buffer transfered?

Can anybody bring some light on this?
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AM335x USB DMA seems broken on ISOC URBs

[Ezequiel Garcia]

Hi Daniel,

On Sat, Jan 18, 2014 at 04:12:24PM +0100, Daniel Mack wrote:
> On 01/17/2014 05:27 PM, Ezequiel Garcia wrote:
> > On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote:
[..]
> 
> Did you try this with a different type of peripheral hardware, a USB
> audio device for example?
> 
[..]

Finally I found some time to setup the board and do some new tests using
an UVC webcam (which might behave better given it should transfer
smaller buffers).

The result is not encouraging! Device is detected regularly, but then I get
some ugly messages on the first command:

# yavta /dev/video0 -l
[   21.279722] BUG: spinlock cpu recursion on CPU#0, kworker/0:2/46
[   21.286041]  lock: 0xdf01e010, .magic: dead4ead, .owner: yavta/78, .owner_cpu: 0
[   21.293800] CPU: 0 PID: 46 Comm: kworker/0:2 Not tainted 3.13.0-rc8-next-20140120-dirty #69
[   21.302571] Workqueue: events musb_host_finish_resume
[   21.307899] [<c000faa1>] (unwind_backtrace) from [<c000e8db>] (show_stack+0xb/0xc)
[   21.315844] [<c000e8db>] (show_stack) from [<c003f981>] (do_raw_spin_lock+0xc5/0xe8)
[   21.323969] [<c003f981>] (do_raw_spin_lock) from [<c030c949>] (_raw_spin_lock_irqsave+0xd/0x10)
[   21.333094] [<c030c949>] (_raw_spin_lock_irqsave) from [<c021927b>] (musb_host_finish_resume+0xf/0x60)
[   21.342860] [<c021927b>] (musb_host_finish_resume) from [<c0031709>] (process_one_work+0xad/0x224)
[   21.352258] [<c0031709>] (process_one_work) from [<c0031b19>] (worker_thread+0xc9/0x270)
[   21.360750] [<c0031b19>] (worker_thread) from [<c00355c7>] (kthread+0x7b/0x94)
[   21.368325] [<c00355c7>] (kthread) from [<c000cb7d>] (ret_from_fork+0x11/0x34)
[   27.352780] BUG: spinlock lockup suspected on CPU#0, kworker/0:2/46
[   27.359350]  lock: 0xdf01e010, .magic: dead4ead, .owner: yavta/78, .owner_cpu: 0
[   27.367104] CPU: 0 PID: 46 Comm: kworker/0:2 Not tainted 3.13.0-rc8-next-20140120-dirty #69
[   27.375860] Workqueue: events musb_host_finish_resume
[   27.381162] [<c000faa1>] (unwind_backtrace) from [<c000e8db>] (show_stack+0xb/0xc)
[   27.389103] [<c000e8db>] (show_stack) from [<c003f971>] (do_raw_spin_lock+0xb5/0xe8)
[   27.397224] [<c003f971>] (do_raw_spin_lock) from [<c030c949>] (_raw_spin_lock_irqsave+0xd/0x10)
[   27.406348] [<c030c949>] (_raw_spin_lock_irqsave) from [<c021927b>] (musb_host_finish_resume+0xf/0x60)
[   27.416109] [<c021927b>] (musb_host_finish_resume) from [<c0031709>] (process_one_work+0xad/0x224)
[   27.425506] [<c0031709>] (process_one_work) from [<c0031b19>] (worker_thread+0xc9/0x270)
[   27.433991] [<c0031b19>] (worker_thread) from [<c00355c7>] (kthread+0x7b/0x94)
[   27.441566] [<c00355c7>] (kthread) from [<c000cb7d>] (ret_from_fork+0x11/0x34)

Any ideas from the maintainers?

PS: As expected TI's PSP v3.2 driver works just fine :P
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html