On Wed, May 24, 2017 at 12:22 AM, Francesco Lavra <francescolavra.fl@xxxxxxxxx> wrote: > On Sun, May 21, 2017 at 4:42 PM, Francesco Lavra > <francescolavra.fl@xxxxxxxxx> wrote: >> Hi, >> I'm using the dwc2 OTG controller as a USB audio gadget (g_audio driver), >> and I'm having trouble with making it work at high data rates, e.g. 192 kHz >> sampling rate or 6 channels. >> When I load the g_audio driver with the above parameters (p_srate=192000 >> p_chmask=0x3F), I get this error message "dwc2 ff580000.usb: >> dwc2_hsotg_ep_enable: No suitable fifo found", followed by a full stack >> trace; as a result, the gadget driver is not operational. If I try to first >> load the driver with its default parameters, then unload it and reload it >> with the above parameters, then I don't see any error message, but the >> driver misbehaves: when I send audio from the USB peripheral to a host, the >> audio data is sent at the rate corresponding to the default parameters. For >> example, a speaker-test run which is supposed to output audio for 3 seconds >> to each channel takes a longer time, to be precise 36 seconds per channel, >> i.e. 12 times the amount it should take. 12 is exactly the ratio between the >> audio data rate with default parameters (48 kHz, 2 channels) and the rate >> with the (p_srate=192000 p_chmask=0x3F) settings. >> Using other combinations of parameter values, I get similar results, e.g. >> the audio is 3 times slower if I use 6 channels with the default 48 kHz >> sampling rate. >> >> So it looks like something gets misconfigured when the gadget driver is >> loaded and unloaded multiple times with different parameters, but my main >> question is about the "No suitable fifo found" error that I get when trying >> to load the g_audio driver: does it stem for an inherent hardware limitation >> of the dwc2 controller? is it specific to the SoC I'm using (Rockchip >> rk3288)? or is it possible via code changes to the dwc2 driver to overcome >> these issues? >> >> For the record, I'm using the latest kernel stable release (4.11.2). > > Since the g_audio module is now a legacy driver and there is a better > way (configfs) for setting up a USB gadget as a UAC2 device, I tried > following the configfs route, but unfortunately the end result is the > same: above a certain audio data rate, when I bind the gadget to the > UDC controller I get the "No suitable fifo found" error followed by a > stack trace. > I also tried to configure first the gadget with supported parameters > (2 channels, 4 bytes per sample, 44.1 kHz), then disable the gadget > and clean up its configuration, and then re-configure it with > different parameter values (e.g. 96 kHz instead of 44.1): this time it > doesn't give any error, but it is somehow using (at least in part) the > older settings, because the audio flows at the same speed as it would > flow with the older settings. > So the behavior is the same as with the legacy g_audio driver. Any > clue on what is going on? And is this a limitation of the UDC > controller, or can the issue be solved with driver changes? > Some UDC controllers use fixed length buffer divided among all EPs so no one EP may have large enough buffer to support high bandwidth required, while others may have unnecessary space. So may be look into the cause of message "No suitable fifo found" -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
