AM335x USB DMA seems broken on ISOC URBs

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

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

Hi Ezequiel,

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

[...]

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

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

Hi Daniel,

[..]

[..]

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