mbox series

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

Message ID 20230308235751.495-1-quic_wcheng@quicinc.com
Headers show
Series Introduce QC USB SND audio offloading support | expand

Message

Wesley Cheng March 8, 2023, 11:57 p.m. UTC
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

Comments

Greg KH March 9, 2023, 6:38 a.m. UTC | #1
On Wed, Mar 08, 2023 at 03:57:25PM -0800, Wesley Cheng wrote:
> Some use cases, such as USB audio offloading, will allow for a DSP to take
> over issuing USB transfers to the host controller.  In order for the DSP to
> submit transfers for a particular endpoint, and to handle its events, the
> client driver will need to query for some parameters allocated by XHCI.
> 
> - XHCI secondary interrupter event ring address
> - XHCI transfer ring address (for a particular EP)
> - Stop endpoint command API
> 
> Once the resources are handed off to the DSP, the offload begins, and the
> main processor can enter idle.  When stopped, since there are no URBs
> submitted from the main processor, the client will just issue a stop
> endpoint command to halt any pending transfers.
> 
> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
> ---
>  drivers/usb/host/xhci.c       | 130 ++++++++++++++++++++++++++++++++++
>  include/linux/usb/xhci-intr.h |   8 +++
>  2 files changed, 138 insertions(+)

Please use checkpatch.pl on your patches before sending them out :(

Some other minor comments:

> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 88435b9cd66e..5c6b3d8f834c 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -1603,6 +1603,136 @@ static int xhci_check_args(struct usb_hcd *hcd, struct usb_device *udev,
>  	return 1;
>  }
>  
> +int xhci_stop_endpoint(struct usb_device *udev,
> +			struct usb_host_endpoint *ep)

That all can be on one line, right?

And no documentation for a global function?

> +{
> +	struct usb_hcd *hcd = bus_to_hcd(udev->bus);
> +	struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> +	unsigned int ep_index;
> +	struct xhci_virt_device *virt_dev;
> +	struct xhci_command *cmd;
> +	unsigned long flags;
> +	int ret = 0;
> +
> +	ret = xhci_check_args(hcd, udev, ep, 1, true, __func__);
> +	if (ret <= 0)
> +		return ret;
> +
> +	cmd = xhci_alloc_command(xhci, true, GFP_NOIO);
> +	if (!cmd)
> +		return -ENOMEM;
> +
> +	spin_lock_irqsave(&xhci->lock, flags);
> +	virt_dev = xhci->devs[udev->slot_id];
> +	if (!virt_dev) {
> +		ret = -ENODEV;
> +		goto err;
> +	}
> +
> +	ep_index = xhci_get_endpoint_index(&ep->desc);
> +	if (virt_dev->eps[ep_index].ring &&
> +			virt_dev->eps[ep_index].ring->dequeue) {
> +		ret = xhci_queue_stop_endpoint(xhci, cmd, udev->slot_id,
> +				ep_index, 0);
> +		if (ret)
> +			goto err;
> +
> +		xhci_ring_cmd_db(xhci);
> +		spin_unlock_irqrestore(&xhci->lock, flags);
> +
> +		/* Wait for stop endpoint command to finish */
> +		wait_for_completion(cmd->completion);
> +
> +		if (cmd->status == COMP_COMMAND_ABORTED ||
> +				cmd->status == COMP_STOPPED) {
> +			xhci_warn(xhci,
> +				"stop endpoint command timeout for ep%d%s\n",
> +				usb_endpoint_num(&ep->desc),
> +				usb_endpoint_dir_in(&ep->desc) ? "in" : "out");
> +			ret = -ETIME;
> +				}
> +		goto free_cmd;
> +	}
> +
> +err:
> +	spin_unlock_irqrestore(&xhci->lock, flags);
> +free_cmd:
> +	xhci_free_command(xhci, cmd);
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(xhci_stop_endpoint);
> +
> +/* Retrieve the transfer ring base address for a specific endpoint. */

At least some comment, but not much for a global function.

> +phys_addr_t xhci_get_xfer_resource(struct usb_device *udev,
> +					struct usb_host_endpoint *ep, dma_addr_t *dma)
> +{
> +	struct usb_hcd *hcd = bus_to_hcd(udev->bus);
> +	struct device *dev = hcd->self.sysdev;
> +	struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> +	struct sg_table sgt;
> +	phys_addr_t pa;
> +	int ret;
> +	unsigned int ep_index;
> +	struct xhci_virt_device *virt_dev;
> +	unsigned long flags;
> +
> +	if (!HCD_RH_RUNNING(hcd))
> +		return 0;

Isn't 0 a valid address?


> +
> +	ret = xhci_check_args(hcd, udev, ep, 1, true, __func__);
> +	if (ret <= 0) {
> +		xhci_err(xhci, "%s: invalid args\n", __func__);
> +		return 0;
> +	}
> +
> +	spin_lock_irqsave(&xhci->lock, flags);
> +
> +	virt_dev = xhci->devs[udev->slot_id];
> +	ep_index = xhci_get_endpoint_index(&ep->desc);
> +
> +	if (virt_dev->eps[ep_index].ring &&
> +		virt_dev->eps[ep_index].ring->first_seg) {
> +
> +		dma_get_sgtable(dev, &sgt,
> +			virt_dev->eps[ep_index].ring->first_seg->trbs,
> +			virt_dev->eps[ep_index].ring->first_seg->dma,
> +			TRB_SEGMENT_SIZE);
> +
> +		*dma = virt_dev->eps[ep_index].ring->first_seg->dma;
> +
> +		pa = page_to_phys(sg_page(sgt.sgl));
> +		sg_free_table(&sgt);
> +		spin_unlock_irqrestore(&xhci->lock, flags);
> +
> +		return pa;
> +	}
> +	spin_unlock_irqrestore(&xhci->lock, flags);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(xhci_get_xfer_resource);
> +
> +phys_addr_t xhci_get_ir_resource(struct usb_device *udev, struct xhci_interrupter *ir)

kerneldoc for global functions?

> +{
> +	struct usb_hcd *hcd = bus_to_hcd(udev->bus);
> +	struct device *dev = hcd->self.sysdev;
> +	struct sg_table sgt;
> +	phys_addr_t pa;
> +
> +	if (!ir)
> +		return 0;

How can ir ever be NULL?  You control the callers, just don't do that.

> +
> +	dma_get_sgtable(dev, &sgt, ir->event_ring->first_seg->trbs,
> +		ir->event_ring->first_seg->dma, TRB_SEGMENT_SIZE);
> +
> +	pa = page_to_phys(sg_page(sgt.sgl));
> +	sg_free_table(&sgt);
> +
> +	return pa;
> +}
> +EXPORT_SYMBOL_GPL(xhci_get_ir_resource);
> +
>  static int xhci_configure_endpoint(struct xhci_hcd *xhci,
>  		struct usb_device *udev, struct xhci_command *command,
>  		bool ctx_change, bool must_succeed);
> diff --git a/include/linux/usb/xhci-intr.h b/include/linux/usb/xhci-intr.h
> index 738b0f0481a6..d42cc9a1e698 100644
> --- a/include/linux/usb/xhci-intr.h
> +++ b/include/linux/usb/xhci-intr.h
> @@ -80,7 +80,15 @@ struct xhci_interrupter {
>  	u64	s3_erst_dequeue;
>  };
>  
> +/* Secondary interrupter */
>  struct xhci_interrupter *
>  xhci_create_secondary_interrupter(struct usb_hcd *hcd, int intr_num);
>  void xhci_remove_secondary_interrupter(struct usb_hcd *hcd, struct xhci_interrupter *ir);
> +
> +/* Offload */
> +int xhci_stop_endpoint(struct usb_device *udev,
> +			struct usb_host_endpoint *ep);
> +phys_addr_t xhci_get_xfer_resource(struct usb_device *udev,
> +					struct usb_host_endpoint *ep, dma_addr_t *dma);
> +phys_addr_t xhci_get_ir_resource(struct usb_device *udev, struct xhci_interrupter *ir);

Why are these functions unique to offload?

thanks,

greg k-h
Greg KH March 9, 2023, 6:44 a.m. UTC | #2
On Wed, Mar 08, 2023 at 03:57:32PM -0800, Wesley Cheng wrote:
> Allow for different platforms to be notified on USB SND connect/disconnect
> seqeunces.  This allows for platform USB SND modules to properly initialize
> and populate internal structures with references to the USB SND chip
> device.
> 
> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
> ---
>  sound/usb/card.c | 36 ++++++++++++++++++++++++++++++++++++
>  sound/usb/card.h | 20 ++++++++++++++++++++
>  2 files changed, 56 insertions(+)
> 
> diff --git a/sound/usb/card.c b/sound/usb/card.c
> index 26268ffb8274..9bcbaa0c0a55 100644
> --- a/sound/usb/card.c
> +++ b/sound/usb/card.c
> @@ -117,6 +117,30 @@ MODULE_PARM_DESC(skip_validation, "Skip unit descriptor validation (default: no)
>  static DEFINE_MUTEX(register_mutex);
>  static struct snd_usb_audio *usb_chip[SNDRV_CARDS];
>  static struct usb_driver usb_audio_driver;
> +static struct snd_usb_platform_ops *platform_ops;

As I've said before, you can not just have one of these.  They need to
be per-bus structure.  Or per-device, something dynamic, not static like
this.

> +int snd_usb_register_platform_ops(struct snd_usb_platform_ops *ops)
> +{
> +	if (platform_ops)
> +		return -EEXIST;
> +
> +	mutex_lock(&register_mutex);
> +	platform_ops = ops;
> +	mutex_unlock(&register_mutex);

Your locking is odd for a single pointer, why is it needed at all?

Also you check the pointer before using the lock, which defeats the lock
in the first place.

thanks,

greg k-h
Takashi Sakamoto March 9, 2023, 8:29 a.m. UTC | #3
Hi,

On Wed, Mar 08, 2023 at 03:57:38PM -0800, Wesley Cheng wrote:
> diff --git a/sound/usb/qcom/qc_audio_offload.c b/sound/usb/qcom/qc_audio_offload.c
> new file mode 100644
> index 000000000000..2663906644f2
> --- /dev/null
> +++ b/sound/usb/qcom/qc_audio_offload.c
> ...
> +static int enable_audio_stream(struct snd_usb_substream *subs,
> +				snd_pcm_format_t pcm_format,
> +				unsigned int channels, unsigned int cur_rate,
> +				int datainterval)
> +{
> +	struct snd_usb_audio *chip = subs->stream->chip;
> +	struct snd_pcm_hw_params params;
> +	const struct audioformat *fmt;
> +	int ret;
> +	bool fixed_rate;
> +
> +	_snd_pcm_hw_params_any(&params);
> +	_snd_pcm_hw_param_set(&params, SNDRV_PCM_HW_PARAM_FORMAT,
> +			(__force int) pcm_format, 0);
> +	_snd_pcm_hw_param_set(&params, SNDRV_PCM_HW_PARAM_CHANNELS,
> +			channels, 0);
> +	_snd_pcm_hw_param_set(&params, SNDRV_PCM_HW_PARAM_RATE,
> +			cur_rate, 0);

I think the above code is equivalent to below code.

```
// 1. Initialize the hardware parameter so that it expresses
// the maximum flags of mask parameters and the maximum range of integer
// parameters.
_snd_pcm_hw_params_any(&params);

// 2. Then shrink the mask parameters and integer parameters.
struct snd_mask *mask;
struct snd_interval *interval;

mask = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
snd_mask_leave(mask, pcm_format);

interval = hw_param_interval(params, SNDRV_PCM_HW_PARAM_CHANNELS);
snd_interval_setinteger(&interval);
interval.min = interval.max = channels;

interval = hw_param_interval(params, SNDRV_PCM_HW_PARAM_RATE);
snd_interval_setinteger(&interval);
interval.min = interval.max = cur_rate;
```

In '[PATCH v3 10/28] sound: usb: Export USB SND APIs for modules', some
codes moved from ALSA Open Sound System compatibility layer to ALSA core
to export some kernel APIs. The '_snd_pcm_hw_param_set()' is one of
them. If they were needed just for the above operations, it would be
exaggerating just for the driver.

Of course, we can assume that the similar kernel API would be required
for the other drivers (OSS PCM, USB gadget, and so on.). However, at
present, it is preferable to focus just on your driver. 

(I note that typical sound PCM driver has code to shrink hardware
parameters in PCM rule. It consists of a set of test and refine API.)


Regards

Takashi Sakamoto
Oliver Neukum March 9, 2023, 10:34 a.m. UTC | #4
On 09.03.23 00:57, Wesley Cheng wrote:

> @@ -1865,8 +1889,15 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
>   
>   	cancel_delayed_work_sync(&xhci->cmd_timer);
>   
> -	xhci_free_interrupter(xhci, xhci->interrupter);
> -	xhci->interrupter = NULL;
> +	for (i = 1; i < xhci->max_interrupters; i++) {
> +		if (xhci->interrupters[i])
> +			xhci_remove_secondary_interrupter(xhci_to_hcd(xhci),
> +							  xhci->interrupters[i]);
> +	}
> +
> +	/* free the primary interrupter, interrupter number 0 */
> +	xhci_free_interrupter(xhci, xhci->interrupters[0]);
> +	xhci->interrupters[0] = NULL;
>   	xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Freed primary event ring");

Any reason you are not just counting down to zero?

> +	if (idx > 0) {
> +		ir = xhci_alloc_interrupter(xhci, idx, GFP_KERNEL);
> +		if (!ir) {
> +			spin_unlock_irqrestore(&xhci->lock, flags);

Why use _irqrestore?

	Regards
		Oliver
Oliver Neukum March 9, 2023, 11:16 a.m. UTC | #5
On 09.03.23 00:57, Wesley Cheng wrote:
> Allow for different platforms to be notified on USB SND connect/disconnect
> seqeunces.  This allows for platform USB SND modules to properly initialize
> and populate internal structures with references to the USB SND chip
> device.
> 
> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
> ---
>   sound/usb/card.c | 36 ++++++++++++++++++++++++++++++++++++
>   sound/usb/card.h | 20 ++++++++++++++++++++
>   2 files changed, 56 insertions(+)
> 
> diff --git a/sound/usb/card.c b/sound/usb/card.c
> index 26268ffb8274..9bcbaa0c0a55 100644
> --- a/sound/usb/card.c
> +++ b/sound/usb/card.c
> @@ -117,6 +117,30 @@ MODULE_PARM_DESC(skip_validation, "Skip unit descriptor validation (default: no)
>   static DEFINE_MUTEX(register_mutex);
>   static struct snd_usb_audio *usb_chip[SNDRV_CARDS];
>   static struct usb_driver usb_audio_driver;
> +static struct snd_usb_platform_ops *platform_ops;
> +
> +int snd_usb_register_platform_ops(struct snd_usb_platform_ops *ops)
> +{
> +	if (platform_ops)
> +		return -EEXIST;
> +
> +	mutex_lock(&register_mutex);
> +	platform_ops = ops;
> +	mutex_unlock(&register_mutex);

This looks _highly_ suspicious.
Why does the assignment need a lock, but the check does not?

	Regards
		Oliver
Pierre-Louis Bossart March 9, 2023, 5:54 p.m. UTC | #6
> +config QC_USB_AUDIO_OFFLOAD
> +	tristate "Qualcomm Audio Offload driver"

"Qualcomm USB Audio Offload driver"

> +	select SND_PCM

depends on SND_USB_AUDIO ?

> +	help
> +	  Say Y here to enable the Qualcomm USB audio offloading feature
> +
> +	  This module sets up the required QMI stream enable/disable
> +	  responses to requests generated by the audio DSP.  It passes the
> +	  USB transfer resource references, so that the audio DSP can issue
> +	  USB transfers to the host controller.
> +
> +	  To compile this driver as a module, choose M here: the module
> +	  will be called qc-audio-offload.

> +#include <linux/ctype.h>
> +#include <linux/moduleparam.h>
> +#include <linux/module.h>
> +#include <linux/usb.h>
> +#include <linux/init.h>

alphabetical order?

> +#include <linux/usb/hcd.h>
> +#include <linux/usb/xhci-intr.h>
> +#include <linux/usb/quirks.h>
> +#include <linux/usb/audio.h>
> +#include <linux/usb/audio-v2.h>
> +#include <linux/usb/audio-v3.h>
> +#include <linux/soc/qcom/qmi.h>
> +#include <linux/iommu.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/dma-map-ops.h>
> +#include <sound/q6usboffload.h>
> +
> +#include <sound/control.h>
> +#include <sound/core.h>
> +#include <sound/info.h>
> +#include <sound/pcm.h>
> +#include <sound/pcm_params.h>
> +#include <sound/initval.h>
> +
> +#include <sound/soc.h>
> +#include <sound/soc-usb.h>
> +#include "../usbaudio.h"
> +#include "../card.h"
> +#include "../midi.h"
> +#include "../mixer.h"
> +#include "../proc.h"
> +#include "../quirks.h"
> +#include "../endpoint.h"
> +#include "../helper.h"
> +#include "../pcm.h"
> +#include "../format.h"
> +#include "../power.h"
> +#include "../stream.h"
> +#include "../media.h"

this looks weird, are all these needed?

> +
> +#define SND_PCM_CARD_NUM_MASK 0xffff0000
> +#define SND_PCM_DEV_NUM_MASK 0xff00
> +#define SND_PCM_STREAM_DIRECTION 0xff

The prefix looks wrong, or it duplicates SND_PCM stuff?

> +
> +/* iommu resource parameters and management */
> +#define PREPEND_SID_TO_IOVA(iova, sid) ((u64)(((u64)(iova)) | \
> +					(((u64)sid) << 32)))
> +#define IOVA_BASE 0x1000
> +#define IOVA_XFER_RING_BASE (IOVA_BASE + PAGE_SIZE * (SNDRV_CARDS + 1))
> +#define IOVA_XFER_BUF_BASE (IOVA_XFER_RING_BASE + PAGE_SIZE * SNDRV_CARDS * 32)
> +#define IOVA_XFER_RING_MAX (IOVA_XFER_BUF_BASE - PAGE_SIZE)
> +#define IOVA_XFER_BUF_MAX (0xfffff000 - PAGE_SIZE)
> +
> +#define MAX_XFER_BUFF_LEN (24 * PAGE_SIZE)
> +
> +struct iova_info {
> +	struct list_head list;
> +	unsigned long start_iova;
> +	size_t size;
> +	bool in_use;
> +};
> +
> +struct intf_info {
> +	unsigned long data_xfer_ring_va;
> +	size_t data_xfer_ring_size;
> +	unsigned long sync_xfer_ring_va;
> +	size_t sync_xfer_ring_size;
> +	unsigned long xfer_buf_va;
> +	size_t xfer_buf_size;
> +	phys_addr_t xfer_buf_pa;
> +	unsigned int data_ep_pipe;
> +	unsigned int sync_ep_pipe;
> +	u8 *xfer_buf;
> +	u8 intf_num;
> +	u8 pcm_card_num;
> +	u8 pcm_dev_num;
> +	u8 direction;
> +	bool in_use;
> +};
> +
> +struct uaudio_qmi_dev {
> +	struct device *dev;
> +	u32 sid;
> +	u32 intr_num;
> +	struct xhci_interrupter *ir;
> +	struct xhci_ring *sec_ring;
> +	struct iommu_domain *domain;
> +
> +	/* list to keep track of available iova */
> +	struct list_head xfer_ring_list;
> +	size_t xfer_ring_iova_size;
> +	unsigned long curr_xfer_ring_iova;
> +	struct list_head xfer_buf_list;
> +	size_t xfer_buf_iova_size;
> +	unsigned long curr_xfer_buf_iova;
> +
> +	/* bit fields representing pcm card enabled */
> +	unsigned long card_slot;
> +	/* indicate event ring mapped or not */
> +	bool er_mapped;
> +	/* reference count to number of possible consumers */
> +	atomic_t qdev_in_use;
> +	/* idx to last udev card number plugged in */
> +	unsigned int last_card_num;
> +};
> +
> +struct uaudio_dev {
> +	struct usb_device *udev;
> +	/* audio control interface */
> +	struct usb_host_interface *ctrl_intf;
> +	unsigned int card_num;
> +	unsigned int usb_core_id;
> +	atomic_t in_use;
> +	struct kref kref;
> +	wait_queue_head_t disconnect_wq;
> +
> +	/* interface specific */
> +	int num_intf;
> +	struct intf_info *info;
> +	struct snd_usb_audio *chip;
> +};

This looks too detailed, isnt' that a duplication of other structures
that exist in the regular USB audio part?

There's nothing that looks QCOM-specific anyways.

> +
> +static struct uaudio_dev uadev[SNDRV_CARDS];
> +static struct uaudio_qmi_dev *uaudio_qdev;
> +static struct uaudio_qmi_svc *uaudio_svc;
> +static DEFINE_MUTEX(qdev_mutex);
> +
> +struct uaudio_qmi_svc {
> +	struct qmi_handle *uaudio_svc_hdl;
> +	struct work_struct qmi_disconnect_work;
> +	struct workqueue_struct *uaudio_wq;
> +	struct sockaddr_qrtr client_sq;
> +	bool client_connected;
> +};
> +
> +enum mem_type {
> +	MEM_EVENT_RING,
> +	MEM_XFER_RING,
> +	MEM_XFER_BUF,
> +};

prefixes better than 'MEM'?

> +
> +/* Supported audio formats */
> +enum usb_qmi_audio_format {
> +	USB_QMI_PCM_FORMAT_S8 = 0,
> +	USB_QMI_PCM_FORMAT_U8,
> +	USB_QMI_PCM_FORMAT_S16_LE,
> +	USB_QMI_PCM_FORMAT_S16_BE,
> +	USB_QMI_PCM_FORMAT_U16_LE,
> +	USB_QMI_PCM_FORMAT_U16_BE,
> +	USB_QMI_PCM_FORMAT_S24_LE,
> +	USB_QMI_PCM_FORMAT_S24_BE,
> +	USB_QMI_PCM_FORMAT_U24_LE,
> +	USB_QMI_PCM_FORMAT_U24_BE,
> +	USB_QMI_PCM_FORMAT_S24_3LE,
> +	USB_QMI_PCM_FORMAT_S24_3BE,
> +	USB_QMI_PCM_FORMAT_U24_3LE,
> +	USB_QMI_PCM_FORMAT_U24_3BE,
> +	USB_QMI_PCM_FORMAT_S32_LE,
> +	USB_QMI_PCM_FORMAT_S32_BE,
> +	USB_QMI_PCM_FORMAT_U32_LE,
> +	USB_QMI_PCM_FORMAT_U32_BE,
> +};
> +
> +static enum usb_audio_device_speed_enum_v01
> +get_speed_info(enum usb_device_speed udev_speed)
> +{
> +	switch (udev_speed) {
> +	case USB_SPEED_LOW:
> +		return USB_AUDIO_DEVICE_SPEED_LOW_V01;
> +	case USB_SPEED_FULL:
> +		return USB_AUDIO_DEVICE_SPEED_FULL_V01;
> +	case USB_SPEED_HIGH:
> +		return USB_AUDIO_DEVICE_SPEED_HIGH_V01;
> +	case USB_SPEED_SUPER:
> +		return USB_AUDIO_DEVICE_SPEED_SUPER_V01;
> +	case USB_SPEED_SUPER_PLUS:
> +		return USB_AUDIO_DEVICE_SPEED_SUPER_PLUS_V01;
> +	default:
> +		return USB_AUDIO_DEVICE_SPEED_INVALID_V01;
> +	}
> +}

this doesn't look qcom-specific, why is this here?

> +
> +static struct snd_usb_substream *find_substream(unsigned int card_num,
> +	unsigned int pcm_idx, unsigned int direction)
> +{
> +	struct snd_usb_stream *as;
> +	struct snd_usb_substream *subs = NULL;
> +	struct snd_usb_audio *chip;
> +
> +	chip = uadev[card_num].chip;
> +	if (!chip || atomic_read(&chip->shutdown))
> +		goto done;
> +
> +	if (pcm_idx >= chip->pcm_devs)
> +		goto done;
> +
> +	if (direction > SNDRV_PCM_STREAM_CAPTURE)
> +		goto done;
> +
> +	list_for_each_entry(as, &chip->pcm_list, list) {
> +		if (as->pcm_index == pcm_idx) {
> +			subs = &as->substream[direction];
> +			goto done;
> +		}
> +	}
> +
> +done:
> +	return subs;
> +}
> +
> +static int info_idx_from_ifnum(int card_num, int intf_num, bool enable)
> +{
> +	int i;
> +
> +	/*
> +	 * default index 0 is used when info is allocated upon
> +	 * first enable audio stream req for a pcm device
> +	 */
> +	if (enable && !uadev[card_num].info)
> +		return 0;
> +
> +	for (i = 0; i < uadev[card_num].num_intf; i++) {
> +		if (enable && !uadev[card_num].info[i].in_use)
> +			return i;
> +		else if (!enable &&
> +				uadev[card_num].info[i].intf_num == intf_num)
> +			return i;
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static int get_data_interval_from_si(struct snd_usb_substream *subs,
> +	u32 service_interval)
> +{
> +	unsigned int bus_intval, bus_intval_mult, binterval;
> +
> +	if (subs->dev->speed >= USB_SPEED_HIGH)
> +		bus_intval = BUS_INTERVAL_HIGHSPEED_AND_ABOVE;
> +	else
> +		bus_intval = BUS_INTERVAL_FULL_SPEED;
> +
> +	if (service_interval % bus_intval)
> +		return -EINVAL;
> +
> +	bus_intval_mult = service_interval / bus_intval;
> +	binterval = ffs(bus_intval_mult);
> +	if (!binterval || binterval > MAX_BINTERVAL_ISOC_EP)
> +		return -EINVAL;
> +
> +	/* check if another bit is set then bail out */
> +	bus_intval_mult = bus_intval_mult >> binterval;
> +	if (bus_intval_mult)
> +		return -EINVAL;
> +
> +	return (binterval - 1);
> +}

this doesn't look qcom-specific either, is this a set of helpers that
need to be moved somewhere else?


> +/**
> + * disable_audio_stream() - disable usb snd endpoints
> + * @subs: usb substream
> + *
> + * Closes the USB SND endpoints associated with the current audio stream
> + * used.  This will decrement the USB SND endpoint opened reference count.
> + *
> + */
> +static void disable_audio_stream(struct snd_usb_substream *subs)
> +{
> +	struct snd_usb_audio *chip = subs->stream->chip;
> +
> +	if (subs->data_endpoint || subs->sync_endpoint) {
> +		close_endpoints(chip, subs);
> +
> +		mutex_lock(&chip->mutex);
> +		subs->cur_audiofmt = NULL;
> +		mutex_unlock(&chip->mutex);
> +	}
> +
> +	snd_usb_autosuspend(chip);
> +}

also not qcom-specific?

> +/* kref release callback when all streams are disabled */

what does "all streams disabled" mean, and when does this happen?

> +static void uaudio_dev_release(struct kref *kref)
> +{
> +	struct uaudio_dev *dev = container_of(kref, struct uaudio_dev, kref);
> +
> +	uaudio_event_ring_cleanup_free(dev);
> +	atomic_set(&dev->in_use, 0);
> +	wake_up(&dev->disconnect_wq);
> +}


> +static int __init qc_usb_audio_offload_init(void)
> +{
> +	struct uaudio_qmi_svc *svc;
> +	int ret;
> +
> +	ret = snd_usb_register_platform_ops(&offload_ops);
> +	if (ret < 0)
> +		return ret;

so what happens if snd_usb is blacklisted or takes time to probe?

This seems to assume a timing dependency when USB is initialized/probed
first?

> +
> +	svc = kzalloc(sizeof(struct uaudio_qmi_svc), GFP_KERNEL);
> +	if (!svc) {
> +		ret = -ENOMEM;
> +		goto unreg_ops;
> +	}
> +
> +	svc->uaudio_wq = create_singlethread_workqueue("uaudio_svc");
> +	if (!svc->uaudio_wq) {
> +		ret = -ENOMEM;
> +		goto free_svc;
> +	}
> +
> +	svc->uaudio_svc_hdl = kzalloc(sizeof(struct qmi_handle), GFP_KERNEL);
> +	if (!svc->uaudio_svc_hdl) {
> +		ret = -ENOMEM;
> +		goto free_wq;
> +	}
> +
> +	ret = qmi_handle_init(svc->uaudio_svc_hdl,
> +				QMI_UAUDIO_STREAM_REQ_MSG_V01_MAX_MSG_LEN,
> +				&uaudio_svc_ops_options,
> +				&uaudio_stream_req_handlers);
> +	ret = qmi_add_server(svc->uaudio_svc_hdl, UAUDIO_STREAM_SERVICE_ID_V01,
> +					UAUDIO_STREAM_SERVICE_VERS_V01, 0);
> +
> +	INIT_WORK(&svc->qmi_disconnect_work, qmi_disconnect_work);
> +	uaudio_svc = svc;
> +
> +	return 0;
> +
> +free_wq:
> +	destroy_workqueue(svc->uaudio_wq);
> +free_svc:
> +	kfree(svc);
> +unreg_ops:
> +	snd_usb_unregister_platform_ops();
> +
> +	return ret;
> +}
> +
> +static void __exit qc_usb_audio_offload_exit(void)
> +{
> +	struct uaudio_qmi_svc *svc = uaudio_svc;
> +
> +	qmi_handle_release(svc->uaudio_svc_hdl);
> +	flush_workqueue(svc->uaudio_wq);
> +	destroy_workqueue(svc->uaudio_wq);
> +	kfree(svc);
> +	uaudio_svc = NULL;
> +	snd_usb_unregister_platform_ops();
> +}
> +
> +module_init(qc_usb_audio_offload_init);
> +module_exit(qc_usb_audio_offload_exit);

what causes this module to be loaded?

> +
> +MODULE_DESCRIPTION("QC USB Audio Offloading");
> +MODULE_LICENSE("GPL");
> diff --git a/sound/usb/qcom/usb_audio_qmi_v01.c b/sound/usb/qcom/usb_audio_qmi_v01.c
> new file mode 100644
> index 000000000000..1a0f2f579786
> --- /dev/null
> +++ b/sound/usb/qcom/usb_audio_qmi_v01.c
> @@ -0,0 +1,892 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include <linux/soc/qcom/qmi.h>
> +
> +#include "usb_audio_qmi_v01.h"
> +
> +static struct qmi_elem_info mem_info_v01_ei[] = {
> +	{
> +		.data_type	= QMI_UNSIGNED_8_BYTE,
> +		.elem_len	= 1,
> +		.elem_size	= sizeof(u64),
> +		.array_type	= NO_ARRAY,
> +		.tlv_type	= 0,
> +		.offset		= offsetof(struct mem_info_v01, va),
> +	},

maybe move these arrays to a different patch that we don't need to
scroll-through or review...

> +	{
> +		.data_type	= QMI_UNSIGNED_8_BYTE,
> +		.elem_len	= 1,
> +		.elem_size	= sizeof(u64),
> +		.array_type	= NO_ARRAY,
> +		.tlv_type	= 0,
> +		.offset		= offsetof(struct mem_info_v01, pa),
> +	},
> +	{
> +		.data_type	= QMI_UNSIGNED_4_BYTE,
> +		.elem_len	= 1,
> +		.elem_size	= sizeof(u32),
> +		.array_type	= NO_ARRAY,
> +		.tlv_type	= 0,
> +		.offset		= offsetof(struct mem_info_v01, size),
> +	},
> +	{
> +		.data_type	= QMI_EOTI,
> +		.array_type	= NO_ARRAY,
> +		.tlv_type	= QMI_COMMON_TLV_TYPE,
> +	},
> +};
Wesley Cheng March 9, 2023, 9:10 p.m. UTC | #7
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
Pierre-Louis Bossart March 10, 2023, 12:37 a.m. UTC | #8
>>> 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.
Claudiu.Beznea--- via Alsa-devel March 10, 2023, 12:17 p.m. UTC | #9
On 09.03.2023 01:57, Wesley Cheng wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Some use cases, such as USB audio offloading, will allow for a DSP to take
> over issuing USB transfers to the host controller.  In order for the DSP to
> submit transfers for a particular endpoint, and to handle its events, the
> client driver will need to query for some parameters allocated by XHCI.
> 
> - XHCI secondary interrupter event ring address
> - XHCI transfer ring address (for a particular EP)
> - Stop endpoint command API
> 
> Once the resources are handed off to the DSP, the offload begins, and the
> main processor can enter idle.  When stopped, since there are no URBs
> submitted from the main processor, the client will just issue a stop
> endpoint command to halt any pending transfers.
> 
> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
> ---
>  drivers/usb/host/xhci.c       | 130 ++++++++++++++++++++++++++++++++++
>  include/linux/usb/xhci-intr.h |   8 +++
>  2 files changed, 138 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 88435b9cd66e..5c6b3d8f834c 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -1603,6 +1603,136 @@ static int xhci_check_args(struct usb_hcd *hcd, struct usb_device *udev,
>         return 1;
>  }
> 
> +int xhci_stop_endpoint(struct usb_device *udev,
> +                       struct usb_host_endpoint *ep)
> +{
> +       struct usb_hcd *hcd = bus_to_hcd(udev->bus);
> +       struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> +       unsigned int ep_index;
> +       struct xhci_virt_device *virt_dev;
> +       struct xhci_command *cmd;
> +       unsigned long flags;
> +       int ret = 0;

No need to initialize it.

> +
> +       ret = xhci_check_args(hcd, udev, ep, 1, true, __func__);
> +       if (ret <= 0)
> +               return ret;
> +
> +       cmd = xhci_alloc_command(xhci, true, GFP_NOIO);
> +       if (!cmd)
> +               return -ENOMEM;
> +
> +       spin_lock_irqsave(&xhci->lock, flags);
> +       virt_dev = xhci->devs[udev->slot_id];
> +       if (!virt_dev) {
> +               ret = -ENODEV;
> +               goto err;
> +       }
> +
> +       ep_index = xhci_get_endpoint_index(&ep->desc);
> +       if (virt_dev->eps[ep_index].ring &&
> +                       virt_dev->eps[ep_index].ring->dequeue) {
> +               ret = xhci_queue_stop_endpoint(xhci, cmd, udev->slot_id,
> +                               ep_index, 0);
> +               if (ret)
> +                       goto err;
> +
> +               xhci_ring_cmd_db(xhci);
> +               spin_unlock_irqrestore(&xhci->lock, flags);
> +
> +               /* Wait for stop endpoint command to finish */
> +               wait_for_completion(cmd->completion);
> +
> +               if (cmd->status == COMP_COMMAND_ABORTED ||
> +                               cmd->status == COMP_STOPPED) {

                      ^ usually here go 2nd condition

> +                       xhci_warn(xhci,
> +                               "stop endpoint command timeout for ep%d%s\n",
> +                               usb_endpoint_num(&ep->desc),
> +                               usb_endpoint_dir_in(&ep->desc) ? "in" : "out");
> +                       ret = -ETIME;
> +                               }

} should be aligned with if

[ ... ]
Mathias Nyman March 10, 2023, 3:07 p.m. UTC | #10
On 9.3.2023 1.57, Wesley Cheng wrote:
> From: Mathias Nyman <mathias.nyman@linux.intel.com>
> 
> Introduce xHCI APIs to allow for clients to allocate and free
> interrupters.  This allocates an array of interrupters, which is based on
> the max_interrupters parameter.  The primary interrupter is set as the
> first entry in the array, and secondary interrupters following after.
> 

I'm thinking about changing this offloading xHCI API
xhci should be aware and keep track of which devices and endpoints that
are offloaded to avoid device getting offloaded twice, avoid xhci driver
from queuing anything itself for these, and act properly if the offloaded
device or entire host is removed.

So first thing audio side would need to do do is register/create an
offload entry for the device using the API:

struct xhci_sideband *xhci_sideband_register(struct usb_device *udev)

(xHCI specs calls offload sideband)
Then endpoints and interrupters can be added and removed from this
offload entry

I have some early thoughts written as non-compiling code in:

git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git feature_interrupters
https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters

Let me know what you think about this.

> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>

My Signed-off-by tag is being misused here.

I wrote a chunk of the code in this patch as PoC that I shared in a separate topic branch.
It was incomplete and not intended for upstream yet. (lacked locking, several fixme parts, etc..)
The rest of the code in this patch is completely new to me.

Thanks
-Mathias
Wesley Cheng March 13, 2023, 8:32 p.m. UTC | #11
Hi Mathias,

On 3/10/2023 7:07 AM, Mathias Nyman wrote:
> On 9.3.2023 1.57, Wesley Cheng wrote:
>> From: Mathias Nyman <mathias.nyman@linux.intel.com>
>>
>> Introduce xHCI APIs to allow for clients to allocate and free
>> interrupters.  This allocates an array of interrupters, which is based on
>> the max_interrupters parameter.  The primary interrupter is set as the
>> first entry in the array, and secondary interrupters following after.
>>
> 
> I'm thinking about changing this offloading xHCI API
> xhci should be aware and keep track of which devices and endpoints that
> are offloaded to avoid device getting offloaded twice, avoid xhci driver
> from queuing anything itself for these, and act properly if the offloaded
> device or entire host is removed.
> 
> So first thing audio side would need to do do is register/create an
> offload entry for the device using the API:
> 
> struct xhci_sideband *xhci_sideband_register(struct usb_device *udev)
> 
> (xHCI specs calls offload sideband)
> Then endpoints and interrupters can be added and removed from this
> offload entry
> 
> I have some early thoughts written as non-compiling code in:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git 
> feature_interrupters
> https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters 
> 
> 
> Let me know what you think about this.
> 
>> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
> 
> My Signed-off-by tag is being misused here.
> 
> I wrote a chunk of the code in this patch as PoC that I shared in a 
> separate topic branch.
> It was incomplete and not intended for upstream yet. (lacked locking, 
> several fixme parts, etc..)
> The rest of the code in this patch is completely new to me.
> 

Sorry about this.  I cherry picked the change directly from your branch, 
so it carried your signed off tag with it.  Will make to include them 
properly next time.

Thanks
Wesley Cheng
Wesley Cheng March 13, 2023, 11:43 p.m. UTC | #12
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
Wesley Cheng March 14, 2023, 1:42 a.m. UTC | #13
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
Wesley Cheng March 15, 2023, 12:08 a.m. UTC | #14
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
Mark Brown March 15, 2023, 4:29 p.m. UTC | #15
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.
Wesley Cheng March 15, 2023, 7:42 p.m. UTC | #16
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
Wesley Cheng April 25, 2023, 1:17 a.m. UTC | #17
Hi Mathias,

On 3/13/2023 1:08 PM, Wesley Cheng wrote:
> Hi Mathias,
> 
> On 3/10/2023 7:07 AM, Mathias Nyman wrote:
>> On 9.3.2023 1.57, Wesley Cheng wrote:
>>> From: Mathias Nyman <mathias.nyman@linux.intel.com>
>>>
>>> Introduce xHCI APIs to allow for clients to allocate and free
>>> interrupters.  This allocates an array of interrupters, which is 
>>> based on
>>> the max_interrupters parameter.  The primary interrupter is set as the
>>> first entry in the array, and secondary interrupters following after.
>>>
>>
>> I'm thinking about changing this offloading xHCI API
>> xhci should be aware and keep track of which devices and endpoints that
>> are offloaded to avoid device getting offloaded twice, avoid xhci driver
>> from queuing anything itself for these, and act properly if the offloaded
>> device or entire host is removed.
>>
>> So first thing audio side would need to do do is register/create an
>> offload entry for the device using the API:
>>
>> struct xhci_sideband *xhci_sideband_register(struct usb_device *udev)
>>
>> (xHCI specs calls offload sideband)
>> Then endpoints and interrupters can be added and removed from this
>> offload entry
>>
>> I have some early thoughts written as non-compiling code in:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git 
>> feature_interrupters
>> https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters 
>>
>>
>> Let me know what you think about this.
>>
> 
> The concept/framework you built looks good to me.  Makes sense to have 
> XHCI better maintain the offloading users.  One thing I would request is 
> to move xhci-sideband.h to the include directory since the class driver 
> levels would need to be able to reference the structure and APIs you've 
> exposed.
> 
> I have yet to try it with our implementation, but I'll work on plugging 
> it in and fix any issues I see along the way.

Sorry for the late reply on some of the efforts on adding your new 
xhci-sideband driver.

I saw your comments with respect to building the SG table for rings with 
multiple segments, ie stream xfer rings.  I had tried some things to 
achieve the page links, but after reviewing some of the Linux memory 
APIs, I'm not sure we can achieve it.  This is because we're not simply 
relying on the direct DMA ops here to build the SG table.  In the IOMMU 
mapped cases, it calls in iommu_dma_get_sgtable(), which has some 
convoluted logic to build the sgt.

Instead of allocating one sgt with multiple sgls (based on # of ring 
segments), would it make sense to just build multiple sgts for each ring 
segment?  The vendor class driver could still fetch the required memory 
information to translate each sgt to a physical address and ring segment 
linking can happen within the external DSP if it supports it.

Thanks
Wesley Cheng
Wesley Cheng June 23, 2023, 10:37 p.m. UTC | #18
Hi Mathias,

On 3/13/2023 1:32 PM, Wesley Cheng wrote:
> Hi Mathias,
> 
> On 3/10/2023 7:07 AM, Mathias Nyman wrote:
>> On 9.3.2023 1.57, Wesley Cheng wrote:
>>> From: Mathias Nyman <mathias.nyman@linux.intel.com>
>>>
>>> Introduce xHCI APIs to allow for clients to allocate and free
>>> interrupters.  This allocates an array of interrupters, which is 
>>> based on
>>> the max_interrupters parameter.  The primary interrupter is set as the
>>> first entry in the array, and secondary interrupters following after.
>>>
>>
>> I'm thinking about changing this offloading xHCI API
>> xhci should be aware and keep track of which devices and endpoints that
>> are offloaded to avoid device getting offloaded twice, avoid xhci driver
>> from queuing anything itself for these, and act properly if the offloaded
>> device or entire host is removed.
>>
>> So first thing audio side would need to do do is register/create an
>> offload entry for the device using the API:
>>
>> struct xhci_sideband *xhci_sideband_register(struct usb_device *udev)
>>
>> (xHCI specs calls offload sideband)
>> Then endpoints and interrupters can be added and removed from this
>> offload entry
>>
>> I have some early thoughts written as non-compiling code in:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git 
>> feature_interrupters
>> https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters 
>>
>>
>> Let me know what you think about this.
>>
>>> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>>> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
>>
>> My Signed-off-by tag is being misused here.
>>
>> I wrote a chunk of the code in this patch as PoC that I shared in a 
>> separate topic branch.
>> It was incomplete and not intended for upstream yet. (lacked locking, 
>> several fixme parts, etc..)
>> The rest of the code in this patch is completely new to me.
>>
> 
> Sorry about this.  I cherry picked the change directly from your branch, 
> so it carried your signed off tag with it.  Will make to include them 
> properly next time.
> 

I'm about ready to submit the next revision for this set of changes, and 
I was wondering how we should handle the changes you made on:
https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters

I did make some modifications to some of the interrupter fixme tags you 
had, and also updated the xhci-sideband APIs with the proper logic.  I 
don't believe it is correct for me to submit a set of patches authored 
by you without your signed off tag. (checkpatch throws an error saying 
the author did not sign off on the change)

Thanks
Wesley Cheng
Mathias Nyman June 26, 2023, 1:55 p.m. UTC | #19
On 24.6.2023 1.37, Wesley Cheng wrote:
> Hi Mathias,
> 
> On 3/13/2023 1:32 PM, Wesley Cheng wrote:
>> Hi Mathias,
>>
>> On 3/10/2023 7:07 AM, Mathias Nyman wrote:
>>> On 9.3.2023 1.57, Wesley Cheng wrote:
>>>> From: Mathias Nyman <mathias.nyman@linux.intel.com>
>>>>
>>>> Introduce xHCI APIs to allow for clients to allocate and free
>>>> interrupters.  This allocates an array of interrupters, which is based on
>>>> the max_interrupters parameter.  The primary interrupter is set as the
>>>> first entry in the array, and secondary interrupters following after.
>>>>
>>>
>>> I'm thinking about changing this offloading xHCI API
>>> xhci should be aware and keep track of which devices and endpoints that
>>> are offloaded to avoid device getting offloaded twice, avoid xhci driver
>>> from queuing anything itself for these, and act properly if the offloaded
>>> device or entire host is removed.
>>>
>>> So first thing audio side would need to do do is register/create an
>>> offload entry for the device using the API:
>>>
>>> struct xhci_sideband *xhci_sideband_register(struct usb_device *udev)
>>>
>>> (xHCI specs calls offload sideband)
>>> Then endpoints and interrupters can be added and removed from this
>>> offload entry
>>>
>>> I have some early thoughts written as non-compiling code in:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git feature_interrupters
>>> https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters
>>>
>>> Let me know what you think about this.
>>>
>>>> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>>>> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
>>>
>>> My Signed-off-by tag is being misused here.
>>>
>>> I wrote a chunk of the code in this patch as PoC that I shared in a separate topic branch.
>>> It was incomplete and not intended for upstream yet. (lacked locking, several fixme parts, etc..)
>>> The rest of the code in this patch is completely new to me.
>>>
>>
>> Sorry about this.  I cherry picked the change directly from your branch, so it carried your signed off tag with it.  Will make to include them properly next time.
>>
> 
> I'm about ready to submit the next revision for this set of changes, and I was wondering how we should handle the changes you made on:
> https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters
> 
> I did make some modifications to some of the interrupter fixme tags you had, and also updated the xhci-sideband APIs with the proper logic.  I don't believe it is correct for me to submit a set of patches authored by you without your signed off tag. (checkpatch throws an error saying the author did not sign off on the change)
> 

Note that the first patch "xhci: split allocate interrupter into separate alloacte and add parts"
is already in usb-next on its way to 6.5

Maybe Co-developed-by would work in this case, with a small explanation at the end of the commit message.
Something like:

Locking, DMA something and feataure x added by Wesley Cheng to
complete original concept code by Mathias

Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Co-developed-by: Wesley Cheng <quic_wcheng@quicinc.com>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>

Thanks
-Mathias
Wesley Cheng June 26, 2023, 3:05 p.m. UTC | #20
Hi Mathias,

On 6/26/2023 6:55 AM, Mathias Nyman wrote:
> On 24.6.2023 1.37, Wesley Cheng wrote:
>> Hi Mathias,
>>
>> On 3/13/2023 1:32 PM, Wesley Cheng wrote:
>>> Hi Mathias,
>>>
>>> On 3/10/2023 7:07 AM, Mathias Nyman wrote:
>>>> On 9.3.2023 1.57, Wesley Cheng wrote:
>>>>> From: Mathias Nyman <mathias.nyman@linux.intel.com>
>>>>>
>>>>> Introduce xHCI APIs to allow for clients to allocate and free
>>>>> interrupters.  This allocates an array of interrupters, which is 
>>>>> based on
>>>>> the max_interrupters parameter.  The primary interrupter is set as the
>>>>> first entry in the array, and secondary interrupters following after.
>>>>>
>>>>
>>>> I'm thinking about changing this offloading xHCI API
>>>> xhci should be aware and keep track of which devices and endpoints that
>>>> are offloaded to avoid device getting offloaded twice, avoid xhci 
>>>> driver
>>>> from queuing anything itself for these, and act properly if the 
>>>> offloaded
>>>> device or entire host is removed.
>>>>
>>>> So first thing audio side would need to do do is register/create an
>>>> offload entry for the device using the API:
>>>>
>>>> struct xhci_sideband *xhci_sideband_register(struct usb_device *udev)
>>>>
>>>> (xHCI specs calls offload sideband)
>>>> Then endpoints and interrupters can be added and removed from this
>>>> offload entry
>>>>
>>>> I have some early thoughts written as non-compiling code in:
>>>>
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git 
>>>> feature_interrupters
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters 
>>>>
>>>>
>>>> Let me know what you think about this.
>>>>
>>>>> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>>>>> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
>>>>
>>>> My Signed-off-by tag is being misused here.
>>>>
>>>> I wrote a chunk of the code in this patch as PoC that I shared in a 
>>>> separate topic branch.
>>>> It was incomplete and not intended for upstream yet. (lacked 
>>>> locking, several fixme parts, etc..)
>>>> The rest of the code in this patch is completely new to me.
>>>>
>>>
>>> Sorry about this.  I cherry picked the change directly from your 
>>> branch, so it carried your signed off tag with it.  Will make to 
>>> include them properly next time.
>>>
>>
>> I'm about ready to submit the next revision for this set of changes, 
>> and I was wondering how we should handle the changes you made on:
>> https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters 
>>
>>
>> I did make some modifications to some of the interrupter fixme tags 
>> you had, and also updated the xhci-sideband APIs with the proper 
>> logic.  I don't believe it is correct for me to submit a set of 
>> patches authored by you without your signed off tag. (checkpatch 
>> throws an error saying the author did not sign off on the change)
>>
> 
> Note that the first patch "xhci: split allocate interrupter into 
> separate alloacte and add parts"
> is already in usb-next on its way to 6.5
> 
> Maybe Co-developed-by would work in this case, with a small explanation 
> at the end of the commit message.
> Something like:
> 
> Locking, DMA something and feataure x added by Wesley Cheng to
> complete original concept code by Mathias
> 
> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
> Co-developed-by: Wesley Cheng <quic_wcheng@quicinc.com>
> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
> 

Sounds good!  Thanks for helping with a non-technical question :).  Just 
wanted to make sure I wasn't overstepping anywhere.

Thanks
Wesley Cheng