Re: [PATCH 2/2] usb: musb: musb_cppi41: revert to old timer poll intervals
Maybe I`ve found a nice old patch: https://github.com/Angstrom-distribution/meta-ti/blob/master/recipes-kernel/linux/linux-ti33x-psp-3.2/psp/0010-usb-musb-cppi41-enable-txfifo-empty-interrupt-logic.patch Is tx fifo empty interrupt logic already used? So maybe for ISOC we can avoid the busy hrtimer loop. -- Sebastian Reimers signature.asc Description: This is a digitally signed message part
Re: [PATCH 2/2] usb: musb: musb_cppi41: revert to old timer poll intervals
Hi Sebastian, Hi Daniel, after some debugging the 25 microseconds loop only catches 1% of early_tx transfers (with your patch #1). Most of them are catched in the hrtimer (incl. re-loop) between 30-60 microseconds. Any debug code suggestions to get reliable values? I`m not sure if my current affects timing. With Daniels usb: musb: cppi41: tweak hrtimer values its better. The only negative is, that CPU usage is higher compared to PIO mode. But maybe this is a restriction of DMA and smaller packet size. cppi41_channel-total_len is 40 bytes. 48 kHz / 32 Bit - Stereo High Speed USB Host. -- Sebastian Reimers -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: musb: musb_cppi41: revert to old timer poll intervals
b) Both FS and HS audio devices should still function as before, with no regression regarding CPU load while streaming. The patch destroys audio quality (pops, clicks and alsa underruns). Tested with a USB 2.0 (Focusrite) device. Test case is a simple audio loop: $ arecord | aplay Jackd generates cppi41_irq errors. -- Sebastian signature.asc Description: This is a digitally signed message part
Re: [PATCH 2/2] usb: musb: musb_cppi41: revert to old timer poll intervals
Am Freitag, den 07.11.2014, 15:17 +0100 schrieb Sebastian Andrzej Siewior: On 11/07/2014 02:57 PM, Sebastian Reimers wrote: b) Both FS and HS audio devices should still function as before, with no regression regarding CPU load while streaming. The patch destroys audio quality (pops, clicks and alsa underruns). Tested with a USB 2.0 (Focusrite) device. Great. I guess appling patch #1 one does not cause any harm, it is just #2 that breaks things. Yes patch #1 should be fine. I debugged that the condition is_hs is really true with my device. Is it better or worse than without usb: musb: cppi41: tweak hrtimer values ? I will check this too. Can you measure how long it takes on average to complete / how often you enter the re-try loop? Yes I figure this out over the weekend. Test case is a simple audio loop: $ arecord | aplay Jackd generates cppi41_irq errors. Can you paste one of those? $ /usr/bin/jackd -R -P89 -dalsa -d hw:0,0 -r48000 -p1024 -n3 With: kernel.sched_rt_runtime_us = -1 [ 79.236750] cppi41_irq() q 138 desc [ 83.768813] [ cut here ] [ 83.773711] WARNING: CPU: 0 PID: 278 at drivers/dma/cppi41.c:612 cppi41_dma_control+0x2ac/0x2d8() [ 83.783014] Modules linked in: [ 83.786229] CPU: 0 PID: 278 Comm: jackd Tainted: GW 3.18.0-rc3 #5 [ 83.793834] [c0013ba8] (unwind_backtrace) from [c00117a0] (show_stack+0x10/0x14) [ 83.801964] [c00117a0] (show_stack) from [c0036324] (warn_slowpath_common+0x6c/0x84) [ 83.810454] [c0036324] (warn_slowpath_common) from [c00363d8] (warn_slowpath_null+0x1c/0x24) [ 83.819670] [c00363d8] (warn_slowpath_null) from [c02c9790] (cppi41_dma_control+0x2ac/0x2d8) [ 83.828893] [c02c9790] (cppi41_dma_control) from [c0391068] (cppi41_dma_channel_abort+0xcc/0x140) [ 83.838578] [c0391068] (cppi41_dma_channel_abort) from [c038c758] (musb_cleanup_urb.isra.13+0x58/0x11c) [ 83.848799] [c038c758] (musb_cleanup_urb.isra.13) from [c038ca5c] (musb_urb_dequeue+0xe8/0x128) [ 83.858292] [c038ca5c] (musb_urb_dequeue) from [c0374ff0] (unlink1+0x2c/0x110) [ 83.866234] [c0374ff0] (unlink1) from [c0375a68] (usb_hcd_unlink_urb+0x4c/0x84) [ 83.874268] [c0375a68] (usb_hcd_unlink_urb) from [c03fc634] (deactivate_urbs+0xd8/0xf4) [ 83.883031] [c03fc634] (deactivate_urbs) from [c03fd718] (snd_usb_endpoint_stop+0x30/0x70) [ 83.892070] [c03fd718] (snd_usb_endpoint_stop) from [c0404b9c] (stop_endpoints+0x70/0x88) [ 83.901015] [c0404b9c] (stop_endpoints) from [c0404cfc] (snd_usb_substream_playback_trigger+0x9c/0xb8) [ 83.911145] [c0404cfc] (snd_usb_substream_playback_trigger) from [c03ee79c] (snd_pcm_do_stop+0x54/0x58) [ 83.921365] [c03ee79c] (snd_pcm_do_stop) from [c03eda30] (snd_pcm_action_group+0x190/0x20c) [ 83.930490] [c03eda30] (snd_pcm_action_group) from [c03ee604] (snd_pcm_action+0x54/0xfc) [ 83.939343] [c03ee604] (snd_pcm_action) from [c03f0918] (snd_pcm_common_ioctl1+0xc84/0xf94) [ 83.948470] [c03f0918] (snd_pcm_common_ioctl1) from [c03f1290] (snd_pcm_capture_ioctl1+0x1b8/0x464) [ 83.958329] [c03f1290] (snd_pcm_capture_ioctl1) from [c00eeed4] (do_vfs_ioctl+0x3fc/0x5f0) [ 83.967365] [c00eeed4] (do_vfs_ioctl) from [c00ef134] (SyS_ioctl +0x6c/0x7c) [ 83.975034] [c00ef134] (SyS_ioctl) from [c000e440] (ret_fast_syscall+0x0/0x48) [ 83.982972] ---[ end trace 094e700abc52f491 ]--- -- Sebastian signature.asc Description: This is a digitally signed message part
Re: [PATCH 2/2] usb: musb: musb_cppi41: revert to old timer poll intervals
Am Freitag, den 07.11.2014, 16:08 +0100 schrieb Sebastian Andrzej Siewior: On 11/07/2014 03:45 PM, Sebastian Reimers wrote: $ /usr/bin/jackd -R -P89 -dalsa -d hw:0,0 -r48000 -p1024 -n3 With: kernel.sched_rt_runtime_us = -1 uhhh. Why do you need this? I need low audio latency and with musb in pio mode this was required to get lower frames per period (-p 512). Otherwise I get: musb_ep_program 896: broken !rx_reinit, ep11 csr 0003 I tested this now with musb DMA mode (default sched_rt_runtime_us value) and in current mainline this didn`t happen anymore, only the cpu load is 2-3x higher compared to PIO (Kernel 3.17.1). Testing PIO and mainline is on my todo list now ;-) But with your patch #2 and default sched_rt_runtime_us the cppi41_irq occur. There should be two back traces. You are right, sorry, here are a fresh complete log. [ 135.909622] [ cut here ] [ 135.914521] WARNING: CPU: 0 PID: 272 at drivers/dma/cppi41.c:320 cppi41_irq+0x140/0x18c() [ 135.923096] Modules linked in: [ 135.926312] CPU: 0 PID: 272 Comm: jackd Not tainted 3.18.0-rc3 #9 [ 135.932727] [c0013ba8] (unwind_backtrace) from [c00117a0] (show_stack+0x10/0x14) [ 135.940855] [c00117a0] (show_stack) from [c0036324] (warn_slowpath_common+0x6c/0x84) [ 135.949345] [c0036324] (warn_slowpath_common) from [c00363d8] (warn_slowpath_null+0x1c/0x24) [ 135.958562] [c00363d8] (warn_slowpath_null) from [c02ca18c] (cppi41_irq+0x140/0x18c) [ 135.967055] [c02ca18c] (cppi41_irq) from [c006c768] (handle_irq_event_percpu+0x38/0x140) [ 135.975908] [c006c768] (handle_irq_event_percpu) from [c006c8ac] (handle_irq_event+0x3c/0x5c) [ 135.985217] [c006c8ac] (handle_irq_event) from [c006ef10] (handle_level_irq+0xbc/0x134) [ 135.993979] [c006ef10] (handle_level_irq) from [c006bf70] (generic_handle_irq+0x2c/0x3c) [ 136.002830] [c006bf70] (generic_handle_irq) from [c006c1e0] (__handle_domain_irq+0x70/0xc8) [ 136.011956] [c006c1e0] (__handle_domain_irq) from [c0008670] (omap_intc_handle_irq+0xc8/0xd0) [ 136.021264] [c0008670] (omap_intc_handle_irq) from [c00125a4] (__irq_usr+0x44/0x60) [ 136.029657] Exception stack(0xdc18ffb0 to 0xdc18fff8) [ 136.034955] ffa0: 00f0 00f0 0021 [ 136.043533] ffc0: 00f0 00f0 081979e7 0039 0001ece8 [ 136.052109] ffe0: b155e0f8 b1540db8 b1551c84 b6d7f658 4010 [ 136.059044] ---[ end trace 66d4bc7aceea6dda ]--- [ 136.063884] cppi41_irq() q 138 desc [ 138.965737] [ cut here ] [ 138.970632] WARNING: CPU: 0 PID: 272 at drivers/dma/cppi41.c:612 cppi41_dma_control+0x2ac/0x2d8() [ 138.979936] Modules linked in: [ 138.983151] CPU: 0 PID: 272 Comm: jackd Tainted: GW 3.18.0-rc3 #9 [ 138.990755] [c0013ba8] (unwind_backtrace) from [c00117a0] (show_stack+0x10/0x14) [ 138.998885] [c00117a0] (show_stack) from [c0036324] (warn_slowpath_common+0x6c/0x84) [ 139.007374] [c0036324] (warn_slowpath_common) from [c00363d8] (warn_slowpath_null+0x1c/0x24) [ 139.016591] [c00363d8] (warn_slowpath_null) from [c02c9790] (cppi41_dma_control+0x2ac/0x2d8) [ 139.025813] [c02c9790] (cppi41_dma_control) from [c0391068] (cppi41_dma_channel_abort+0xcc/0x140) [ 139.035496] [c0391068] (cppi41_dma_channel_abort) from [c038c758] (musb_cleanup_urb.isra.13+0x58/0x11c) [ 139.045717] [c038c758] (musb_cleanup_urb.isra.13) from [c038ca5c] (musb_urb_dequeue+0xe8/0x128) [ 139.055210] [c038ca5c] (musb_urb_dequeue) from [c0374ff0] (unlink1+0x2c/0x110) [ 139.063151] [c0374ff0] (unlink1) from [c0375a68] (usb_hcd_unlink_urb+0x4c/0x84) [ 139.071184] [c0375a68] (usb_hcd_unlink_urb) from [c03fc634] (deactivate_urbs+0xd8/0xf4) [ 139.079947] [c03fc634] (deactivate_urbs) from [c03fd718] (snd_usb_endpoint_stop+0x30/0x70) [ 139.088985] [c03fd718] (snd_usb_endpoint_stop) from [c0404b9c] (stop_endpoints+0x70/0x88) [ 139.097929] [c0404b9c] (stop_endpoints) from [c0404cfc] (snd_usb_substream_playback_trigger+0x9c/0xb8) [ 139.108058] [c0404cfc] (snd_usb_substream_playback_trigger) from [c03ee79c] (snd_pcm_do_stop+0x54/0x58) [ 139.118277] [c03ee79c] (snd_pcm_do_stop) from [c03eda30] (snd_pcm_action_group+0x190/0x20c) [ 139.127401] [c03eda30] (snd_pcm_action_group) from [c03ee604] (snd_pcm_action+0x54/0xfc) [ 139.136253] [c03ee604] (snd_pcm_action) from [c03f0918] (snd_pcm_common_ioctl1+0xc84/0xf94) [ 139.145379] [c03f0918] (snd_pcm_common_ioctl1) from [c03f1290] (snd_pcm_capture_ioctl1+0x1b8/0x464) [ 139.155237] [c03f1290] (snd_pcm_capture_ioctl1) from [c00eeed4] (do_vfs_ioctl+0x3fc/0x5f0) [ 139.164274] [c00eeed4] (do_vfs_ioctl) from [c00ef134] (SyS_ioctl+0x6c/0x7c) [ 139.171943] [c00ef134] (SyS_ioctl) from [c000e440] (ret_fast_syscall+0x0/0x48) [ 139.179881] ---[ end trace 66d4bc7aceea6ddb ]--- and the transfer is canceled because jack assumed it took too long to complete? You didn't stop it on your own right? Correct. -- ALSA
Re: [PATCH 2/2] usb: musb: musb_cppi41: revert to old timer poll intervals
Sebastian (Reimers), given that you have a good test setup too, any chance you can as well do some testing here? Of course. I can try to reproduce your bug and then retry it with Sebastian's patch, anything special with the audio setup (sampling rate, format)? -- Sebastian Reimers signature.asc Description: This is a digitally signed message part
Re: [PATCH v3 0/4] usb: gadget: f_uac2: cleanups and capture timing
Hi Xuebing, Would you mind to share how did you run the test for both Playback/Capture? What host version are you using, as different Host enumerates (sends sequences of USB_REQ_SET_INTERFACE request differently)? sure, on client side (BBB) I have a jackd on top alsa running and connected capture and playback ports together. On host side I use a Linux Kernel 3.16.1 and forward the gadget usb with alsa_in and alsa_out to a jackd pipe with another usb interface (focusrite UAC2). regards, Sebastian signature.asc Description: This is a digitally signed message part
Re: [PATCH v3 0/4] usb: gadget: f_uac2: cleanups and capture timing
Hi, Sebastian, could you give these patches a try? They seem to work well on a BBB setup here. Patch v3 works great on BBB as well with a Audio Loop and 48kHz/16 bit. No noise or clicks. Tomorrow I have time to test other combinations (sample-/rate/size). Sebastian signature.asc Description: This is a digitally signed message part
Re: [PATCH 00/5] Equivalent of g_audio with configfs
Andrzej Pietrasiewicz andrzej.p@... writes: This series aims at integrating configfs into the audio gadget, the way it has been done for acm, ncm, ecm, eem, ecm subset, rndis, obex, phonet, mass_storage, FunctionFS, loopback, sourcesink; rfc for uvc has also been sent. It contains everything that is required to provide the equivalent of g_audio.ko with configfs. It is meant for 3.18. Rebased onto Felipe's testing-next. Just tested the patches on top 3.17-rc1. Works fine, so: Tested-by: Sebastian Reimers sebastian.reim...@googlemail.com Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] usb: gadget: f_uac2: Fix pcm sample size selection
The pcm playback and capture sample size format was fixed
SNDRV_PCM_FMTBIT_S16_LE.
This patch respects also 16, 24 and 32 bit p_ssize and c_ssize values.
Signed-off-by: Sebastian Reimers sebastian.reim...@gmail.com
---
drivers/usb/gadget/f_uac2.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/f_uac2.c b/drivers/usb/gadget/f_uac2.c
index 6261db4a..3ed89ec 100644
--- a/drivers/usb/gadget/f_uac2.c
+++ b/drivers/usb/gadget/f_uac2.c
@@ -348,14 +348,34 @@ static int uac2_pcm_open(struct snd_pcm_substream
*substream)
if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK) {
spin_lock_init(uac2-p_prm.lock);
runtime-hw.rate_min = p_srate;
- runtime-hw.formats = SNDRV_PCM_FMTBIT_S16_LE; /* ! p_ssize ! */
+ switch (p_ssize) {
+ case 3:
+ runtime-hw.formats = SNDRV_PCM_FMTBIT_S24_3LE;
+ break;
+ case 4:
+ runtime-hw.formats = SNDRV_PCM_FMTBIT_S32_LE;
+ break;
+ default:
+ runtime-hw.formats = SNDRV_PCM_FMTBIT_S16_LE;
+ break;
+ }
runtime-hw.channels_min = num_channels(p_chmask);
runtime-hw.period_bytes_min = 2 * uac2-p_prm.max_psize
/ runtime-hw.periods_min;
} else {
spin_lock_init(uac2-c_prm.lock);
runtime-hw.rate_min = c_srate;
- runtime-hw.formats = SNDRV_PCM_FMTBIT_S16_LE; /* ! c_ssize ! */
+ switch (c_ssize) {
+ case 3:
+ runtime-hw.formats = SNDRV_PCM_FMTBIT_S24_3LE;
+ break;
+ case 4:
+ runtime-hw.formats = SNDRV_PCM_FMTBIT_S32_LE;
+ break;
+ default:
+ runtime-hw.formats = SNDRV_PCM_FMTBIT_S16_LE;
+ break;
+ }
runtime-hw.channels_min = num_channels(c_chmask);
runtime-hw.period_bytes_min = 2 * uac2-c_prm.max_psize
/ runtime-hw.periods_min;
--
2.0.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
