Re: [PATCH v36 00/31] Introduce QC USB SND audio offloading support

[Wesley Cheng]

Hi Luca,

On 3/21/2025 6:13 AM, Luca Weiss wrote:
> Hi Wesley,
> 
> On Wed Mar 19, 2025 at 1:51 AM CET, Wesley Cheng wrote:
>> Requesting to see if we can get some Acked-By tags, and merge on usb-next.
>>
>> Several Qualcomm based chipsets can support USB audio offloading to a
>> dedicated audio DSP, which can take over issuing transfers to the USB
>> host controller.  The intention is to reduce the load on the main
>> processors in the SoC, and allow them to be placed into lower power modes.
>> There are several parts to this design:
>>   1. Adding ASoC binding layer
>>   2. Create a USB backend for Q6DSP
>>   3. Introduce XHCI interrupter support
>>   4. Create vendor ops for the USB SND driver
>>
> 
> I was able to test this series (v35) on SM6350/SM7225 Fairphone 4
> smartphone and it appears to work as expected!

Thank you for taking the time to testing this :), much appreciated.

> 
> Based on the sm8350 branch you shared[0] I added similar dts bits for my
> device, I've pushed that branch here[1] for reference.
> 
> [0] https://git.codelinaro.org/clo/linux-kernel/kernel-qcom/-/commits/usb_audio_offload/
> [1] https://github.com/sm6350-mainline/linux/commits/sm6350-6.14-wip-usb-snd-offload/
> 
> And I've used these commands to test:
> 
> fairphone-4:~$ amixer -c0 cset name='USB Mixer MultiMedia2' On
> 
> fairphone-4:~$ aplay -l
> **** List of PLAYBACK Hardware Devices ****
> card 0: F4 [Fairphone 4], device 0: MultiMedia1 (*) []
> Subdevices: 1/1
> Subdevice #0: subdevice #0
> card 0: F4 [Fairphone 4], device 1: MultiMedia2 (*) []
> Subdevices: 1/1
> Subdevice #0: subdevice #0
> card 1: Audio [Hi-Res Audio], device 0: USB Audio [USB Audio]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
> 
> fairphone-4:~$ ffmpeg -i test.m4a -acodec pcm_s16le test.wav
> 
> fairphone-4:~$ aplay --device=plughw:0,1 Music/test.wav
> Playing WAVE 'Music/test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
> 
> And then music was coming out of these headphones connected via a USB-C
> to 3.5mm dongle.
> 
> Every time I'm starting playback this error appears in dmesg, do you
> also see this on your test setup?
> 
> [ 1336.081525] q6afe-dai 3000000.remoteproc:glink-edge:apr:service@4:dais: AFE Port already open
> 

The print is coming because the Q6 USB backend DAI link is utilizing the
q6afe_port_get_from_id() API to fetch the proper AFE port to issue commands
to.  IMO, that log level should be decreased to at least dev_info() instead
of an error, but we can probably take that discussion into a different series.

To add, I also see this on my set up.

> 
> And if I'm not mistaken it's possible to check that actually the offload
> path is getting used by checking the interrupt counts of the xhci-hcd
> interrupt.
> 
> With regular USB audio card playback there's many interrupts per second
> happening:
> 
> fairphone-4:~$ aplay --device=plughw:1,0 Music/test.wav # regular USB
> fairphone-4:~$ cat /proc/interrupts | grep -i usb
> 188:     137524          0          0          0          0          0          0          0    GICv3 165 Level     xhci-hcd:usb1
> fairphone-4:~$ cat /proc/interrupts | grep -i usb
> 188:     137591          0          0          0          0          0          0          0    GICv3 165 Level     xhci-hcd:usb1
> 
> And with the offload card during playback there's no interrupts
> happening (just a few when initially starting playback):
> 
> fairphone-4:~$ aplay --device=plughw:0,1 Music/test.wav # offload
> fairphone-4:~$ cat /proc/interrupts | grep -i usb
> 188:     141947          0          0          0          0          0          0          0    GICv3 165 Level     xhci-hcd:usb1
> fairphone-4:~$ cat /proc/interrupts | grep -i usb
> 188:     141947          0          0          0          0          0          0          0    GICv3 165 Level     xhci-hcd:usb1
> 

This is correct.  With offload enabled, you should probably only see a few
interrupts from xHCI from the initial USB headset enumeration and control
transfers, but the data packets itself should result in no increase of the
xHCI IRQ.

Thanks
Wesley Cheng