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).
Thank you
Regards,
Francesco Lavra
--
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
