[v3,00/28] Introduce QC USB SND audio offloading support

  Changes in v3:
- Changed prefix from RFC to PATCH
- Rebased entire series to usb-next
- Updated copyright years

XHCI:
- Rebased changes on top of XHCI changes merged into usb-next, and only added
changes that were still under discussion.
- Added change to read in the "num-hc-interrupters" device property.

ASoC:
- qusb6 USB backend
  - Incorporated suggestions to fetch iommu information with existing APIs
  - Added two new sound kcontrols to fetch offload status and offload device
    selection.
    - offload status - will return the card and pcm device in use
        tinymix -D 0 get 1 --> 1, 0 (offload in progress on card#1 pcm#0)

    - device selection - set the card and pcm device to enable offload on. Ex.:
        tinymix -D 0 set 1 2 0  --> sets offload on card#2 pcm#0
                                    (this should be the USB card)

USB SND:
- Fixed up some locking related concerns for registering platform ops.
   - Moved callbacks under the register_mutex, so that 
- Modified APIs to properly pass more information about the USB SND device, so
that the Q6USB backend can build a device list/map, in order to monitor offload
status and device selection.

Changes in v2:

XHCI:
- Replaced XHCI and HCD changes with Mathias' XHCI interrupter changes
in his tree:
https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters

Adjustments made to Mathias' changes:
  - Created xhci-intr.h to export/expose interrupter APIs versus exposing xhci.h.
    Moved dependent structures to this file as well. (so clients can parse out
    information from "struct xhci_interrupter")
  - Added some basic locking when requesting interrupters.
  - Fixed up some sanity checks.
  - Removed clearing of the ERSTBA during freeing of the interrupter. (pending
    issue where SMMU fault occurs if DMA addr returned is 64b - TODO)

- Clean up pending events in the XHCI secondary interrupter.  While testing USB
bus suspend, it was seen that on bus resume, the xHCI HC would run into a command
timeout.
- Added offloading APIs to xHCI to fetch transfer and event ring information.

ASoC:
- Modified soc-usb to allow for multiple USB port additions.  For this to work,
the USB offload driver has to have a reference to the USB backend by adding
a "usb-soc-be" DT entry to the device saved into XHCI sysdev.
- Created separate dt-bindings for defining USB_RX port.
- Increased APR timeout to accommodate the situation where the AFE port start
command could be delayed due to having to issue a USB bus resume while
handling the QMI stream start command.

USB SND:
- Added a platform ops during usb_audio_suspend().  This allows for the USB
offload driver to halt the audio stream when system enters PM suspend.  This
ensures the audio DSP is not issuing transfers on the USB bus.
- Do not override platform ops if they are already populated.
- Introduce a shared status variable between the USB offload and USB SND layers,
to ensure that only one path is active at a time.  If the USB bus is occupied,
then userspace is notified that the path is busy.

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

Mathias Nyman (1):
  xhci: Add support to allocate several interrupters

Wesley Cheng (27):
  usb: xhci: Add XHCI APIs to support USB offloading
  usb: host: xhci-mem: Cleanup pending secondary event ring events
  ASoC: Add SOC USB APIs for adding an USB backend
  ASoC: dt-bindings: qcom,q6dsp-lpass-ports: Add USB_RX port
  ASoC: qcom: qdsp6: Introduce USB AFE port to q6dsp
  ASoC: qdsp6: q6afe: Increase APR timeout
  ASoC: qcom: Add USB backend ASoC driver for Q6
  sound: usb: card: Introduce USB SND platform op callbacks
  sound: usb: Export USB SND APIs for modules
  dt-bindings: usb: dwc3: Add snps,num-hc-interrupters definition
  usb: dwc3: Add DT parameter to specify maximum number of interrupters
  usb: host: xhci-plat: Set XHCI max interrupters if property is present
  sound: usb: pcm: Export fixed rate check USB SND API
  sound: usb: Introduce QC USB SND offloading support
  sound: usb: card: Check for support for requested audio format
  sound: soc: soc-usb: Add PCM format check API for USB backend
  sound: soc: qcom: qusb6: Ensure PCM format is supported by USB audio
    device
  sound: usb: Prevent starting of audio stream if in use
  ASoC: dt-bindings: Add Q6USB backend bindings
  ASoC: dt-bindings: Update example for enabling USB offload on SM8250
  ASoC: qcom: qdsp6: q6afe: Split USB AFE dev_token param into separate
    API
  sound: Pass USB SND card and PCM information to SOC USB
  sound: soc: qdsp6: Add SND kcontrol to select offload device
  sound: soc: qdsp6: Add SND kcontrol for fetching offload status
  sound: usb: qc_audio_offload: Use card and PCM index from QMI request
  sound: usb: card: Allow for rediscovery of connected USB SND devices
  sound: soc: soc-usb: Rediscover USB SND devices on USB port add

 .../bindings/sound/qcom,q6usb-dais.yaml       |   49 +
 .../bindings/sound/qcom,sm8250.yaml           |   15 +
 .../devicetree/bindings/usb/snps,dwc3.yaml    |   13 +
 drivers/usb/dwc3/core.c                       |   12 +
 drivers/usb/dwc3/core.h                       |    2 +
 drivers/usb/dwc3/host.c                       |    5 +-
 drivers/usb/host/xhci-debugfs.c               |    2 +-
 drivers/usb/host/xhci-mem.c                   |  171 +-
 drivers/usb/host/xhci-plat.c                  |    2 +
 drivers/usb/host/xhci-ring.c                  |    2 +-
 drivers/usb/host/xhci.c                       |  181 +-
 drivers/usb/host/xhci.h                       |    2 +-
 .../sound/qcom,q6dsp-lpass-ports.h            |    1 +
 include/linux/usb/xhci-intr.h                 |   94 +
 include/sound/pcm_params.h                    |    4 +
 include/sound/q6usboffload.h                  |   20 +
 include/sound/soc-usb.h                       |   39 +
 sound/core/oss/pcm_oss.c                      |   58 -
 sound/core/pcm_lib.c                          |   65 +
 sound/soc/Makefile                            |    2 +-
 sound/soc/qcom/Kconfig                        |    4 +
 sound/soc/qcom/qdsp6/Makefile                 |    1 +
 sound/soc/qcom/qdsp6/q6afe-dai.c              |   50 +
 sound/soc/qcom/qdsp6/q6afe.c                  |  208 +-
 sound/soc/qcom/qdsp6/q6afe.h                  |   47 +-
 sound/soc/qcom/qdsp6/q6dsp-lpass-ports.c      |   23 +
 sound/soc/qcom/qdsp6/q6dsp-lpass-ports.h      |    1 +
 sound/soc/qcom/qdsp6/q6routing.c              |    9 +
 sound/soc/qcom/qdsp6/q6usb.c                  |  445 ++++
 sound/soc/soc-usb.c                           |  197 ++
 sound/usb/Kconfig                             |   14 +
 sound/usb/Makefile                            |    2 +-
 sound/usb/card.c                              |   85 +
 sound/usb/card.h                              |   31 +
 sound/usb/endpoint.c                          |    2 +
 sound/usb/helper.c                            |    1 +
 sound/usb/pcm.c                               |   29 +-
 sound/usb/pcm.h                               |   12 +
 sound/usb/qcom/Makefile                       |    2 +
 sound/usb/qcom/qc_audio_offload.c             | 1790 +++++++++++++++++
 sound/usb/qcom/usb_audio_qmi_v01.c            |  892 ++++++++
 sound/usb/qcom/usb_audio_qmi_v01.h            |  162 ++
 42 files changed, 4646 insertions(+), 100 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/qcom,q6usb-dais.yaml
 create mode 100644 include/linux/usb/xhci-intr.h
 create mode 100644 include/sound/q6usboffload.h
 create mode 100644 include/sound/soc-usb.h
 create mode 100644 sound/soc/qcom/qdsp6/q6usb.c
 create mode 100644 sound/soc/soc-usb.c
 create mode 100644 sound/usb/qcom/Makefile
 create mode 100644 sound/usb/qcom/qc_audio_offload.c
 create mode 100644 sound/usb/qcom/usb_audio_qmi_v01.c
 create mode 100644 sound/usb/qcom/usb_audio_qmi_v01.h
  

On Wed, Mar 08, 2023 at 03:57:23PM -0800, Wesley Cheng wrote:
> Changes in v3:
> - Changed prefix from RFC to PATCH
> - Rebased entire series to usb-next
> - Updated copyright years

This is much better, thanks.  I've done some very brief high-level
skimming and found minor issues, and one major one.  I'll let others
review this in more depth right now, as I am way behind in reviewing
other USB patches and need to get to them first.

thanks,

greg k-h
  

On 3/8/23 17:57, Wesley Cheng wrote:
> Changes in v3:
> - Changed prefix from RFC to PATCH
> - Rebased entire series to usb-next
> - Updated copyright years

You may want to move the per-version changes after the description of
this patchset.

> XHCI:
> - Rebased changes on top of XHCI changes merged into usb-next, and only added
> changes that were still under discussion.
> - Added change to read in the "num-hc-interrupters" device property.
> 
> ASoC:
> - qusb6 USB backend
>   - Incorporated suggestions to fetch iommu information with existing APIs
>   - Added two new sound kcontrols to fetch offload status and offload device
>     selection.
>     - offload status - will return the card and pcm device in use
>         tinymix -D 0 get 1 --> 1, 0 (offload in progress on card#1 pcm#0)
> 
>     - device selection - set the card and pcm device to enable offload on. Ex.:
>         tinymix -D 0 set 1 2 0  --> sets offload on card#2 pcm#0
>                                     (this should be the USB card)
> 
> USB SND:
> - Fixed up some locking related concerns for registering platform ops.
>    - Moved callbacks under the register_mutex, so that 
> - Modified APIs to properly pass more information about the USB SND device, so
> that the Q6USB backend can build a device list/map, in order to monitor offload
> status and device selection.
> 
> Changes in v2:
> 
> XHCI:
> - Replaced XHCI and HCD changes with Mathias' XHCI interrupter changes
> in his tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters
> 
> Adjustments made to Mathias' changes:
>   - Created xhci-intr.h to export/expose interrupter APIs versus exposing xhci.h.
>     Moved dependent structures to this file as well. (so clients can parse out
>     information from "struct xhci_interrupter")
>   - Added some basic locking when requesting interrupters.
>   - Fixed up some sanity checks.
>   - Removed clearing of the ERSTBA during freeing of the interrupter. (pending
>     issue where SMMU fault occurs if DMA addr returned is 64b - TODO)
> 
> - Clean up pending events in the XHCI secondary interrupter.  While testing USB
> bus suspend, it was seen that on bus resume, the xHCI HC would run into a command
> timeout.
> - Added offloading APIs to xHCI to fetch transfer and event ring information.
> 
> ASoC:
> - Modified soc-usb to allow for multiple USB port additions.  For this to work,
> the USB offload driver has to have a reference to the USB backend by adding
> a "usb-soc-be" DT entry to the device saved into XHCI sysdev.
> - Created separate dt-bindings for defining USB_RX port.
> - Increased APR timeout to accommodate the situation where the AFE port start
> command could be delayed due to having to issue a USB bus resume while
> handling the QMI stream start command.
> 
> USB SND:
> - Added a platform ops during usb_audio_suspend().  This allows for the USB
> offload driver to halt the audio stream when system enters PM suspend.  This
> ensures the audio DSP is not issuing transfers on the USB bus.
> - Do not override platform ops if they are already populated.
> - Introduce a shared status variable between the USB offload and USB SND layers,
> to ensure that only one path is active at a time.  If the USB bus is occupied,
> then userspace is notified that the path is busy.


---> start of the 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

clarify what 'backend' means. I would guess you are referring to the
ASoC DPCM concept of Back-End, which typically exposes an audio
interface controlled by a DSP?

If yes, the description should be

"Create a Q6DSP ASoC DPCM BackEnd for USB audio playback/record".

>   3. Introduce XHCI interrupter support
>   4. Create vendor ops for the USB SND driver

Add an introduction as to why this would be needed? which 'vendor' are
we talking about, is this on the SOC side or the USB device side?

> 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.

port == backend?

Using different words for the same concept is a sure way to lose the
reviewers, and not describing different concepts isn't much better.

> Create a USB backend for Q6DSP:
> q6usb: Basic backend driver that will be responsible for maintaining the

What does this mean? Is this a module that registers a set of ASoC DAIs?

It's not clear to me what a 'backend driver' means either in a USB or
ASoC context.

> 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.

If it's an ASoC backend, there is no PCM open call. You're probably
referring to the hw_params, not the open/startup anyways.

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

so how does this 'qc_audio_offload' interface with 'q6usb' described
above? how are the roles different or complementary?

> 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...

I already voiced my concerns about exposing two cards, each with their
own set of volume controls with the same device. It would be much better
to have an additional offloaded PCM device for card0...

But if the consensus is to have two cards, it's still not clear how the
routing would be selected. In the case where there are two USB audio
devices attached, the offloaded path would only support one of the two.
How would userspace know which of the two is selected?

And how would userspace know the difference anyways between two physical
devices attached to the platform with no offload, and one physical
device with one additional offload path? The names you selected can't be
used to identify that card1 is the optimized version of card0.

Before we review low-level kernel plumbing, it would be good to give a
better overview of how userspace applications are supposed to interact
with the cards and identify the offloaded path. Testing with
tinyplay/tinymix is fine, but that's a developer-level or CI unit test.
we've got to see the broader picture of how a sound server would use
this USB offload capability.
  

Hi Pierre,

On 3/9/2023 9:13 AM, Pierre-Louis Bossart wrote:
> 
> 
> On 3/8/23 17:57, Wesley Cheng wrote:
>> Changes in v3:
>> - Changed prefix from RFC to PATCH
>> - Rebased entire series to usb-next
>> - Updated copyright years
> 
> You may want to move the per-version changes after the description of
> this patchset.
> 

Thanks for reading through this :).

Sure, will do that going forward.

>> XHCI:
>> - Rebased changes on top of XHCI changes merged into usb-next, and only added
>> changes that were still under discussion.
>> - Added change to read in the "num-hc-interrupters" device property.
>>
>> ASoC:
>> - qusb6 USB backend
>>    - Incorporated suggestions to fetch iommu information with existing APIs
>>    - Added two new sound kcontrols to fetch offload status and offload device
>>      selection.
>>      - offload status - will return the card and pcm device in use
>>          tinymix -D 0 get 1 --> 1, 0 (offload in progress on card#1 pcm#0)
>>
>>      - device selection - set the card and pcm device to enable offload on. Ex.:
>>          tinymix -D 0 set 1 2 0  --> sets offload on card#2 pcm#0
>>                                      (this should be the USB card)
>>
>> USB SND:
>> - Fixed up some locking related concerns for registering platform ops.
>>     - Moved callbacks under the register_mutex, so that
>> - Modified APIs to properly pass more information about the USB SND device, so
>> that the Q6USB backend can build a device list/map, in order to monitor offload
>> status and device selection.
>>
>> Changes in v2:
>>
>> XHCI:
>> - Replaced XHCI and HCD changes with Mathias' XHCI interrupter changes
>> in his tree:
>> https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters
>>
>> Adjustments made to Mathias' changes:
>>    - Created xhci-intr.h to export/expose interrupter APIs versus exposing xhci.h.
>>      Moved dependent structures to this file as well. (so clients can parse out
>>      information from "struct xhci_interrupter")
>>    - Added some basic locking when requesting interrupters.
>>    - Fixed up some sanity checks.
>>    - Removed clearing of the ERSTBA during freeing of the interrupter. (pending
>>      issue where SMMU fault occurs if DMA addr returned is 64b - TODO)
>>
>> - Clean up pending events in the XHCI secondary interrupter.  While testing USB
>> bus suspend, it was seen that on bus resume, the xHCI HC would run into a command
>> timeout.
>> - Added offloading APIs to xHCI to fetch transfer and event ring information.
>>
>> ASoC:
>> - Modified soc-usb to allow for multiple USB port additions.  For this to work,
>> the USB offload driver has to have a reference to the USB backend by adding
>> a "usb-soc-be" DT entry to the device saved into XHCI sysdev.
>> - Created separate dt-bindings for defining USB_RX port.
>> - Increased APR timeout to accommodate the situation where the AFE port start
>> command could be delayed due to having to issue a USB bus resume while
>> handling the QMI stream start command.
>>
>> USB SND:
>> - Added a platform ops during usb_audio_suspend().  This allows for the USB
>> offload driver to halt the audio stream when system enters PM suspend.  This
>> ensures the audio DSP is not issuing transfers on the USB bus.
>> - Do not override platform ops if they are already populated.
>> - Introduce a shared status variable between the USB offload and USB SND layers,
>> to ensure that only one path is active at a time.  If the USB bus is occupied,
>> then userspace is notified that the path is busy.
> 
> 
> ---> start of the 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
> 
> clarify what 'backend' means. I would guess you are referring to the
> ASoC DPCM concept of Back-End, which typically exposes an audio
> interface controlled by a DSP?
> 
> If yes, the description should be
> 
> "Create a Q6DSP ASoC DPCM BackEnd for USB audio playback/record".
> 

You're correct.  "backend" was referring to a Q6DSP ASoC DPCM backend.

>>    3. Introduce XHCI interrupter support
>>    4. Create vendor ops for the USB SND driver
> 
> Add an introduction as to why this would be needed? which 'vendor' are
> we talking about, is this on the SOC side or the USB device side?
> 

This would be referring to the SoC side.  For example, QCOM can 
potentially have a different implementation of offloading USB SND to the 
audio DSP versus another OEM.  This is to allow those other entities to 
be able to define their own offload methodology.

For the most part, the common operations across all offloading 
implementations have so far is being able to handle USB SND 
connect/disconnect events.

>> 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.
> 
> port == backend?
> 
> Using different words for the same concept is a sure way to lose the
> reviewers, and not describing different concepts isn't much better.
> 

Yes, port is corresponding to the

>> Create a USB backend for Q6DSP:
>> q6usb: Basic backend driver that will be responsible for maintaining the
> 
> What does this mean? Is this a module that registers a set of ASoC DAIs?
> 
> It's not clear to me what a 'backend driver' means either in a USB or
> ASoC context.
> 

Will fix this up next time.  It refers to a Q6DSP DPCM ASoC backend, as 
you mentioned above.

>> 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.
> 
> If it's an ASoC backend, there is no PCM open call. You're probably
> referring to the hw_params, not the open/startup anyways.
> 

Correct.  Will fix this.

>>
>> 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
> 
> so how does this 'qc_audio_offload' interface with 'q6usb' described
> above? how are the roles different or complementary?
> 
So in general you can think that the qc_audio_offload is a complement to 
the USB SND USB class driver, while q6usb is to ASoC.  Since the ASoC 
framework doesn't have any communication with USB SND, the ASoC DPCM USB 
backend (q6usb) will have to be the entity that maintains what is going 
on in USB SND.  That way, sessions initiated through the ASoC managed 
sound card can evaluate what is available based on information reported 
by q6usb.

qc_audio_offload and q6usb will have some interaction between each 
other.  The majority of communication between qc_audio_offload and q6usb 
is reporting the device connection events.

>> 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...
> 
> I already voiced my concerns about exposing two cards, each with their
> own set of volume controls with the same device. It would be much better
> to have an additional offloaded PCM device for card0...
> 
> But if the consensus is to have two cards, it's still not clear how the
> routing would be selected. In the case where there are two USB audio
> devices attached, the offloaded path would only support one of the two.
> How would userspace know which of the two is selected?
> 

With patch#24:
https://lore.kernel.org/linux-usb/20230308235751.495-25-quic_wcheng@quicinc.com/T/#u

Now, userspace can at least choose which device it wants to offload. 
Part of doing that would mean userspace knows what USB SND card devices 
are available, so it is aware of which devices are shared (between the 
offload and USB SND path)

> And how would userspace know the difference anyways between two physical
> devices attached to the platform with no offload, and one physical
> device with one additional offload path? The names you selected can't be
> used to identify that card1 is the optimized version of card0.
> 

Is userspace currently able to differentiate between cards that are 
created by USB SND versus ASoC?  How complex can the userspace card 
discovery be?  Can it query kcontrols at this point in time?  If so, 
maybe we can change the names of the newly added ones to reflect that it 
is an offload device?

SND kcontrol names are currently:
Q6USB offload status
Q6USB offload SND device select

> Before we review low-level kernel plumbing, it would be good to give a
> better overview of how userspace applications are supposed to interact
> with the cards and identify the offloaded path. Testing with
> tinyplay/tinymix is fine, but that's a developer-level or CI unit test.
> we've got to see the broader picture of how a sound server would use
> this USB offload capability.

Sure, I think that is fine.  I was hoping that at least adding some of 
the new kcontrols would help userspace make use of this path in general, 
but we can add more information if required.

Thanks
Wesley Cheng
  

>>> 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
>>
>> so how does this 'qc_audio_offload' interface with 'q6usb' described
>> above? how are the roles different or complementary?
>>
> So in general you can think that the qc_audio_offload is a complement to
> the USB SND USB class driver, while q6usb is to ASoC.  Since the ASoC

Humm, that is far from clear. I don't get how a something that interacts
with the USB class driver can also be in charge of the audio DSP memory
management.

> framework doesn't have any communication with USB SND, the ASoC DPCM USB
> backend (q6usb) will have to be the entity that maintains what is going
> on in USB SND.  That way, sessions initiated through the ASoC managed
> sound card can evaluate what is available based on information reported
> by q6usb.
> 
> qc_audio_offload and q6usb will have some interaction between each
> other.  The majority of communication between qc_audio_offload and q6usb
> is reporting the device connection events.

It's already complicated to figure out how the DSP and USB class driver
might interact and probe/timing dependencies, but with two additional
drivers in the mix it's really hard to understand.

Maybe ascii-art would help describe the concepts and types of
information exchanged. Maintaining a consistent state across multiple
drivers is not an easy task.

> 
>>> 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...
>>
>> I already voiced my concerns about exposing two cards, each with their
>> own set of volume controls with the same device. It would be much better
>> to have an additional offloaded PCM device for card0...
>>
>> But if the consensus is to have two cards, it's still not clear how the
>> routing would be selected. In the case where there are two USB audio
>> devices attached, the offloaded path would only support one of the two.
>> How would userspace know which of the two is selected?
>>
> 
> With patch#24:
> https://lore.kernel.org/linux-usb/20230308235751.495-25-quic_wcheng@quicinc.com/T/#u
> 
> Now, userspace can at least choose which device it wants to offload.
> Part of doing that would mean userspace knows what USB SND card devices
> are available, so it is aware of which devices are shared (between the
> offload and USB SND path)
> 
>> And how would userspace know the difference anyways between two physical
>> devices attached to the platform with no offload, and one physical
>> device with one additional offload path? The names you selected can't be
>> used to identify that card1 is the optimized version of card0.
>>
> 
> Is userspace currently able to differentiate between cards that are
> created by USB SND versus ASoC?  How complex can the userspace card
> discovery be?  Can it query kcontrols at this point in time?  If so,
> maybe we can change the names of the newly added ones to reflect that it
> is an offload device?
> 
> SND kcontrol names are currently:
> Q6USB offload status
> Q6USB offload SND device select

I must admit I've never seen kcontrols being used to identify what the
card is, and in this case it's a pretend-card that's just an improved
version of another. It might be easier to use something else, such as
the component strings.
> 
>> Before we review low-level kernel plumbing, it would be good to give a
>> better overview of how userspace applications are supposed to interact
>> with the cards and identify the offloaded path. Testing with
>> tinyplay/tinymix is fine, but that's a developer-level or CI unit test.
>> we've got to see the broader picture of how a sound server would use
>> this USB offload capability.
> 
> Sure, I think that is fine.  I was hoping that at least adding some of
> the new kcontrols would help userspace make use of this path in general,
> but we can add more information if required.

Can I ask if this solution has been used with a complete userspace stack
already? I could see how this might be used with a relatively fixed
Android HAL, where the platform and routing are relatively controlled. I
don't see how a more generic audio server would deal with the discovery
and routing.
  

Hi Pierre,

On 3/9/2023 4:37 PM, Pierre-Louis Bossart wrote:
> 
>>>> 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
>>>
>>> so how does this 'qc_audio_offload' interface with 'q6usb' described
>>> above? how are the roles different or complementary?
>>>
>> So in general you can think that the qc_audio_offload is a complement to
>> the USB SND USB class driver, while q6usb is to ASoC.  Since the ASoC
> 
> Humm, that is far from clear. I don't get how a something that interacts
> with the USB class driver can also be in charge of the audio DSP memory
> management.
> 

This is because the USB class driver is the entity which is going to 
work with the USB HCD (XHCI) in this case to fetch the required 
addresses, and map that into memory accessible by the audio DSP.  It 
would be odd to be doing that from the q6usb end, which is part of the 
ASoC layer.

>> framework doesn't have any communication with USB SND, the ASoC DPCM USB
>> backend (q6usb) will have to be the entity that maintains what is going
>> on in USB SND.  That way, sessions initiated through the ASoC managed
>> sound card can evaluate what is available based on information reported
>> by q6usb.
>>
>> qc_audio_offload and q6usb will have some interaction between each
>> other.  The majority of communication between qc_audio_offload and q6usb
>> is reporting the device connection events.
> 
> It's already complicated to figure out how the DSP and USB class driver
> might interact and probe/timing dependencies, but with two additional
> drivers in the mix it's really hard to understand.
> 

I did test some cases based on existence of both these drivers 
(qc_audio_offload and q6usb).  If either one doesn't exist in the 
system, then the offload path would not work.  I did improve some of 
these potential sequences in the latest revision, such as patch#28. This 
would address scenarios where the q6usb ASoC DPCM backend wasn't probed, 
while the USB SND (and qc_audio_offload) were still detecting device 
connections.

Once the Q6USB driver is probed, then the offload snd kcontrols would be 
created, and devices would be properly identified with the rediscover api.

> Maybe ascii-art would help describe the concepts and types of
> information exchanged. Maintaining a consistent state across multiple
> drivers is not an easy task.
> 

Hopefully this might help?  I know its a lot to read through.

      USB                          |            ASoC
--------------------------------------------------------------------
                                   |  _________________________
                                   | |sm8250 platform card     |
                                   | |_________________________|
                                   |         |           |
                                   |      ___V____   ____V____
                                   |     |Q6USB   | |Q6AFE    |  #5
                                   |     |"codec" | |"cpu"    |
                                   |     |________| |_________|
                                   |         ^
                                   |         |  #6
                                   |      ___V____
                                   |     |SOC-USB |
   ________   #1  ________         #7    |        |
  |USB SND |<--->|QC offld|<------------>|________|
  |(card.c)|     |        |<----------       ^
  |________|     |________|___ #4  | |       |
      ^               ^       |    | |    ___V__________________
      | #2            |  #2   |    | |   |APR/GLINK             |
   __ V_______________V_____  |    | |   |______________________|
  |USB SND (endpoint.c)     | |    | |              ^
  |_________________________| |    | | #8           |
              ^               |    | |   ___________V___________
              | #3            |    | |->|audio DSP              |
   ___________V_____________  |    |    |_______________________|
  |XHCI HCD                 |<-    |
  |_________________________|      |


#1 - USB SND and QC offload:
Initialization:
- Register platform operations, to receive connect/disconnect events
   from USB SND.
- QC offload creates a QMI handle, in order to receive QMI requests
   from the audio DSP.

Runtime:
- USB SND passes along "struct snd_usb_audio" in order for QC offload
   to reference USB UAC desc parsing/USB SND helper APIs.
- USB device disconnection events will result in clearing of the chip
   entry.

#2 - USB SND and QC offload endpoints:
Runtime:
- In the non-offloaded path, USB snd will utilize functions exposed by
   USB SND endpoint, to help with fetching USB EP references and queuing
   URBs.
- In the offload path, qc offload will utilize the functions to fetch
   USB EP references, so that it can use that information to query the
   XHCI HCD.
- Likewise, both will clean up endpoints when audio stream is not in use.

#3 - XHCI HCD:
Initialization:
- During XHCI probe timing, when the USB HCD is added to the system, it
   will also initialize the secondary event rings.

Runtime:
- During USB device plug ins/outs, allocates device slot, assigns eps,
   and initializes transfer rings.

#4 - QC offload and XHCI:
Runtime:
- QC offload needs to reference the transfer ring and secondary event ring
   addresses by executing XHCI offload management APIs.
- This happens when audio DSP receives a USB QMI stream request.

#5 - ASoC components:
Initialization:
- The SM8250 platform sound card driver fetches DT node entries defining
   the ASoC links. This chain/link has the components involved for a
   particular Q6AFE path. (not only USB offload)
     - "cpu" - this is the ASoC CPU DAI that handles interaction with the
               Q6 DSP's audio protocol. (AFE ports)
     - "codec" - the ASoC codec (backend) DAI defined
- Registers ASoC platform sound card based on links defined in the DT node.
   - Probes DAI components involved, ie Q6USB and Q6AFE

Runtime:
- Q6AFE has the bulk of the interaction w/ the audio DSP to start an audio
   session, such as issuing AFE port start commands (part of the protocol
   used to communicate the audio session info)
- Q6USB will be there to now check for if format requested is supported by
   the device, and maintain offloading status.

#6 - Q6USB and SOC-USB:
Initialization:
- Q6USB will query QC offload for USB device connection states. (through
   soc-usb)
- Creates a SOC USB entry, that carries information about resources,
   such as audio DSP memory information and requested XHCI event ring
   index.

Runtime:
- SOC-USB will receive connect/disconnect events and propagate to Q6USB.
   - Q6USB makes devices available for offloading based on these events.
- Sets Q6AFE port configurations to select the USB SND card# and PCM#.

#7 - SOC-USB and QC offload:
Initialization:
- Rediscover USB SND devices when the SOC-USB entry is created (if needed)
     - For situations where the Q6USB DAI hasn't been probed.

Runtime:
- Propagate connect/disconnect events.

#8 - audio DSP and QC offload:
Runtime:
- Handle QMI requests coming from audio DSP.  These requests come AFTER
   the Q6AFE port is opened by the Q6AFE DAI(#6)
- Returns memory information about resources allocated by XHCI.
- Enables audio playback when this QMI transaction is completed.

>>
>>>> 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...
>>>
>>> I already voiced my concerns about exposing two cards, each with their
>>> own set of volume controls with the same device. It would be much better
>>> to have an additional offloaded PCM device for card0...
>>>
>>> But if the consensus is to have two cards, it's still not clear how the
>>> routing would be selected. In the case where there are two USB audio
>>> devices attached, the offloaded path would only support one of the two.
>>> How would userspace know which of the two is selected?
>>>
>>
>> With patch#24:
>> https://lore.kernel.org/linux-usb/20230308235751.495-25-quic_wcheng@quicinc.com/T/#u
>>
>> Now, userspace can at least choose which device it wants to offload.
>> Part of doing that would mean userspace knows what USB SND card devices
>> are available, so it is aware of which devices are shared (between the
>> offload and USB SND path)
>>
>>> And how would userspace know the difference anyways between two physical
>>> devices attached to the platform with no offload, and one physical
>>> device with one additional offload path? The names you selected can't be
>>> used to identify that card1 is the optimized version of card0.
>>>
>>
>> Is userspace currently able to differentiate between cards that are
>> created by USB SND versus ASoC?  How complex can the userspace card
>> discovery be?  Can it query kcontrols at this point in time?  If so,
>> maybe we can change the names of the newly added ones to reflect that it
>> is an offload device?
>>
>> SND kcontrol names are currently:
>> Q6USB offload status
>> Q6USB offload SND device select
> 
> I must admit I've never seen kcontrols being used to identify what the
> card is, and in this case it's a pretend-card that's just an improved
> version of another. It might be easier to use something else, such as
> the component strings.

Its not exactly a pretend card, right?  This is part of the overall 
platform sound card we have in the system.  At the moment, I'm only 
testing by adding the USB audio routing, but there can be several ASoC 
links defined in the overall platform card.

The Q6AFE CPU DAI has multiple audio AFE "ports" they can handle.  USB 
is only one of those.

>>
>>> Before we review low-level kernel plumbing, it would be good to give a
>>> better overview of how userspace applications are supposed to interact
>>> with the cards and identify the offloaded path. Testing with
>>> tinyplay/tinymix is fine, but that's a developer-level or CI unit test.
>>> we've got to see the broader picture of how a sound server would use
>>> this USB offload capability.
>>
>> Sure, I think that is fine.  I was hoping that at least adding some of
>> the new kcontrols would help userspace make use of this path in general,
>> but we can add more information if required.
> 
> Can I ask if this solution has been used with a complete userspace stack
> already? I could see how this might be used with a relatively fixed

Its been used only with the Android HAL.

> Android HAL, where the platform and routing are relatively controlled. I
> don't see how a more generic audio server would deal with the discovery
> and routing.
> 

This is why your input is helpful, since it provides another use case 
that wasn't considered.  I think in our previous discussions the tagging 
possibility was a good idea, and was hoping that it could help.  Could 
tag all USB SND cards to the platform sound card as well, and if the 
power saving path is chosen, it would issue the playback on the platform 
sound card. (if not in use)

In this case, the offload path wouldn't be the default routing, and only 
enabled for power optimized path.

Thanks
Wesley Cheng
  

On 3/13/23 18:43, Wesley Cheng wrote:
> Hi Pierre,
> 
> On 3/9/2023 4:37 PM, Pierre-Louis Bossart wrote:
>>
>>>>> 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
>>>>
>>>> so how does this 'qc_audio_offload' interface with 'q6usb' described
>>>> above? how are the roles different or complementary?
>>>>
>>> So in general you can think that the qc_audio_offload is a complement to
>>> the USB SND USB class driver, while q6usb is to ASoC.  Since the ASoC
>>
>> Humm, that is far from clear. I don't get how a something that interacts
>> with the USB class driver can also be in charge of the audio DSP memory
>> management.
>>
> 
> This is because the USB class driver is the entity which is going to
> work with the USB HCD (XHCI) in this case to fetch the required
> addresses, and map that into memory accessible by the audio DSP.  It
> would be odd to be doing that from the q6usb end, which is part of the
> ASoC layer.
> 
>>> framework doesn't have any communication with USB SND, the ASoC DPCM USB
>>> backend (q6usb) will have to be the entity that maintains what is going
>>> on in USB SND.  That way, sessions initiated through the ASoC managed
>>> sound card can evaluate what is available based on information reported
>>> by q6usb.
>>>
>>> qc_audio_offload and q6usb will have some interaction between each
>>> other.  The majority of communication between qc_audio_offload and q6usb
>>> is reporting the device connection events.
>>
>> It's already complicated to figure out how the DSP and USB class driver
>> might interact and probe/timing dependencies, but with two additional
>> drivers in the mix it's really hard to understand.
>>
> 
> I did test some cases based on existence of both these drivers
> (qc_audio_offload and q6usb).  If either one doesn't exist in the
> system, then the offload path would not work.  I did improve some of
> these potential sequences in the latest revision, such as patch#28. This
> would address scenarios where the q6usb ASoC DPCM backend wasn't probed,
> while the USB SND (and qc_audio_offload) were still detecting device
> connections.
> 
> Once the Q6USB driver is probed, then the offload snd kcontrols would be
> created, and devices would be properly identified with the rediscover api.
> 
>> Maybe ascii-art would help describe the concepts and types of
>> information exchanged. Maintaining a consistent state across multiple
>> drivers is not an easy task.
>>
> 
> Hopefully this might help?  I know its a lot to read through.

It's very helpful! Thanks for spending the time to illustrate the
different building blocks.

> 
>      USB                          |            ASoC
> --------------------------------------------------------------------
>                                   |  _________________________
>                                   | |sm8250 platform card     |
>                                   | |_________________________|
>                                   |         |           |
>                                   |      ___V____   ____V____
>                                   |     |Q6USB   | |Q6AFE    |  #5
>                                   |     |"codec" | |"cpu"    |
>                                   |     |________| |_________|
>                                   |         ^
>                                   |         |  #6
>                                   |      ___V____
>                                   |     |SOC-USB |
>   ________   #1  ________         #7    |        |
>  |USB SND |<--->|QC offld|<------------>|________|
>  |(card.c)|     |        |<----------       ^
>  |________|     |________|___ #4  | |       |
>      ^               ^       |    | |    ___V__________________
>      | #2            |  #2   |    | |   |APR/GLINK             |
>   __ V_______________V_____  |    | |   |______________________|
>  |USB SND (endpoint.c)     | |    | |              ^
>  |_________________________| |    | | #8           |
>              ^               |    | |   ___________V___________
>              | #3            |    | |->|audio DSP              |
>   ___________V_____________  |    |    |_______________________|
>  |XHCI HCD                 |<-    |
>  |_________________________|      |
> 
> 
> #1 - USB SND and QC offload:
> Initialization:
> - Register platform operations, to receive connect/disconnect events
>   from USB SND.
> - QC offload creates a QMI handle, in order to receive QMI requests
>   from the audio DSP.
> 
> Runtime:
> - USB SND passes along "struct snd_usb_audio" in order for QC offload
>   to reference USB UAC desc parsing/USB SND helper APIs.
> - USB device disconnection events will result in clearing of the chip
>   entry.
> 
> #2 - USB SND and QC offload endpoints:
> Runtime:
> - In the non-offloaded path, USB snd will utilize functions exposed by
>   USB SND endpoint, to help with fetching USB EP references and queuing
>   URBs.
> - In the offload path, qc offload will utilize the functions to fetch
>   USB EP references, so that it can use that information to query the
>   XHCI HCD.
> - Likewise, both will clean up endpoints when audio stream is not in use.
> 
> #3 - XHCI HCD:
> Initialization:
> - During XHCI probe timing, when the USB HCD is added to the system, it
>   will also initialize the secondary event rings.
> 
> Runtime:
> - During USB device plug ins/outs, allocates device slot, assigns eps,
>   and initializes transfer rings.
> 
> #4 - QC offload and XHCI:
> Runtime:
> - QC offload needs to reference the transfer ring and secondary event ring
>   addresses by executing XHCI offload management APIs.
> - This happens when audio DSP receives a USB QMI stream request.
> 
> #5 - ASoC components:
> Initialization:
> - The SM8250 platform sound card driver fetches DT node entries defining
>   the ASoC links. This chain/link has the components involved for a
>   particular Q6AFE path. (not only USB offload)
>     - "cpu" - this is the ASoC CPU DAI that handles interaction with the
>               Q6 DSP's audio protocol. (AFE ports)
>     - "codec" - the ASoC codec (backend) DAI defined
> - Registers ASoC platform sound card based on links defined in the DT node.
>   - Probes DAI components involved, ie Q6USB and Q6AFE
> 
> Runtime:
> - Q6AFE has the bulk of the interaction w/ the audio DSP to start an audio
>   session, such as issuing AFE port start commands (part of the protocol
>   used to communicate the audio session info)
> - Q6USB will be there to now check for if format requested is supported by
>   the device, and maintain offloading status.
> 
> #6 - Q6USB and SOC-USB:
> Initialization:
> - Q6USB will query QC offload for USB device connection states. (through
>   soc-usb)
> - Creates a SOC USB entry, that carries information about resources,
>   such as audio DSP memory information and requested XHCI event ring
>   index.
> 
> Runtime:
> - SOC-USB will receive connect/disconnect events and propagate to Q6USB.
>   - Q6USB makes devices available for offloading based on these events.
> - Sets Q6AFE port configurations to select the USB SND card# and PCM#.
> 
> #7 - SOC-USB and QC offload:
> Initialization:
> - Rediscover USB SND devices when the SOC-USB entry is created (if needed)
>     - For situations where the Q6USB DAI hasn't been probed.
> 
> Runtime:
> - Propagate connect/disconnect events.

Is the SOC-USB module or building blocks intended to be generic or
Qualcomm agnostic?

It's not clear to me how it would handle "audio DSP memory information
and requested XHCI event ring index."

In addition, it seems to be the "bridge" or means of communication
between qc_audio_offload and q6usb, is this not based on custom events
or triggers?

Along the same lines, this SOC-USB entity interfaces with APR/GLINK
which doesn't speak to me so it must be a QCOM interface?

I am trying to see if this design could be used for other architectures,
and the QCOM-specific and generic parts are not obvious.

> #8 - audio DSP and QC offload:
> Runtime:
> - Handle QMI requests coming from audio DSP.  These requests come AFTER
>   the Q6AFE port is opened by the Q6AFE DAI(#6)
> - Returns memory information about resources allocated by XHCI.
> - Enables audio playback when this QMI transaction is completed.
> 
>>>
>>>>> 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...
>>>>
>>>> I already voiced my concerns about exposing two cards, each with their
>>>> own set of volume controls with the same device. It would be much
>>>> better
>>>> to have an additional offloaded PCM device for card0...
>>>>
>>>> But if the consensus is to have two cards, it's still not clear how the
>>>> routing would be selected. In the case where there are two USB audio
>>>> devices attached, the offloaded path would only support one of the two.
>>>> How would userspace know which of the two is selected?
>>>>
>>>
>>> With patch#24:
>>> https://lore.kernel.org/linux-usb/20230308235751.495-25-quic_wcheng@quicinc.com/T/#u
>>>
>>> Now, userspace can at least choose which device it wants to offload.
>>> Part of doing that would mean userspace knows what USB SND card devices
>>> are available, so it is aware of which devices are shared (between the
>>> offload and USB SND path)
>>>
>>>> And how would userspace know the difference anyways between two
>>>> physical
>>>> devices attached to the platform with no offload, and one physical
>>>> device with one additional offload path? The names you selected
>>>> can't be
>>>> used to identify that card1 is the optimized version of card0.
>>>>
>>>
>>> Is userspace currently able to differentiate between cards that are
>>> created by USB SND versus ASoC?  How complex can the userspace card
>>> discovery be?  Can it query kcontrols at this point in time?  If so,
>>> maybe we can change the names of the newly added ones to reflect that it
>>> is an offload device?
>>>
>>> SND kcontrol names are currently:
>>> Q6USB offload status
>>> Q6USB offload SND device select
>>
>> I must admit I've never seen kcontrols being used to identify what the
>> card is, and in this case it's a pretend-card that's just an improved
>> version of another. It might be easier to use something else, such as
>> the component strings.
> 
> Its not exactly a pretend card, right?  This is part of the overall
> platform sound card we have in the system.  At the moment, I'm only
> testing by adding the USB audio routing, but there can be several ASoC
> links defined in the overall platform card.

Sorry, I misunderstood the proposal. I thought there would be one card
for "generic USB Audio", and another one for "DSP-offloaded USB Audio".
I assumed, probably mistakenly, that all local audio endpoints
(speaker,mics) would be exposed as a separate card.

It looks like it's more "generic USB Audio" and "DSP Audio", with the
USB offload being exposed as a PCM device of the latter.

Did I get this right? In this case, presumably there can be some sort of
UCM file for the "DSP Audio card" that contains the configuration or
knows which kcontrols to look for. But my point about detection hold.
You could perfectly well have a 'Jack control' that tells userspace when
a device is connected. That way there's no guess work, it's similar to
HDMI for Intel: the device is exposed but only valid when the jack
control is set.

> The Q6AFE CPU DAI has multiple audio AFE "ports" they can handle.  USB
> is only one of those.
> 
>>>
>>>> Before we review low-level kernel plumbing, it would be good to give a
>>>> better overview of how userspace applications are supposed to interact
>>>> with the cards and identify the offloaded path. Testing with
>>>> tinyplay/tinymix is fine, but that's a developer-level or CI unit test.
>>>> we've got to see the broader picture of how a sound server would use
>>>> this USB offload capability.
>>>
>>> Sure, I think that is fine.  I was hoping that at least adding some of
>>> the new kcontrols would help userspace make use of this path in general,
>>> but we can add more information if required.
>>
>> Can I ask if this solution has been used with a complete userspace stack
>> already? I could see how this might be used with a relatively fixed
> 
> Its been used only with the Android HAL.

ok, that aligns with what I was thinking.

> 
>> Android HAL, where the platform and routing are relatively controlled. I
>> don't see how a more generic audio server would deal with the discovery
>> and routing.
>>
> 
> This is why your input is helpful, since it provides another use case
> that wasn't considered.  I think in our previous discussions the tagging
> possibility was a good idea, and was hoping that it could help.  Could
> tag all USB SND cards to the platform sound card as well, and if the
> power saving path is chosen, it would issue the playback on the platform
> sound card. (if not in use)
> 
> In this case, the offload path wouldn't be the default routing, and only
> enabled for power optimized path.
> 
> Thanks
> Wesley Cheng
  

Hi Pierre,

On 3/13/2023 5:42 PM, Pierre-Louis Bossart wrote:
> 
> 
> On 3/13/23 18:43, Wesley Cheng wrote:
>> Hi Pierre,
>>
>> On 3/9/2023 4:37 PM, Pierre-Louis Bossart wrote:
>>>
>>>>>> 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
>>>>>
>>>>> so how does this 'qc_audio_offload' interface with 'q6usb' described
>>>>> above? how are the roles different or complementary?
>>>>>
>>>> So in general you can think that the qc_audio_offload is a complement to
>>>> the USB SND USB class driver, while q6usb is to ASoC.  Since the ASoC
>>>
>>> Humm, that is far from clear. I don't get how a something that interacts
>>> with the USB class driver can also be in charge of the audio DSP memory
>>> management.
>>>
>>
>> This is because the USB class driver is the entity which is going to
>> work with the USB HCD (XHCI) in this case to fetch the required
>> addresses, and map that into memory accessible by the audio DSP.  It
>> would be odd to be doing that from the q6usb end, which is part of the
>> ASoC layer.
>>
>>>> framework doesn't have any communication with USB SND, the ASoC DPCM USB
>>>> backend (q6usb) will have to be the entity that maintains what is going
>>>> on in USB SND.  That way, sessions initiated through the ASoC managed
>>>> sound card can evaluate what is available based on information reported
>>>> by q6usb.
>>>>
>>>> qc_audio_offload and q6usb will have some interaction between each
>>>> other.  The majority of communication between qc_audio_offload and q6usb
>>>> is reporting the device connection events.
>>>
>>> It's already complicated to figure out how the DSP and USB class driver
>>> might interact and probe/timing dependencies, but with two additional
>>> drivers in the mix it's really hard to understand.
>>>
>>
>> I did test some cases based on existence of both these drivers
>> (qc_audio_offload and q6usb).  If either one doesn't exist in the
>> system, then the offload path would not work.  I did improve some of
>> these potential sequences in the latest revision, such as patch#28. This
>> would address scenarios where the q6usb ASoC DPCM backend wasn't probed,
>> while the USB SND (and qc_audio_offload) were still detecting device
>> connections.
>>
>> Once the Q6USB driver is probed, then the offload snd kcontrols would be
>> created, and devices would be properly identified with the rediscover api.
>>
>>> Maybe ascii-art would help describe the concepts and types of
>>> information exchanged. Maintaining a consistent state across multiple
>>> drivers is not an easy task.
>>>
>>
>> Hopefully this might help?  I know its a lot to read through.
> 
> It's very helpful! Thanks for spending the time to illustrate the
> different building blocks.
> 
>>
>>       USB                          |            ASoC
>> --------------------------------------------------------------------
>>                                    |  _________________________
>>                                    | |sm8250 platform card     |
>>                                    | |_________________________|
>>                                    |         |           |
>>                                    |      ___V____   ____V____
>>                                    |     |Q6USB   | |Q6AFE    |  #5
>>                                    |     |"codec" | |"cpu"    |
>>                                    |     |________| |_________|
>>                                    |         ^
>>                                    |         |  #6
>>                                    |      ___V____
>>                                    |     |SOC-USB |
>>    ________   #1  ________         #7    |        |
>>   |USB SND |<--->|QC offld|<------------>|________|
>>   |(card.c)|     |        |<----------       ^
>>   |________|     |________|___ #4  | |       |
>>       ^               ^       |    | |    ___V__________________
>>       | #2            |  #2   |    | |   |APR/GLINK             |
>>    __ V_______________V_____  |    | |   |______________________|
>>   |USB SND (endpoint.c)     | |    | |              ^
>>   |_________________________| |    | | #8           |
>>               ^               |    | |   ___________V___________
>>               | #3            |    | |->|audio DSP              |
>>    ___________V_____________  |    |    |_______________________|
>>   |XHCI HCD                 |<-    |
>>   |_________________________|      |
>>
>>
>> #1 - USB SND and QC offload:
>> Initialization:
>> - Register platform operations, to receive connect/disconnect events
>>    from USB SND.
>> - QC offload creates a QMI handle, in order to receive QMI requests
>>    from the audio DSP.
>>
>> Runtime:
>> - USB SND passes along "struct snd_usb_audio" in order for QC offload
>>    to reference USB UAC desc parsing/USB SND helper APIs.
>> - USB device disconnection events will result in clearing of the chip
>>    entry.
>>
>> #2 - USB SND and QC offload endpoints:
>> Runtime:
>> - In the non-offloaded path, USB snd will utilize functions exposed by
>>    USB SND endpoint, to help with fetching USB EP references and queuing
>>    URBs.
>> - In the offload path, qc offload will utilize the functions to fetch
>>    USB EP references, so that it can use that information to query the
>>    XHCI HCD.
>> - Likewise, both will clean up endpoints when audio stream is not in use.
>>
>> #3 - XHCI HCD:
>> Initialization:
>> - During XHCI probe timing, when the USB HCD is added to the system, it
>>    will also initialize the secondary event rings.
>>
>> Runtime:
>> - During USB device plug ins/outs, allocates device slot, assigns eps,
>>    and initializes transfer rings.
>>
>> #4 - QC offload and XHCI:
>> Runtime:
>> - QC offload needs to reference the transfer ring and secondary event ring
>>    addresses by executing XHCI offload management APIs.
>> - This happens when audio DSP receives a USB QMI stream request.
>>
>> #5 - ASoC components:
>> Initialization:
>> - The SM8250 platform sound card driver fetches DT node entries defining
>>    the ASoC links. This chain/link has the components involved for a
>>    particular Q6AFE path. (not only USB offload)
>>      - "cpu" - this is the ASoC CPU DAI that handles interaction with the
>>                Q6 DSP's audio protocol. (AFE ports)
>>      - "codec" - the ASoC codec (backend) DAI defined
>> - Registers ASoC platform sound card based on links defined in the DT node.
>>    - Probes DAI components involved, ie Q6USB and Q6AFE
>>
>> Runtime:
>> - Q6AFE has the bulk of the interaction w/ the audio DSP to start an audio
>>    session, such as issuing AFE port start commands (part of the protocol
>>    used to communicate the audio session info)
>> - Q6USB will be there to now check for if format requested is supported by
>>    the device, and maintain offloading status.
>>
>> #6 - Q6USB and SOC-USB:
>> Initialization:
>> - Q6USB will query QC offload for USB device connection states. (through
>>    soc-usb)
>> - Creates a SOC USB entry, that carries information about resources,
>>    such as audio DSP memory information and requested XHCI event ring
>>    index.
>>
>> Runtime:
>> - SOC-USB will receive connect/disconnect events and propagate to Q6USB.
>>    - Q6USB makes devices available for offloading based on these events.
>> - Sets Q6AFE port configurations to select the USB SND card# and PCM#.
>>
>> #7 - SOC-USB and QC offload:
>> Initialization:
>> - Rediscover USB SND devices when the SOC-USB entry is created (if needed)
>>      - For situations where the Q6USB DAI hasn't been probed.
>>
>> Runtime:
>> - Propagate connect/disconnect events.
> 
> Is the SOC-USB module or building blocks intended to be generic or
> Qualcomm agnostic?
> 

This should be generic.

> It's not clear to me how it would handle "audio DSP memory information
> and requested XHCI event ring index."
> 

Each soc-usb entry that is created by the ASoC DPCM backend DAI (q6usb) 
will be able to hold "private data" that, in QC case, is defined as:
struct q6usb_offload

This is passed within the snd_soc_usb_add_port() call:
snd_soc_usb_add_port(component->dev, &data->priv, q6usb_alsa_connection_cb);

So depending on the user, the private data can contain their own struct 
with the information they require.

> In addition, it seems to be the "bridge" or means of communication
> between qc_audio_offload and q6usb, is this not based on custom events
> or triggers?
> 

Ideally, no, it shouldn't be based on custom events.  Intention for the 
connect_cb() that is defined is just to receive USB device discovery 
events from USB SND.  From the qc_audio_offload, we call 
snd_soc_usb_connect() within our platform op that we register to USB SND.

//Platform connect_cb() - called from USB SND probe (device connected)
static void qc_usb_audio_offload_probe(struct snd_usb_audio *chip)
{
...
snd_soc_usb_connect(usb_get_usb_backend(udev), chip->card->number,
				chip->index, chip->pcm_devs);

In the QC situation, we used this to build a list of active devices 
connected.

> Along the same lines, this SOC-USB entity interfaces with APR/GLINK
> which doesn't speak to me so it must be a QCOM interface?
> 

Sorry for not labeling those in the diagram, but yes, those are QC 
specific interfaces.  You can just think of it as a type of IPC transport.

> I am trying to see if this design could be used for other architectures,
> and the QCOM-specific and generic parts are not obvious.
> 
>> #8 - audio DSP and QC offload:
>> Runtime:
>> - Handle QMI requests coming from audio DSP.  These requests come AFTER
>>    the Q6AFE port is opened by the Q6AFE DAI(#6)
>> - Returns memory information about resources allocated by XHCI.
>> - Enables audio playback when this QMI transaction is completed.
>>
>>>>
>>>>>> 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...
>>>>>
>>>>> I already voiced my concerns about exposing two cards, each with their
>>>>> own set of volume controls with the same device. It would be much
>>>>> better
>>>>> to have an additional offloaded PCM device for card0...
>>>>>
>>>>> But if the consensus is to have two cards, it's still not clear how the
>>>>> routing would be selected. In the case where there are two USB audio
>>>>> devices attached, the offloaded path would only support one of the two.
>>>>> How would userspace know which of the two is selected?
>>>>>
>>>>
>>>> With patch#24:
>>>> https://lore.kernel.org/linux-usb/20230308235751.495-25-quic_wcheng@quicinc.com/T/#u
>>>>
>>>> Now, userspace can at least choose which device it wants to offload.
>>>> Part of doing that would mean userspace knows what USB SND card devices
>>>> are available, so it is aware of which devices are shared (between the
>>>> offload and USB SND path)
>>>>
>>>>> And how would userspace know the difference anyways between two
>>>>> physical
>>>>> devices attached to the platform with no offload, and one physical
>>>>> device with one additional offload path? The names you selected
>>>>> can't be
>>>>> used to identify that card1 is the optimized version of card0.
>>>>>
>>>>
>>>> Is userspace currently able to differentiate between cards that are
>>>> created by USB SND versus ASoC?  How complex can the userspace card
>>>> discovery be?  Can it query kcontrols at this point in time?  If so,
>>>> maybe we can change the names of the newly added ones to reflect that it
>>>> is an offload device?
>>>>
>>>> SND kcontrol names are currently:
>>>> Q6USB offload status
>>>> Q6USB offload SND device select
>>>
>>> I must admit I've never seen kcontrols being used to identify what the
>>> card is, and in this case it's a pretend-card that's just an improved
>>> version of another. It might be easier to use something else, such as
>>> the component strings.
>>
>> Its not exactly a pretend card, right?  This is part of the overall
>> platform sound card we have in the system.  At the moment, I'm only
>> testing by adding the USB audio routing, but there can be several ASoC
>> links defined in the overall platform card.
> 
> Sorry, I misunderstood the proposal. I thought there would be one card
> for "generic USB Audio", and another one for "DSP-offloaded USB Audio".
> I assumed, probably mistakenly, that all local audio endpoints
> (speaker,mics) would be exposed as a separate card.
> 

Ah got it.  No, that isn't the case here.

> It looks like it's more "generic USB Audio" and "DSP Audio", with the
> USB offload being exposed as a PCM device of the latter.
> 
> Did I get this right? In this case, presumably there can be some sort of

Yep that's correct!

> UCM file for the "DSP Audio card" that contains the configuration or
> knows which kcontrols to look for. But my point about detection hold.
> You could perfectly well have a 'Jack control' that tells userspace when
> a device is connected. That way there's no guess work, it's similar to
> HDMI for Intel: the device is exposed but only valid when the jack
> control is set.
> 

Hmm, ok.  Let me see if I can switch up some things.  Maybe replace the 
current snd_soc_dapm_enable_pin() calls in the q6usb connection_cb and 
replace that with a snd jack report. (the snd jack implementation 
already takes care of updating the pin if needed)

Thanks
Wesley Cheng

>> The Q6AFE CPU DAI has multiple audio AFE "ports" they can handle.  USB
>> is only one of those.
>>
>>>>
>>>>> Before we review low-level kernel plumbing, it would be good to give a
>>>>> better overview of how userspace applications are supposed to interact
>>>>> with the cards and identify the offloaded path. Testing with
>>>>> tinyplay/tinymix is fine, but that's a developer-level or CI unit test.
>>>>> we've got to see the broader picture of how a sound server would use
>>>>> this USB offload capability.
>>>>
>>>> Sure, I think that is fine.  I was hoping that at least adding some of
>>>> the new kcontrols would help userspace make use of this path in general,
>>>> but we can add more information if required.
>>>
>>> Can I ask if this solution has been used with a complete userspace stack
>>> already? I could see how this might be used with a relatively fixed
>>
>> Its been used only with the Android HAL.
> 
> ok, that aligns with what I was thinking.
> 
>>
>>> Android HAL, where the platform and routing are relatively controlled. I
>>> don't see how a more generic audio server would deal with the discovery
>>> and routing.
>>>
>>
>> This is why your input is helpful, since it provides another use case
>> that wasn't considered.  I think in our previous discussions the tagging
>> possibility was a good idea, and was hoping that it could help.  Could
>> tag all USB SND cards to the platform sound card as well, and if the
>> power saving path is chosen, it would issue the playback on the platform
>> sound card. (if not in use)
>>
>> In this case, the offload path wouldn't be the default routing, and only
>> enabled for power optimized path.
>>
>> Thanks
>> Wesley Cheng
  

<snip>

>>
>>>
>>>       USB                          |            ASoC
>>> --------------------------------------------------------------------
>>>                                    |  _________________________
>>>                                    | |sm8250 platform card     |
>>>                                    | |_________________________|
>>>                                    |         |           |
>>>                                    |      ___V____   ____V____
>>>                                    |     |Q6USB   | |Q6AFE    |  #5
>>>                                    |     |"codec" | |"cpu"    |
>>>                                    |     |________| |_________|
>>>                                    |         ^
>>>                                    |         |  #6
>>>                                    |      ___V____
>>>                                    |     |SOC-USB |
>>>    ________   #1  ________         #7    |        |
>>>   |USB SND |<--->|QC offld|<------------>|________|
>>>   |(card.c)|     |        |<----------       ^
>>>   |________|     |________|___ #4  | |       |
>>>       ^               ^       |    | |    ___V__________________
>>>       | #2            |  #2   |    | |   |APR/GLINK             |
>>>    __ V_______________V_____  |    | |   |______________________|
>>>   |USB SND (endpoint.c)     | |    | |              ^
>>>   |_________________________| |    | | #8           |
>>>               ^               |    | |   ___________V___________
>>>               | #3            |    | |->|audio DSP              |
>>>    ___________V_____________  |    |    |_______________________|
>>>   |XHCI HCD                 |<-    |
>>>   |_________________________|      |
>>>
>>>
>>> #1 - USB SND and QC offload:
>>> Initialization:
>>> - Register platform operations, to receive connect/disconnect events
>>>    from USB SND.
>>> - QC offload creates a QMI handle, in order to receive QMI requests
>>>    from the audio DSP.
>>>
>>> Runtime:
>>> - USB SND passes along "struct snd_usb_audio" in order for QC offload
>>>    to reference USB UAC desc parsing/USB SND helper APIs.
>>> - USB device disconnection events will result in clearing of the chip
>>>    entry.
>>>
>>> #2 - USB SND and QC offload endpoints:
>>> Runtime:
>>> - In the non-offloaded path, USB snd will utilize functions exposed by
>>>    USB SND endpoint, to help with fetching USB EP references and queuing
>>>    URBs.
>>> - In the offload path, qc offload will utilize the functions to fetch
>>>    USB EP references, so that it can use that information to query the
>>>    XHCI HCD.
>>> - Likewise, both will clean up endpoints when audio stream is not in
>>> use.
>>>
>>> #3 - XHCI HCD:
>>> Initialization:
>>> - During XHCI probe timing, when the USB HCD is added to the system, it
>>>    will also initialize the secondary event rings.
>>>
>>> Runtime:
>>> - During USB device plug ins/outs, allocates device slot, assigns eps,
>>>    and initializes transfer rings.
>>>
>>> #4 - QC offload and XHCI:
>>> Runtime:
>>> - QC offload needs to reference the transfer ring and secondary event
>>> ring
>>>    addresses by executing XHCI offload management APIs.
>>> - This happens when audio DSP receives a USB QMI stream request.
>>>
>>> #5 - ASoC components:
>>> Initialization:
>>> - The SM8250 platform sound card driver fetches DT node entries defining
>>>    the ASoC links. This chain/link has the components involved for a
>>>    particular Q6AFE path. (not only USB offload)
>>>      - "cpu" - this is the ASoC CPU DAI that handles interaction with
>>> the
>>>                Q6 DSP's audio protocol. (AFE ports)
>>>      - "codec" - the ASoC codec (backend) DAI defined
>>> - Registers ASoC platform sound card based on links defined in the DT
>>> node.
>>>    - Probes DAI components involved, ie Q6USB and Q6AFE
>>>
>>> Runtime:
>>> - Q6AFE has the bulk of the interaction w/ the audio DSP to start an
>>> audio
>>>    session, such as issuing AFE port start commands (part of the
>>> protocol
>>>    used to communicate the audio session info)
>>> - Q6USB will be there to now check for if format requested is
>>> supported by
>>>    the device, and maintain offloading status.
>>>
>>> #6 - Q6USB and SOC-USB:
>>> Initialization:
>>> - Q6USB will query QC offload for USB device connection states. (through
>>>    soc-usb)
>>> - Creates a SOC USB entry, that carries information about resources,
>>>    such as audio DSP memory information and requested XHCI event ring
>>>    index.
>>>
>>> Runtime:
>>> - SOC-USB will receive connect/disconnect events and propagate to Q6USB.
>>>    - Q6USB makes devices available for offloading based on these events.
>>> - Sets Q6AFE port configurations to select the USB SND card# and PCM#.
>>>
>>> #7 - SOC-USB and QC offload:
>>> Initialization:
>>> - Rediscover USB SND devices when the SOC-USB entry is created (if
>>> needed)
>>>      - For situations where the Q6USB DAI hasn't been probed.
>>>
>>> Runtime:
>>> - Propagate connect/disconnect events.
>>
>> Is the SOC-USB module or building blocks intended to be generic or
>> Qualcomm agnostic?
>>
> 
> This should be generic.

ok, but then how would it communicate with APR/GLINK described below [1]
> 
>> It's not clear to me how it would handle "audio DSP memory information
>> and requested XHCI event ring index."
>>
> 
> Each soc-usb entry that is created by the ASoC DPCM backend DAI (q6usb)
> will be able to hold "private data" that, in QC case, is defined as:
> struct q6usb_offload
> 
> This is passed within the snd_soc_usb_add_port() call:
> snd_soc_usb_add_port(component->dev, &data->priv,
> q6usb_alsa_connection_cb);
> 
> So depending on the user, the private data can contain their own struct
> with the information they require.

ok, so "handle private data such as audio DSP memory information
>> and requested XHCI event ring index" is what you meant. That'd fine.

>> In addition, it seems to be the "bridge" or means of communication
>> between qc_audio_offload and q6usb, is this not based on custom events
>> or triggers?
>>
> 
> Ideally, no, it shouldn't be based on custom events.  Intention for the
> connect_cb() that is defined is just to receive USB device discovery
> events from USB SND.  From the qc_audio_offload, we call
> snd_soc_usb_connect() within our platform op that we register to USB SND.
> 
> //Platform connect_cb() - called from USB SND probe (device connected)
> static void qc_usb_audio_offload_probe(struct snd_usb_audio *chip)
> {
> ...
> snd_soc_usb_connect(usb_get_usb_backend(udev), chip->card->number,
>                 chip->index, chip->pcm_devs);
> 
> In the QC situation, we used this to build a list of active devices
> connected.
> 
>> Along the same lines, this SOC-USB entity interfaces with APR/GLINK
>> which doesn't speak to me so it must be a QCOM interface?>>
> 
> Sorry for not labeling those in the diagram, but yes, those are QC
> specific interfaces.  You can just think of it as a type of IPC transport.

[1] ... something's not clear on how a generic 'soc-usb' component can
directly talk to a vendor-specific IPC.

Is there a missing layer?

>> I am trying to see if this design could be used for other architectures,
>> and the QCOM-specific and generic parts are not obvious.
>>
>>> #8 - audio DSP and QC offload:
>>> Runtime:
>>> - Handle QMI requests coming from audio DSP.  These requests come AFTER
>>>    the Q6AFE port is opened by the Q6AFE DAI(#6)
>>> - Returns memory information about resources allocated by XHCI.
>>> - Enables audio playback when this QMI transaction is completed.
>>>
>>>>>
>>>>>>> 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...
>>>>>>
>>>>>> I already voiced my concerns about exposing two cards, each with
>>>>>> their
>>>>>> own set of volume controls with the same device. It would be much
>>>>>> better
>>>>>> to have an additional offloaded PCM device for card0...
>>>>>>
>>>>>> But if the consensus is to have two cards, it's still not clear
>>>>>> how the
>>>>>> routing would be selected. In the case where there are two USB audio
>>>>>> devices attached, the offloaded path would only support one of the
>>>>>> two.
>>>>>> How would userspace know which of the two is selected?
>>>>>>
>>>>>
>>>>> With patch#24:
>>>>> https://lore.kernel.org/linux-usb/20230308235751.495-25-quic_wcheng@quicinc.com/T/#u
>>>>>
>>>>> Now, userspace can at least choose which device it wants to offload.
>>>>> Part of doing that would mean userspace knows what USB SND card
>>>>> devices
>>>>> are available, so it is aware of which devices are shared (between the
>>>>> offload and USB SND path)
>>>>>
>>>>>> And how would userspace know the difference anyways between two
>>>>>> physical
>>>>>> devices attached to the platform with no offload, and one physical
>>>>>> device with one additional offload path? The names you selected
>>>>>> can't be
>>>>>> used to identify that card1 is the optimized version of card0.
>>>>>>
>>>>>
>>>>> Is userspace currently able to differentiate between cards that are
>>>>> created by USB SND versus ASoC?  How complex can the userspace card
>>>>> discovery be?  Can it query kcontrols at this point in time?  If so,
>>>>> maybe we can change the names of the newly added ones to reflect
>>>>> that it
>>>>> is an offload device?
>>>>>
>>>>> SND kcontrol names are currently:
>>>>> Q6USB offload status
>>>>> Q6USB offload SND device select
>>>>
>>>> I must admit I've never seen kcontrols being used to identify what the
>>>> card is, and in this case it's a pretend-card that's just an improved
>>>> version of another. It might be easier to use something else, such as
>>>> the component strings.
>>>
>>> Its not exactly a pretend card, right?  This is part of the overall
>>> platform sound card we have in the system.  At the moment, I'm only
>>> testing by adding the USB audio routing, but there can be several ASoC
>>> links defined in the overall platform card.
>>
>> Sorry, I misunderstood the proposal. I thought there would be one card
>> for "generic USB Audio", and another one for "DSP-offloaded USB Audio".
>> I assumed, probably mistakenly, that all local audio endpoints
>> (speaker,mics) would be exposed as a separate card.
>>
> 
> Ah got it.  No, that isn't the case here.
> 
>> It looks like it's more "generic USB Audio" and "DSP Audio", with the
>> USB offload being exposed as a PCM device of the latter.
>>
>> Did I get this right? In this case, presumably there can be some sort of
> 
> Yep that's correct!

ok, that's good.

My initial thought was to add a 'DSP offload' PCM to the USB card, you
added a "USB offload" PCM to the DSP card. Nice logical swap!

Your proposal might be easier in practice since there's typically a
vendor-specific configuration file (UCM or custom) file for the DSP,
where USB information can be added.

It's more problematic to change a generic USB card as we know it today
and bolt vendor-specific DSP information on top.

The only open I have with your option is that there are still two
control paths to e.g. set the volume. It would be so much easier for
userspace if there was a single volume control no matter what path is
used for data, or make sure the kcontrols are 'mirrored' somehow. If we
found a way to address this issue that would be ideal.

>> UCM file for the "DSP Audio card" that contains the configuration or
>> knows which kcontrols to look for. But my point about detection hold.
>> You could perfectly well have a 'Jack control' that tells userspace when
>> a device is connected. That way there's no guess work, it's similar to
>> HDMI for Intel: the device is exposed but only valid when the jack
>> control is set.
>>
> 
> Hmm, ok.  Let me see if I can switch up some things.  Maybe replace the
> current snd_soc_dapm_enable_pin() calls in the q6usb connection_cb and
> replace that with a snd jack report. (the snd jack implementation
> already takes care of updating the pin if needed)

The jack is useful to let userspace know if a PCM device, i.e. a
Front-End, can be used. But if you expose a PCM device, nothing prevents
an application from trying to open and use it, we recently had such an
issue due to a change in PipeWire that tried to open a non-functional
HDMI device. So you do need something to bail if the PCM device is
mistakenly used.

DAPM pin management seems different, it will turn-on/off parts of the
graph connected to an endpoint. Userpace will typically not know
anything about pin management, it's an in-kernel concept.

Not sure if you have to choose, those are two different layers, no?
  

Hi Pierre,

On 3/13/2023 7:22 PM, Pierre-Louis Bossart wrote:
> 
> <snip>
> 
>>>
>>>>
>>>>        USB                          |            ASoC
>>>> --------------------------------------------------------------------
>>>>                                     |  _________________________
>>>>                                     | |sm8250 platform card     |
>>>>                                     | |_________________________|
>>>>                                     |         |           |
>>>>                                     |      ___V____   ____V____
>>>>                                     |     |Q6USB   | |Q6AFE    |  #5
>>>>                                     |     |"codec" | |"cpu"    |
>>>>                                     |     |________| |_________|
>>>>                                     |         ^
>>>>                                     |         |  #6
>>>>                                     |      ___V____
>>>>                                     |     |SOC-USB |
>>>>     ________   #1  ________         #7    |        |
>>>>    |USB SND |<--->|QC offld|<------------>|________|
>>>>    |(card.c)|     |        |<----------       ^
>>>>    |________|     |________|___ #4  | |       |
>>>>        ^               ^       |    | |    ___V__________________
>>>>        | #2            |  #2   |    | |   |APR/GLINK             |
>>>>     __ V_______________V_____  |    | |   |______________________|
>>>>    |USB SND (endpoint.c)     | |    | |              ^
>>>>    |_________________________| |    | | #8           |
>>>>                ^               |    | |   ___________V___________
>>>>                | #3            |    | |->|audio DSP              |
>>>>     ___________V_____________  |    |    |_______________________|
>>>>    |XHCI HCD                 |<-    |
>>>>    |_________________________|      |
>>>>
>>>>
>>>> #1 - USB SND and QC offload:
>>>> Initialization:
>>>> - Register platform operations, to receive connect/disconnect events
>>>>     from USB SND.
>>>> - QC offload creates a QMI handle, in order to receive QMI requests
>>>>     from the audio DSP.
>>>>
>>>> Runtime:
>>>> - USB SND passes along "struct snd_usb_audio" in order for QC offload
>>>>     to reference USB UAC desc parsing/USB SND helper APIs.
>>>> - USB device disconnection events will result in clearing of the chip
>>>>     entry.
>>>>
>>>> #2 - USB SND and QC offload endpoints:
>>>> Runtime:
>>>> - In the non-offloaded path, USB snd will utilize functions exposed by
>>>>     USB SND endpoint, to help with fetching USB EP references and queuing
>>>>     URBs.
>>>> - In the offload path, qc offload will utilize the functions to fetch
>>>>     USB EP references, so that it can use that information to query the
>>>>     XHCI HCD.
>>>> - Likewise, both will clean up endpoints when audio stream is not in
>>>> use.
>>>>
>>>> #3 - XHCI HCD:
>>>> Initialization:
>>>> - During XHCI probe timing, when the USB HCD is added to the system, it
>>>>     will also initialize the secondary event rings.
>>>>
>>>> Runtime:
>>>> - During USB device plug ins/outs, allocates device slot, assigns eps,
>>>>     and initializes transfer rings.
>>>>
>>>> #4 - QC offload and XHCI:
>>>> Runtime:
>>>> - QC offload needs to reference the transfer ring and secondary event
>>>> ring
>>>>     addresses by executing XHCI offload management APIs.
>>>> - This happens when audio DSP receives a USB QMI stream request.
>>>>
>>>> #5 - ASoC components:
>>>> Initialization:
>>>> - The SM8250 platform sound card driver fetches DT node entries defining
>>>>     the ASoC links. This chain/link has the components involved for a
>>>>     particular Q6AFE path. (not only USB offload)
>>>>       - "cpu" - this is the ASoC CPU DAI that handles interaction with
>>>> the
>>>>                 Q6 DSP's audio protocol. (AFE ports)
>>>>       - "codec" - the ASoC codec (backend) DAI defined
>>>> - Registers ASoC platform sound card based on links defined in the DT
>>>> node.
>>>>     - Probes DAI components involved, ie Q6USB and Q6AFE
>>>>
>>>> Runtime:
>>>> - Q6AFE has the bulk of the interaction w/ the audio DSP to start an
>>>> audio
>>>>     session, such as issuing AFE port start commands (part of the
>>>> protocol
>>>>     used to communicate the audio session info)
>>>> - Q6USB will be there to now check for if format requested is
>>>> supported by
>>>>     the device, and maintain offloading status.
>>>>
>>>> #6 - Q6USB and SOC-USB:
>>>> Initialization:
>>>> - Q6USB will query QC offload for USB device connection states. (through
>>>>     soc-usb)
>>>> - Creates a SOC USB entry, that carries information about resources,
>>>>     such as audio DSP memory information and requested XHCI event ring
>>>>     index.
>>>>
>>>> Runtime:
>>>> - SOC-USB will receive connect/disconnect events and propagate to Q6USB.
>>>>     - Q6USB makes devices available for offloading based on these events.
>>>> - Sets Q6AFE port configurations to select the USB SND card# and PCM#.
>>>>
>>>> #7 - SOC-USB and QC offload:
>>>> Initialization:
>>>> - Rediscover USB SND devices when the SOC-USB entry is created (if
>>>> needed)
>>>>       - For situations where the Q6USB DAI hasn't been probed.
>>>>
>>>> Runtime:
>>>> - Propagate connect/disconnect events.
>>>
>>> Is the SOC-USB module or building blocks intended to be generic or
>>> Qualcomm agnostic?
>>>
>>
>> This should be generic.
> 
> ok, but then how would it communicate with APR/GLINK described below [1]

To make the diagram a bit more compact, I left out our Q6ASM DAI, which 
is the path that handles the PCM data/buffers. (not really involved in 
initializing any part of the offload path)

Sorry made a mistake on the diagram.  There is no connection from 
SOC-USB to the APR/GLINK.  The Q6USB driver will be the one that is 
going to configure some of the Q6AFE ports along withe the Q6AFE DAI driver.

|            ASoC
----------------------------------
|  _________________________
| |sm8250 platform card     |
| |_________________________|
|         |           |
|      ___V____   ____V____
|     |Q6USB   | |Q6AFE    |  #5
|     |"codec" | |"cpu"    |
|     |________| |_________|
|         ^  ^        ^
|      #6 |  |________|
|      ___V____     |
|     |SOC-USB |    |
#7    |        |    |
----->|________|    |
---                 |
| |                 |
| |    _____________V________
| |   |APR/GLINK             |
| |   |______________________|
| |              ^
| | #8           |
| |   ___________V___________
| |->|audio DSP              |
|    |_______________________|
|
|

>>
>>> It's not clear to me how it would handle "audio DSP memory information
>>> and requested XHCI event ring index."
>>>
>>
>> Each soc-usb entry that is created by the ASoC DPCM backend DAI (q6usb)
>> will be able to hold "private data" that, in QC case, is defined as:
>> struct q6usb_offload
>>
>> This is passed within the snd_soc_usb_add_port() call:
>> snd_soc_usb_add_port(component->dev, &data->priv,
>> q6usb_alsa_connection_cb);
>>
>> So depending on the user, the private data can contain their own struct
>> with the information they require.
> 
> ok, so "handle private data such as audio DSP memory information
>>> and requested XHCI event ring index" is what you meant. That'd fine.
> 
>>> In addition, it seems to be the "bridge" or means of communication
>>> between qc_audio_offload and q6usb, is this not based on custom events
>>> or triggers?
>>>
>>
>> Ideally, no, it shouldn't be based on custom events.  Intention for the
>> connect_cb() that is defined is just to receive USB device discovery
>> events from USB SND.  From the qc_audio_offload, we call
>> snd_soc_usb_connect() within our platform op that we register to USB SND.
>>
>> //Platform connect_cb() - called from USB SND probe (device connected)
>> static void qc_usb_audio_offload_probe(struct snd_usb_audio *chip)
>> {
>> ...
>> snd_soc_usb_connect(usb_get_usb_backend(udev), chip->card->number,
>>                  chip->index, chip->pcm_devs);
>>
>> In the QC situation, we used this to build a list of active devices
>> connected.
>>
>>> Along the same lines, this SOC-USB entity interfaces with APR/GLINK
>>> which doesn't speak to me so it must be a QCOM interface?>>
>>
>> Sorry for not labeling those in the diagram, but yes, those are QC
>> specific interfaces.  You can just think of it as a type of IPC transport.
> 
> [1] ... something's not clear on how a generic 'soc-usb' component can
> directly talk to a vendor-specific IPC.
> 
> Is there a missing layer?
> 

:) hopefully the updated diagram clarifies this.

>>> I am trying to see if this design could be used for other architectures,
>>> and the QCOM-specific and generic parts are not obvious.
>>>
>>>> #8 - audio DSP and QC offload:
>>>> Runtime:
>>>> - Handle QMI requests coming from audio DSP.  These requests come AFTER
>>>>     the Q6AFE port is opened by the Q6AFE DAI(#6)
>>>> - Returns memory information about resources allocated by XHCI.
>>>> - Enables audio playback when this QMI transaction is completed.
>>>>
>>>>>>
>>>>>>>> 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...
>>>>>>>
>>>>>>> I already voiced my concerns about exposing two cards, each with
>>>>>>> their
>>>>>>> own set of volume controls with the same device. It would be much
>>>>>>> better
>>>>>>> to have an additional offloaded PCM device for card0...
>>>>>>>
>>>>>>> But if the consensus is to have two cards, it's still not clear
>>>>>>> how the
>>>>>>> routing would be selected. In the case where there are two USB audio
>>>>>>> devices attached, the offloaded path would only support one of the
>>>>>>> two.
>>>>>>> How would userspace know which of the two is selected?
>>>>>>>
>>>>>>
>>>>>> With patch#24:
>>>>>> https://lore.kernel.org/linux-usb/20230308235751.495-25-quic_wcheng@quicinc.com/T/#u
>>>>>>
>>>>>> Now, userspace can at least choose which device it wants to offload.
>>>>>> Part of doing that would mean userspace knows what USB SND card
>>>>>> devices
>>>>>> are available, so it is aware of which devices are shared (between the
>>>>>> offload and USB SND path)
>>>>>>
>>>>>>> And how would userspace know the difference anyways between two
>>>>>>> physical
>>>>>>> devices attached to the platform with no offload, and one physical
>>>>>>> device with one additional offload path? The names you selected
>>>>>>> can't be
>>>>>>> used to identify that card1 is the optimized version of card0.
>>>>>>>
>>>>>>
>>>>>> Is userspace currently able to differentiate between cards that are
>>>>>> created by USB SND versus ASoC?  How complex can the userspace card
>>>>>> discovery be?  Can it query kcontrols at this point in time?  If so,
>>>>>> maybe we can change the names of the newly added ones to reflect
>>>>>> that it
>>>>>> is an offload device?
>>>>>>
>>>>>> SND kcontrol names are currently:
>>>>>> Q6USB offload status
>>>>>> Q6USB offload SND device select
>>>>>
>>>>> I must admit I've never seen kcontrols being used to identify what the
>>>>> card is, and in this case it's a pretend-card that's just an improved
>>>>> version of another. It might be easier to use something else, such as
>>>>> the component strings.
>>>>
>>>> Its not exactly a pretend card, right?  This is part of the overall
>>>> platform sound card we have in the system.  At the moment, I'm only
>>>> testing by adding the USB audio routing, but there can be several ASoC
>>>> links defined in the overall platform card.
>>>
>>> Sorry, I misunderstood the proposal. I thought there would be one card
>>> for "generic USB Audio", and another one for "DSP-offloaded USB Audio".
>>> I assumed, probably mistakenly, that all local audio endpoints
>>> (speaker,mics) would be exposed as a separate card.
>>>
>>
>> Ah got it.  No, that isn't the case here.
>>
>>> It looks like it's more "generic USB Audio" and "DSP Audio", with the
>>> USB offload being exposed as a PCM device of the latter.
>>>
>>> Did I get this right? In this case, presumably there can be some sort of
>>
>> Yep that's correct!
> 
> ok, that's good.
> 
> My initial thought was to add a 'DSP offload' PCM to the USB card, you
> added a "USB offload" PCM to the DSP card. Nice logical swap!
> 
> Your proposal might be easier in practice since there's typically a
> vendor-specific configuration file (UCM or custom) file for the DSP,
> where USB information can be added.
> 
> It's more problematic to change a generic USB card as we know it today
> and bolt vendor-specific DSP information on top.
> 
> The only open I have with your option is that there are still two
> control paths to e.g. set the volume. It would be so much easier for
> userspace if there was a single volume control no matter what path is
> used for data, or make sure the kcontrols are 'mirrored' somehow. If we
> found a way to address this issue that would be ideal.
> 

Got it.  Let me look to see if that is something we can address/add.  I 
think the current implementation is that USB SND will expose some mixer 
controls based on the UAC descriptor parsing.  Then when they want to 
change the volume (for example) it will result in a USB SETUP transaction.

So USB SND will eventually be the entity controlling these changes.

>>> UCM file for the "DSP Audio card" that contains the configuration or
>>> knows which kcontrols to look for. But my point about detection hold.
>>> You could perfectly well have a 'Jack control' that tells userspace when
>>> a device is connected. That way there's no guess work, it's similar to
>>> HDMI for Intel: the device is exposed but only valid when the jack
>>> control is set.
>>>
>>
>> Hmm, ok.  Let me see if I can switch up some things.  Maybe replace the
>> current snd_soc_dapm_enable_pin() calls in the q6usb connection_cb and
>> replace that with a snd jack report. (the snd jack implementation
>> already takes care of updating the pin if needed)
> 
> The jack is useful to let userspace know if a PCM device, i.e. a
> Front-End, can be used. But if you expose a PCM device, nothing prevents
> an application from trying to open and use it, we recently had such an
> issue due to a change in PipeWire that tried to open a non-functional
> HDMI device. So you do need something to bail if the PCM device is
> mistakenly used.
> 
> DAPM pin management seems different, it will turn-on/off parts of the
> graph connected to an endpoint. Userpace will typically not know
> anything about pin management, it's an in-kernel concept.
> 
> Not sure if you have to choose, those are two different layers, no?

Will review this more and fix it in the next rev.  Thanks for the inputs!

Thanks
Wesley Cheng
  

Hi Wesley,

> Sorry made a mistake on the diagram.  There is no connection from
> SOC-USB to the APR/GLINK.  The Q6USB driver will be the one that is
> going to configure some of the Q6AFE ports along withe the Q6AFE DAI
> driver.
> 
> |            ASoC
> ----------------------------------
> |  _________________________
> | |sm8250 platform card     |
> | |_________________________|
> |         |           |
> |      ___V____   ____V____
> |     |Q6USB   | |Q6AFE    |  #5
> |     |"codec" | |"cpu"    |
> |     |________| |_________|
> |         ^  ^        ^
> |      #6 |  |________|
> |      ___V____     |
> |     |SOC-USB |    |
> #7    |        |    |
> ----->|________|    |
> ---                 |
> | |                 |
> | |    _____________V________
> | |   |APR/GLINK             |
> | |   |______________________|
> | |              ^
> | | #8           |
> | |   ___________V___________
> | |->|audio DSP              |
> |    |_______________________|
> |
> |
> 
>>>

Makes sense now, thank you for the clarification.

I'll have to dig more in this 'soc-usb' block, it's clearly a key
component that will have to maintain a consistent state across two
different parts of the stack and deal with probe/remove/shutdown.

>> My initial thought was to add a 'DSP offload' PCM to the USB card, you
>> added a "USB offload" PCM to the DSP card. Nice logical swap!
>>
>> Your proposal might be easier in practice since there's typically a
>> vendor-specific configuration file (UCM or custom) file for the DSP,
>> where USB information can be added.
>>
>> It's more problematic to change a generic USB card as we know it today
>> and bolt vendor-specific DSP information on top.
>>
>> The only open I have with your option is that there are still two
>> control paths to e.g. set the volume. It would be so much easier for
>> userspace if there was a single volume control no matter what path is
>> used for data, or make sure the kcontrols are 'mirrored' somehow. If we
>> found a way to address this issue that would be ideal.
>>
> 
> Got it.  Let me look to see if that is something we can address/add.  I
> think the current implementation is that USB SND will expose some mixer
> controls based on the UAC descriptor parsing.  Then when they want to
> change the volume (for example) it will result in a USB SETUP transaction.
> 
> So USB SND will eventually be the entity controlling these changes.

That's probably ok then, am I getting this right that the the DSP card
would not expose any USB-related kcontrols then, i.e. the ONLY path to
change volumes, etc.,  would through the regular USB card kcontrols?

That would limit the changes in the platform sound card to the addition
of a PCM USB device.
  

On Wed, Mar 15, 2023 at 09:30:58AM -0500, Pierre-Louis Bossart wrote:

> That's probably ok then, am I getting this right that the the DSP card
> would not expose any USB-related kcontrols then, i.e. the ONLY path to
> change volumes, etc.,  would through the regular USB card kcontrols?

> That would limit the changes in the platform sound card to the addition
> of a PCM USB device.

I'd guess that there might be some volume control in the DSP as part of
the generic routing to the port (eg, if all ports have some output
control) but I'm not sure that's an issue, could even be useful for
normalising the output of DSP algorithms compared to direct PCM
playback.
  

Hi Pierre,

On 3/15/2023 7:30 AM, Pierre-Louis Bossart wrote:
> Hi Wesley,
> 
>> Sorry made a mistake on the diagram.  There is no connection from
>> SOC-USB to the APR/GLINK.  The Q6USB driver will be the one that is
>> going to configure some of the Q6AFE ports along withe the Q6AFE DAI
>> driver.
>>
>> |            ASoC
>> ----------------------------------
>> |  _________________________
>> | |sm8250 platform card     |
>> | |_________________________|
>> |         |           |
>> |      ___V____   ____V____
>> |     |Q6USB   | |Q6AFE    |  #5
>> |     |"codec" | |"cpu"    |
>> |     |________| |_________|
>> |         ^  ^        ^
>> |      #6 |  |________|
>> |      ___V____     |
>> |     |SOC-USB |    |
>> #7    |        |    |
>> ----->|________|    |
>> ---                 |
>> | |                 |
>> | |    _____________V________
>> | |   |APR/GLINK             |
>> | |   |______________________|
>> | |              ^
>> | | #8           |
>> | |   ___________V___________
>> | |->|audio DSP              |
>> |    |_______________________|
>> |
>> |
>>
>>>>
> 
> Makes sense now, thank you for the clarification.
> 
> I'll have to dig more in this 'soc-usb' block, it's clearly a key
> component that will have to maintain a consistent state across two
> different parts of the stack and deal with probe/remove/shutdown.
> 
>>> My initial thought was to add a 'DSP offload' PCM to the USB card, you
>>> added a "USB offload" PCM to the DSP card. Nice logical swap!
>>>
>>> Your proposal might be easier in practice since there's typically a
>>> vendor-specific configuration file (UCM or custom) file for the DSP,
>>> where USB information can be added.
>>>
>>> It's more problematic to change a generic USB card as we know it today
>>> and bolt vendor-specific DSP information on top.
>>>
>>> The only open I have with your option is that there are still two
>>> control paths to e.g. set the volume. It would be so much easier for
>>> userspace if there was a single volume control no matter what path is
>>> used for data, or make sure the kcontrols are 'mirrored' somehow. If we
>>> found a way to address this issue that would be ideal.
>>>
>>
>> Got it.  Let me look to see if that is something we can address/add.  I
>> think the current implementation is that USB SND will expose some mixer
>> controls based on the UAC descriptor parsing.  Then when they want to
>> change the volume (for example) it will result in a USB SETUP transaction.
>>
>> So USB SND will eventually be the entity controlling these changes.
> 
> That's probably ok then, am I getting this right that the the DSP card
> would not expose any USB-related kcontrols then, i.e. the ONLY path to
> change volumes, etc.,  would through the regular USB card kcontrols?
> 
> That would limit the changes in the platform sound card to the addition
> of a PCM USB device.

Yes, that's correct.  There won't be any exposed USB volume controls 
from the DSP card.

Thanks
Wesley Cheng