Re: [RFC PATCH 00/14] Introduce QC USB SND audio offloading support

[Wesley Cheng]

Hi Greg,

On 12/23/2022 10:45 PM, Greg KH wrote:
> On Fri, Dec 23, 2022 at 03:31:46PM -0800, Wesley Cheng wrote:
> > 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
> >
> > Adding ASoC binding layer:
> > soc-usb: Intention is to treat a USB port similar to a headphone jack.
> > 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
> > resources needed to initiate a playback stream using the Q6DSP.  Will
> > 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.
> >
> > 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:
> >   0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D
> >                        SM8250-MTP-WCD9380-WSA8810-VA-DMIC
> >   1 [Audio          ]: USB-Audio - USB Audio
> >                        Generic USB Audio at usb-xhci-hcd.1.auto-1.4, high speed
> >
> > 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
>
> This looks to duplicate a bunch of the same things that a number of
> different google developers have posted recently.  Please work with them
> to come up with a unified set of patches that you all can agree with,
> AND get them to sign off on the changes before resubmitting them.
>
> This uncoordinated drip of patches from different people doing the same
> thing is almost impossible to review from our side, as I'm sure you can
> imagine.

I saw some of the Google patchsets submitted awhile back, but didn't 
really get a chance to look at them in detail.  Let me reach out to 
Albert Wang to see if we can come to a solution that works for both 
implementations.

From the looks of it (at least from the XHCI HCD changes), it seems 
that a different set of resources is required for the Google 
implementation to work.  I'll need to ask for a bit more details before 
I can comment further...

> That being said, thank you finally for at least submitting all of the
> needed changes together as one patch set.  That's a first, and something
> we had been asking for for years.
>
> Have a good holiday break,

Thanks for the quick in-depth review, and the feedback.  Gives me some 
more things to think about improving over the break :).  Happy holidays!

Thanks
Wesley Cheng