On 4/28/25 9:41 AM, Luca Weiss wrote:
> On Fri Apr 25, 2025 at 11:06 PM CEST, Konrad Dybcio wrote:
>> On 4/25/25 12:44 PM, Luca Weiss wrote:
>>> Enable USB audio offloading which allows to play audio via a USB-C
>>> headset with lower power consumption and enabling some other features.
>>>
>>> This can be used like the following:
>>>
>>> $ amixer -c0 cset name='USB_RX Audio Mixer MultiMedia1' On
>>> $ aplay --device=plughw:0,0 test.wav
>>>
>>> Compared to regular playback to the USB sound card no interrupts should
>>> appear on the xhci-hcd interrupts during playback, instead the ADSP will
>>> be handling the playback.
>>
>> "should" isn't very optimistic - I assume this works for you? >
>
> Yes it does!
>
> With 'should' I meant to describe the expected behavior from using this
> since most people are probably not familiar with how this works.
>
>>> Signed-off-by: Luca Weiss <luca.we...@fairphone.com>
>>> ---
[...]
>>> &usb_1_dwc3 {
>>> maximum-speed = "super-speed";
>>> dr_mode = "otg";
>>> + num-hc-interrupters = /bits/ 16 <3>;
>> Where does this number come from?
>
> I'm honestly not 100% sure. As far as I understand it, with
> 'qcom,usb-audio-intr-idx = /bits/ 16 <2>;' in the qcom,q6usb node (which
> I've checked against downstream) we declare which "XHCI interrupter
> number to use". Without the num-hc-interrupters property we get an error
> that not enough interrupters are available (I assume only 1 is then), so
> this value practically needs to be higher than the <2> from earlier.
>
> Why it's this value and not a higher value e.g. 4 I'm not really sure.
> Downstream code looks somewhat different and "max_interrupters" in
> drivers/usb/ doesn't come from a dt property. I'd need to check more in
> details what this code does - or maybe Wesley can help.
I got word that it's simply hw specific - please move it over to the
soc dt with the value of 3
Konrad
