From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Wesley Cheng <quic_wcheng@quicinc.com>,
srinivas.kandagatla@linaro.org, mathias.nyman@intel.com,
perex@perex.cz, lgirdwood@gmail.com, andersson@kernel.org,
krzysztof.kozlowski+dt@linaro.org, gregkh@linuxfoundation.org,
Thinh.Nguyen@synopsys.com, broonie@kernel.org,
bgoswami@quicinc.com, tiwai@suse.com, robh+dt@kernel.org,
agross@kernel.org
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, quic_jackp@quicinc.com,
quic_plai@quicinc.com
Subject: Re: [RFC PATCH v2 16/22] sound: usb: Introduce QC USB SND offloading support
Date: Thu, 26 Jan 2023 10:07:08 -0600 [thread overview]
Message-ID: <940fdc34-3d45-05be-7087-31f576114418@linux.intel.com> (raw)
In-Reply-To: <20230126031424.14582-17-quic_wcheng@quicinc.com>
On 1/25/23 21:14, Wesley Cheng wrote:
> Several Qualcomm SoCs have a dedicated audio DSP, which has the ability to
> support USB sound devices. This vendor driver will implement the required
> handshaking with the DSP, in order to pass along required resources that
> will be utilized by the DSP's USB SW. The communication channel used for
> this handshaking will be using the QMI protocol. Required resources
> include:
> - Allocated secondary event ring address
> - EP transfer ring address
> - Interrupter number
>
> The above information will allow for the audio DSP to execute USB transfers
> over the USB bus. It will also be able to support devices that have an
> implicit feedback and sync endpoint as well. Offloading these data
> transfers will allow the main/applications processor to enter lower CPU
> power modes, and sustain a longer duration in those modes.
>
> Audio offloading is initiated with the following sequence:
> 1. Userspace configures to route audio playback to USB backend and starts
> playback on the platform soundcard.
what happens if the DSP driver is probed after the USB one?
Or vice-versa?
Userspace needs to be notified of what is detected at the kernel level,
I don't see how we can assume a specific route is always present.
> +config QC_USB_AUDIO_OFFLOAD
> + tristate "Qualcomm Audio Offload driver"
USB Audio Offload
> +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;
> +};
> +
> +static struct uaudio_dev uadev[SNDRV_CARDS];
I don't follow what this array is? Does this shadow all possible cards,
even non-USB ones?
> +static struct uaudio_qmi_dev *uaudio_qdev;
> +static struct uaudio_qmi_svc *uaudio_svc;
> +static DEFINE_MUTEX(qdev_mutex);
> +/**
> + * 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);
can you explain why the format selection is protected by a mutex? I
don't quite get what level of concurrency might happen here?
> + }
> +
> + snd_usb_autosuspend(chip);
> +}
> +
> +/**
> + * enable_audio_stream() - enable usb snd endpoints
> + * @subs: usb substream
> + * @pcm_format: pcm format requested
> + * @channels: number of channels
> + * @cur_rate: sample rate
> + * @datainterval: interval
> + *
> + * Opens all USB SND endpoints used for the data interface. This will increment
> + * the USB SND endpoint's opened count. Requests to keep the interface resumed
> + * until the audio stream is stopped. Will issue the USB set interface control
> + * message to enable the data interface.
> + *
> + */
> +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;
> +
> + _snd_pcm_hw_params_any(¶ms);
> + _snd_pcm_hw_param_set(¶ms, SNDRV_PCM_HW_PARAM_FORMAT,
> + (__force int) pcm_format, 0);
> + _snd_pcm_hw_param_set(¶ms, SNDRV_PCM_HW_PARAM_CHANNELS,
> + channels, 0);
> + _snd_pcm_hw_param_set(¶ms, SNDRV_PCM_HW_PARAM_RATE,
> + cur_rate, 0);
> +
> + pm_runtime_barrier(&chip->intf[0]->dev);
> + snd_usb_autoresume(chip);
> +
> + fmt = find_format(&subs->fmt_list, pcm_format, cur_rate,
> + channels, datainterval, subs);
> + if (!fmt) {
> + dev_err(uaudio_qdev->dev,
> + "cannot find format: format = %#x, rate = %d, ch = %d\n",
> + pcm_format, cur_rate, channels);
> + return -EINVAL;
> + }
> +
> + if (atomic_read(&chip->shutdown)) {
> + dev_err(uaudio_qdev->dev, "chip already shutdown\n");
> + ret = -ENODEV;
> + } else {
> + if (subs->data_endpoint)
> + close_endpoints(chip, subs);
> +
> + subs->data_endpoint = snd_usb_endpoint_open(chip, fmt,
> + ¶ms, false);
> + if (!subs->data_endpoint) {
> + dev_err(uaudio_qdev->dev, "failed to open data endpoint\n");
> + return -EINVAL;
> + }
> +
> + if (fmt->sync_ep) {
> + subs->sync_endpoint = snd_usb_endpoint_open(chip,
> + fmt, ¶ms, true);
> + if (!subs->sync_endpoint) {
> + dev_err(uaudio_qdev->dev,
> + "failed to open sync endpoint\n");
> + return -EINVAL;
> + }
> +
> + subs->data_endpoint->sync_source = subs->sync_endpoint;
> + }
> +
> + mutex_lock(&chip->mutex);
> + subs->cur_audiofmt = fmt;
> + mutex_unlock(&chip->mutex);
> +
> + if (subs->sync_endpoint) {
> + ret = snd_usb_endpoint_prepare(chip, subs->sync_endpoint);
> + if (ret < 0)
> + return ret;
> + }
> +
> + ret = snd_usb_endpoint_prepare(chip, subs->data_endpoint);
> + if (ret < 0)
> + return ret;
what happens in those two error cases? Should the format selected above
remain set even though the prepare failed?
> +
> + dev_dbg(uaudio_qdev->dev,
> + "selected %s iface:%d altsetting:%d datainterval:%dus\n",
> + subs->direction ? "capture" : "playback",
> + fmt->iface, fmt->altsetting,
> + (1 << fmt->datainterval) *
> + (subs->dev->speed >= USB_SPEED_HIGH ?
> + BUS_INTERVAL_HIGHSPEED_AND_ABOVE :
> + BUS_INTERVAL_FULL_SPEED));
> + }
> +
> + return 0;
> +}
<snip>
> 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..95ae434f0a41
> --- /dev/null
> +++ b/sound/usb/qcom/usb_audio_qmi_v01.c
> @@ -0,0 +1,892 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2022 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),
> + },
> + {
> + .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,
> + },
<snip>
> + {
> + .data_type = QMI_EOTI,
> + .array_type = NO_ARRAY,
> + .tlv_type = QMI_COMMON_TLV_TYPE,
> + },
> +};
Are those dozens of descriptors needed? They look mostly the same, not
sure how anyone could review this.
next prev parent reply other threads:[~2023-01-26 16:26 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-26 3:14 [RFC PATCH v2 00/22] Introduce QC USB SND audio offloading support Wesley Cheng
2023-01-26 3:14 ` [RFC PATCH v2 01/22] xhci: fix event ring segment table related masks and variables in header Wesley Cheng
2023-01-26 3:14 ` [RFC PATCH v2 02/22] xhci: remove xhci_test_trb_in_td_math early development check Wesley Cheng
2023-01-26 7:48 ` Greg KH
2023-01-26 3:14 ` [RFC PATCH v2 03/22] xhci: Refactor interrupter code for initial multi interrupter support Wesley Cheng
2023-01-26 3:14 ` [RFC PATCH v2 04/22] xhci: Add support to allocate several interrupters Wesley Cheng
2023-01-26 3:14 ` [RFC PATCH v2 05/22] usb: xhci: Add XHCI APIs to support USB offloading Wesley Cheng
2023-01-26 3:14 ` [RFC PATCH v2 06/22] usb: host: xhci-mem: Cleanup pending secondary event ring events Wesley Cheng
2023-01-26 3:14 ` [RFC PATCH v2 07/22] ASoC: Add SOC USB APIs for adding an USB backend Wesley Cheng
2023-01-26 15:32 ` Pierre-Louis Bossart
2023-01-30 22:36 ` Wesley Cheng
2023-01-28 13:26 ` Greg KH
2023-01-29 6:54 ` Zhou Furong
2023-01-29 7:09 ` Greg KH
2023-01-30 8:34 ` Zhou Furong
2023-01-30 9:27 ` Greg KH
2023-02-10 22:46 ` Wesley Cheng
2023-01-26 3:14 ` [RFC PATCH v2 08/22] ASoC: dt-bindings: Add USB_RX port Wesley Cheng
2023-01-26 11:55 ` Krzysztof Kozlowski
2023-01-30 21:52 ` Wesley Cheng
2023-01-26 3:14 ` [RFC PATCH v2 09/22] ASoC: qcom: qdsp6: Introduce USB AFE port to q6dsp Wesley Cheng
2023-01-26 15:07 ` Srinivas Kandagatla
2023-01-26 15:38 ` Pierre-Louis Bossart
2023-01-30 22:54 ` Wesley Cheng
2023-01-30 23:59 ` Pierre-Louis Bossart
2023-02-01 2:40 ` Wesley Cheng
2023-02-01 3:02 ` Pierre-Louis Bossart
2023-02-03 1:23 ` Wesley Cheng
2023-02-03 1:44 ` Wesley Cheng
2023-01-26 3:14 ` [RFC PATCH v2 10/22] ASoC: qdsp6: q6afe: Increase APR timeout Wesley Cheng
2023-01-26 15:09 ` Srinivas Kandagatla
2023-01-26 3:14 ` [RFC PATCH v2 11/22] ASoC: qcom: Add USB backend ASoC driver for Q6 Wesley Cheng
2023-01-26 15:44 ` Pierre-Louis Bossart
2023-01-30 22:59 ` Wesley Cheng
2023-01-30 23:50 ` Pierre-Louis Bossart
2023-01-26 16:35 ` Srinivas Kandagatla
2023-01-26 3:14 ` [RFC PATCH v2 12/22] sound: usb: card: Introduce USB SND platform op callbacks Wesley Cheng
2023-01-26 15:50 ` Pierre-Louis Bossart
2023-01-30 23:00 ` Wesley Cheng
2023-01-28 13:28 ` Greg KH
2023-02-10 22:49 ` Wesley Cheng
2023-02-28 2:59 ` Wesley Cheng
2023-02-28 7:30 ` Greg KH
2023-02-28 9:19 ` Wesley Cheng
2023-02-28 15:29 ` Greg KH
2023-02-20 17:11 ` Albert Wang
2023-01-26 3:14 ` [RFC PATCH v2 13/22] sound: usb: Export USB SND APIs for modules Wesley Cheng
2023-01-26 3:14 ` [RFC PATCH v2 14/22] dt-bindings: usb: dwc3: Add snps,num-hc-interrupters definition Wesley Cheng
2023-01-26 12:01 ` Krzysztof Kozlowski
2023-01-30 22:02 ` Wesley Cheng
2023-01-26 3:14 ` [RFC PATCH v2 15/22] usb: dwc3: Add DT parameter to specify maximum number of interrupters Wesley Cheng
2023-01-26 3:14 ` [RFC PATCH v2 16/22] sound: usb: Introduce QC USB SND offloading support Wesley Cheng
2023-01-26 16:07 ` Pierre-Louis Bossart [this message]
2023-01-28 13:32 ` Greg KH
2023-02-11 0:03 ` Wesley Cheng
2023-01-26 3:14 ` [RFC PATCH v2 17/22] sound: usb: card: Check for support for requested audio format Wesley Cheng
2023-01-26 3:14 ` [RFC PATCH v2 18/22] sound: soc: soc-usb: Add PCM format check API for USB backend Wesley Cheng
2023-01-26 3:14 ` [RFC PATCH v2 19/22] sound: soc: qcom: qusb6: Ensure PCM format is supported by USB audio device Wesley Cheng
2023-01-26 3:14 ` [RFC PATCH v2 20/22] sound: usb: Prevent starting of audio stream if in use Wesley Cheng
2023-01-26 16:12 ` Pierre-Louis Bossart
2023-02-07 1:15 ` Wesley Cheng
2023-02-07 13:29 ` Pierre-Louis Bossart
2023-02-11 9:52 ` Wesley Cheng
2023-02-13 15:22 ` Pierre-Louis Bossart
2023-02-13 20:12 ` Wesley Cheng
2023-01-26 3:14 ` [RFC PATCH v2 21/22] ASoC: dt-bindings: Add Q6USB backend bindings Wesley Cheng
2023-01-26 12:03 ` Krzysztof Kozlowski
2023-01-26 16:01 ` Srinivas Kandagatla
2023-01-26 3:14 ` [RFC PATCH v2 22/22] ASoC: dt-bindings: Update example for enabling USB offload on SM8250 Wesley Cheng
2023-01-26 12:05 ` Krzysztof Kozlowski
2023-01-26 9:23 ` [RFC PATCH v2 00/22] Introduce QC USB SND audio offloading support Mathias Nyman
2023-01-30 21:51 ` Wesley Cheng
2023-01-26 16:22 ` Pierre-Louis Bossart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=940fdc34-3d45-05be-7087-31f576114418@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=Thinh.Nguyen@synopsys.com \
--cc=agross@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=andersson@kernel.org \
--cc=bgoswami@quicinc.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=perex@perex.cz \
--cc=quic_jackp@quicinc.com \
--cc=quic_plai@quicinc.com \
--cc=quic_wcheng@quicinc.com \
--cc=robh+dt@kernel.org \
--cc=srinivas.kandagatla@linaro.org \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).