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

From: Wesley Cheng
Date: Wed Oct 18 2023 - 16:21:05 EST

Hi Pierre,

On 10/18/2023 6:54 AM, Pierre-Louis Bossart wrote:


On 10/17/23 19:25, Wesley Cheng wrote:
Hi Pierre,

On 10/17/2023 1:58 PM, Pierre-Louis Bossart wrote:
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.


Thanks for the review!

Sure, maybe I can write a more comprehensive documentation that saves
these details somewhere.  Will add a RST documentation for material
where necessary.

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'?


This would be the Q6USB entity which is the DPCM backend for this
particular audio path.

DPCM is about dailinks. Technically the q6usb entity is a codec dai
which is part of a DPCM backend dailink.

   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.


"Port" in this explanation refers to the USB port.  So the audio device
connected.  You are right that a USB device can enumerate w/ multiple
interfaces (ie UAC + HID + ...) so the closest relation to "port" is
"interface."  It is not a 1:1 mapping w/ the number of endpoints exposed
by a device.

"AFE port" is just something that has been termed from the audio DSP
end, so that concept of port is not related to the port where USB
devices are connected to.  This is something that is defined within the
audio DSP.

Wow. So there's a "USB port" and "AFE port". I would recommend avoiding
the same term for completely different concepts. Why not use "USB device"?


I think maybe USB interface is probably the most acceptable, since even at the USB snd level, they work based on usb_interface, not on the udev (USB device) itself.

  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?


In the end, since the offload case is handled by the audio DSP, it would
have to go through the platform/machine sound card.  That is the sm8250
device above.

  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.


Do userspace entities look at this card string?  Assuming there is only
one platform card, there are situations where maybe multiple USB audio
devices are connected to the same USB root hub, so offloading can happen
on any one of them (not at the same time).

Jaroslav cares, as measured by the changes over the years to make the
card names more self-explanatory.

I really don't see anything in the SM8250MTPWCD938 card name that would
hint at the support of USB. If it's not in the card string, maybe this
can be added in the component string as well (amixer -Dhw:0 info). The
point is that userspace should not have to maintain an 'accept-list' of
card names but have the means to check the USB offload capability with a
vendor-neutral convention.

I'll take a look at adding it into the components string. At least in that case, we'd be able to dynamically modify to say if USB offload is supported or not based on the child entries/paths that are defined in the DT node.

Thanks
Wesley Cheng