Re: [PATCH v9 00/34] Introduce QC USB SND audio offloading support

From: Pierre-Louis Bossart
Date: Tue Oct 17 2023 - 19:23:16 EST


It's been a very long time since I reviewed earlier versions, and I am
still lost on terminology and concepts. The explanations below should
really be added as a .rst file in Documentation for reference, not just
as a cover letter.

> 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

"backend" is a loaded terms for ASoC. Can you clarify which part of the
ascii art below is a 'backend'?

> 3. Introduce XHCI interrupter support
> 4. Create vendor ops for the USB SND driver
>
> USB | ASoC
> --------------------------------------------------------------------
> | _________________________
> | |sm8250 platform card |
> | |_________________________|
> | | |
> | ___V____ ____V____
> | |Q6USB | |Q6AFE |
> | |"codec" | |"cpu" |
> | |________| |_________|
> | ^ ^ ^
> | | |________|
> | ___V____ |
> | |SOC-USB | |
> ________ ________ | | |
> |USB SND |<--->|QC offld|<------------>|________| |
> |(card.c)| | |<---------- |
> |________| |________|___ | | |
> ^ ^ | | | ____________V_________
> | | | | | |APR/GLINK |
> __ V_______________V_____ | | | |______________________|
> |USB SND (endpoint.c) | | | | ^
> |_________________________| | | | |
> ^ | | | ___________V___________
> | | | |->|audio DSP |
> ___________V_____________ | | |_______________________|
> |XHCI HCD |<- |
> |_________________________| |
>
>
> Adding ASoC binding layer:
> soc-usb: Intention is to treat a USB port similar to a headphone jack.

What is a 'port'? USB refers to "interfaces" and "endpoints". Is a
"port" a 1:1 mapping to "endpoint"?

Below I read "AFE port" so not sure what concepts refer to what.

> The port is always present on the device, but cable/pin status can be
> enabled/disabled. Expose mechanisms for USB backend ASoC drivers to
> communicate with USB SND.
>
> Create a USB backend for Q6DSP:
> q6usb: Basic backend driver that will be responsible for maintaining the

The asciiart above suggests that q6usb exposes a codec DAI - but the
backend dailink is created by the platform card?

> resources needed to initiate a playback stream using the Q6DSP. Will

is capture supported? there's explicit references to "num_capture" in
following patches.

> be the entity that checks to make sure the connected USB audio device
> supports the requested PCM format. If it does not, the PCM open call will
> fail, and userpsace ALSA can take action accordingly.
>
> Introduce XHCI interrupter support:
> XHCI HCD supports multiple interrupters, which allows for events to be routed
> to different event rings. This is determined by "Interrupter Target" field
> specified in Section "6.4.1.1 Normal TRB" of the XHCI specification.
>
> Events in the offloading case will be routed to an event ring that is assigned
> to the audio DSP.
>
> Create vendor ops for the USB SND driver:
> qc_audio_offload: This particular driver has several components associated
> with it:
> - QMI stream request handler
> - XHCI interrupter and resource management
> - audio DSP memory management
>
> When the audio DSP wants to enable a playback stream, the request is first
> received by the ASoC platform sound card. Depending on the selected route,
> ASoC will bring up the individual DAIs in the path. The Q6USB backend DAI
> will send an AFE port start command (with enabling the USB playback path), and
> the audio DSP will handle the request accordingly.

what about capture, e.g. for a headset?

> Part of the AFE USB port start handling will have an exchange of control
> messages using the QMI protocol. The qc_audio_offload driver will populate the
> buffer information:
> - Event ring base address
> - EP transfer ring base address
>
> and pass it along to the audio DSP. All endpoint management will now be handed
> over to the DSP, and the main processor is not involved in transfers.
>
> Overall, implementing this feature will still expose separate sound card and PCM
> devices for both the platorm card and USB audio device:

typo: platform

> 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D
> SM8250-MTP-WCD9380-WSA8810-VA-DMIC

How do you plan on exposing the USB PCM device?

The lines above are really cryptic, and with no USB reference in any of
the short/long card names it's not obvious that this card is different
from the no-offload case, is it?

> 1 [Audio ]: USB-Audio - USB Audio
> Generic USB Audio at usb-xhci-hcd.1.auto-1.4, high speed

likewise some sort of qualifier would be useful to show that card 0 and
card 1 can target the same USB endpoints.

> This is to ensure that userspace ALSA entities can decide which route to take
> when executing the audio playback. In the above, if card#1 is selected, then
> USB audio data will take the legacy path over the USB PCM drivers, etc...
>
> This feature was validated using:
> - tinymix: set/enable the multimedia path to route to USB backend
> - tinyplay: issue playback on platform card