| Message ID | 20240203023645.31105-1-quic_wcheng@quicinc.com |
|---|---|
| Headers | show |
| Series | Introduce QC USB SND audio offloading support | expand |
On 2/3/2024 3:36 AM, Wesley Cheng wrote: > Some platforms may have support for offloading USB audio devices to a > dedicated audio DSP. Introduce a set of APIs that allow for management of > USB sound card and PCM devices enumerated by the USB SND class driver. > This allows for the ASoC components to be aware of what USB devices are > available for offloading. > > Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> > --- ... > + > +/** > + * snd_soc_usb_add_port() - Add a USB backend port > + * @dev: USB backend device > + * @priv: private data > + * @connection_cb: connection status callback > + * > + * Register a USB backend device to the SND USB SOC framework. Memory is > + * allocated as part of the USB backend device. > + * > + */ > +int snd_soc_usb_add_port(struct snd_soc_usb *usb) > +{ > + > + Cosmetic, but why is there white space between start of function and body of function? > + mutex_lock(&ctx_mutex); > + list_add_tail(&usb->list, &usb_ctx_list); > + mutex_unlock(&ctx_mutex); > + > + return 0; > +} > +EXPORT_SYMBOL_GPL(snd_soc_usb_add_port); > +
On 2/3/2024 3:36 AM, Wesley Cheng wrote: > In case of notifying SND platform drivers of connection events, some of > these use cases, such as offloading, require an ASoC USB backend device to > be initialized before the events can be handled. If the USB backend device > has not yet been probed, this leads to missing initial USB audio device > connection events. > > Expose an API that traverses the usb_chip array for connected devices, and > to call the respective connection callback registered to the SND platform > driver. > > Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> > --- > sound/usb/card.c | 19 +++++++++++++++++++ > sound/usb/card.h | 2 ++ > sound/usb/qcom/qc_audio_offload.c | 2 ++ > 3 files changed, 23 insertions(+) > > diff --git a/sound/usb/card.c b/sound/usb/card.c > index 11b827b7a2a5..995b2df676ab 100644 > --- a/sound/usb/card.c > +++ b/sound/usb/card.c > @@ -202,6 +202,25 @@ struct snd_usb_stream *snd_usb_find_suppported_substream(int card_idx, > } > EXPORT_SYMBOL_GPL(snd_usb_find_suppported_substream); > > +/* > + * in case the platform driver was not ready at the time of USB SND > + * device connect, expose an API to discover all connected USB devices > + * so it can populate any dependent resources/structures. > + */ > +void snd_usb_rediscover_devices(void) > +{ > + int i; > + > + mutex_lock(®ister_mutex); > + for (i = 0; i < SNDRV_CARDS; i++) { > + if (usb_chip[i]) > + if (platform_ops && platform_ops->connect_cb) > + platform_ops->connect_cb(usb_chip[i]); if inside if, it can just be && or maybe move callback check before mutex lock and just return early if it is not present? > + } > + mutex_unlock(®ister_mutex); > +} > +EXPORT_SYMBOL_GPL(snd_usb_rediscover_devices); > + > /* > * disconnect streams > * called from usb_audio_disconnect() > diff --git a/sound/usb/card.h b/sound/usb/card.h > index 6d59995440c3..3a0d68f453a1 100644 > --- a/sound/usb/card.h > +++ b/sound/usb/card.h > @@ -222,11 +222,13 @@ int snd_usb_unregister_platform_ops(void); > #if IS_ENABLED(CONFIG_SND_USB_AUDIO) > struct snd_usb_stream *snd_usb_find_suppported_substream(int card_idx, > struct snd_pcm_hw_params *params, int direction); > +void snd_usb_rediscover_devices(void); > #else > static struct snd_usb_stream *snd_usb_find_suppported_substream(int card_idx, > struct snd_pcm_hw_params *params, int direction) > { > return NULL; > } > +static void snd_usb_rediscover_devices(void) { } > #endif /* IS_ENABLED(CONFIG_SND_USB_AUDIO) */ > #endif /* __USBAUDIO_CARD_H */ > diff --git a/sound/usb/qcom/qc_audio_offload.c b/sound/usb/qcom/qc_audio_offload.c > index 08af82ec22ad..9b0f98600e58 100644 > --- a/sound/usb/qcom/qc_audio_offload.c > +++ b/sound/usb/qcom/qc_audio_offload.c > @@ -1867,6 +1867,8 @@ static int __init qc_usb_audio_offload_init(void) > if (ret < 0) > goto release_qmi; > > + snd_usb_rediscover_devices(); > + > return 0; > > release_qmi: >
Hi Amadeusz, On 2/5/2024 12:20 AM, Amadeusz Sławiński wrote: > On 2/3/2024 3:36 AM, Wesley Cheng wrote: >> Some platforms may have support for offloading USB audio devices to a >> dedicated audio DSP. Introduce a set of APIs that allow for >> management of >> USB sound card and PCM devices enumerated by the USB SND class driver. >> This allows for the ASoC components to be aware of what USB devices are >> available for offloading. >> >> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> >> --- > > ... > >> + >> +/** >> + * snd_soc_usb_add_port() - Add a USB backend port >> + * @dev: USB backend device >> + * @priv: private data >> + * @connection_cb: connection status callback >> + * >> + * Register a USB backend device to the SND USB SOC framework. >> Memory is >> + * allocated as part of the USB backend device. >> + * >> + */ >> +int snd_soc_usb_add_port(struct snd_soc_usb *usb) >> +{ >> + >> + > > Cosmetic, but why is there white space between start of function and > body of function? > Thanks for catching this. Will fix it. Thanks Wesley Cheng
Hi Amadeusz, On 2/5/2024 1:01 AM, Amadeusz Sławiński wrote: > On 2/3/2024 3:36 AM, Wesley Cheng wrote: >> In case of notifying SND platform drivers of connection events, some of >> these use cases, such as offloading, require an ASoC USB backend >> device to >> be initialized before the events can be handled. If the USB backend >> device >> has not yet been probed, this leads to missing initial USB audio device >> connection events. >> >> Expose an API that traverses the usb_chip array for connected devices, >> and >> to call the respective connection callback registered to the SND platform >> driver. >> >> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> >> --- >> sound/usb/card.c | 19 +++++++++++++++++++ >> sound/usb/card.h | 2 ++ >> sound/usb/qcom/qc_audio_offload.c | 2 ++ >> 3 files changed, 23 insertions(+) >> >> diff --git a/sound/usb/card.c b/sound/usb/card.c >> index 11b827b7a2a5..995b2df676ab 100644 >> --- a/sound/usb/card.c >> +++ b/sound/usb/card.c >> @@ -202,6 +202,25 @@ struct snd_usb_stream >> *snd_usb_find_suppported_substream(int card_idx, >> } >> EXPORT_SYMBOL_GPL(snd_usb_find_suppported_substream); >> +/* >> + * in case the platform driver was not ready at the time of USB SND >> + * device connect, expose an API to discover all connected USB devices >> + * so it can populate any dependent resources/structures. >> + */ >> +void snd_usb_rediscover_devices(void) >> +{ >> + int i; >> + >> + mutex_lock(®ister_mutex); >> + for (i = 0; i < SNDRV_CARDS; i++) { >> + if (usb_chip[i]) >> + if (platform_ops && platform_ops->connect_cb) >> + platform_ops->connect_cb(usb_chip[i]); > > if inside if, it can just be && or maybe move callback check before > mutex lock and just return early if it is not present? > Thanks for pointing that out. Makes sense, and will update it. Thanks Wesley Cheng
On Sat, 03 Feb 2024 03:36:40 +0100, Wesley Cheng wrote: > > In order to allow userspace/applications know about USB offloading status, > expose a sound kcontrol that fetches information about which sound card > index is associated with the ASoC platform card supporting offloading. In > the USB audio offloading framework, the ASoC BE DAI link is the entity > responsible for registering to the SOC USB layer. SOC USB will expose more > details about the current offloading status, which includes the USB sound > card and USB PCM device indexes currently being used. > > Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> The concept is understandable, but the control element name ("SNDUSB OFFLD playback available") looks non-intrusive and non-conformant. Use a bit more understandable name instead. This provides a card number where the offload driver is bound, and the name should indicate something about that. Also, about the implementation: > +static int > +snd_usb_offload_create_mixer(struct usb_mixer_interface *mixer, > + const struct snd_kcontrol_new *new_kctl) > +{ > + struct snd_kcontrol *kctl; > + struct usb_mixer_elem_info *elem; > + > + elem = kzalloc(sizeof(struct usb_mixer_elem_info), GFP_KERNEL); > + if (!elem) > + return -ENOMEM; > + > + elem->head.mixer = mixer; > + elem->val_type = USB_MIXER_S32; > + elem->control = 0; > + elem->head.id = 0; > + elem->channels = 1; > + > + kctl = snd_ctl_new1(new_kctl, elem); > + if (!kctl) { > + kfree(elem); > + return -ENOMEM; > + } > + kctl->private_free = snd_usb_mixer_elem_free; > + > + return snd_usb_mixer_add_control(&elem->head, kctl); This control has almost little to do with the standard USB interface, and it'll be much simpler if you create a raw control element. Pass the bus or the sysdev to private_data, and that's all you need in the get callback. Also, don't forget to set the proper access bits (it's read-only). thanks, Takashi
On Mon, 05 Feb 2024 10:01:03 +0100, Amadeusz Sławiński wrote: > > On 2/3/2024 3:36 AM, Wesley Cheng wrote: > > In case of notifying SND platform drivers of connection events, some of > > these use cases, such as offloading, require an ASoC USB backend device to > > be initialized before the events can be handled. If the USB backend device > > has not yet been probed, this leads to missing initial USB audio device > > connection events. > > > > Expose an API that traverses the usb_chip array for connected devices, and > > to call the respective connection callback registered to the SND platform > > driver. > > > > Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> > > --- > > sound/usb/card.c | 19 +++++++++++++++++++ > > sound/usb/card.h | 2 ++ > > sound/usb/qcom/qc_audio_offload.c | 2 ++ > > 3 files changed, 23 insertions(+) > > > > diff --git a/sound/usb/card.c b/sound/usb/card.c > > index 11b827b7a2a5..995b2df676ab 100644 > > --- a/sound/usb/card.c > > +++ b/sound/usb/card.c > > @@ -202,6 +202,25 @@ struct snd_usb_stream *snd_usb_find_suppported_substream(int card_idx, > > } > > EXPORT_SYMBOL_GPL(snd_usb_find_suppported_substream); > > +/* > > + * in case the platform driver was not ready at the time of USB SND > > + * device connect, expose an API to discover all connected USB devices > > + * so it can populate any dependent resources/structures. > > + */ > > +void snd_usb_rediscover_devices(void) > > +{ > > + int i; > > + > > + mutex_lock(®ister_mutex); > > + for (i = 0; i < SNDRV_CARDS; i++) { > > + if (usb_chip[i]) > > + if (platform_ops && platform_ops->connect_cb) > > + platform_ops->connect_cb(usb_chip[i]); > > if inside if, it can just be && or maybe move callback check before > mutex lock and just return early if it is not present? The callback check must be inside mutex; otherwise you'll get a race about the platform_ops registration. thanks, Takashi
On Sat, 03 Feb 2024 03:36:27 +0100, Wesley Cheng wrote: > > With USB audio offloading, an audio session is started from the ASoC > platform sound card and PCM devices. Likewise, the USB SND path is still > readily available for use, in case the non-offload path is desired. In > order to prevent the two entities from attempting to use the USB bus, > introduce a flag that determines when either paths are in use. > > If a PCM device is already in use, the check will return an error to > userspace notifying that the stream is currently busy. This ensures that > only one path is using the USB substream. > > Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Hm, I'm not sure whether it's safe to hold chip->mutex there for the long code path. It even kicks off the auto-resume, which may call various functions at resuming, and some of them may re-hold chip->mutex. If it's only about the open flag, protect only the flag access with the mutex, not covering the all open function. At least the re-entry can be avoided by that. thanks, Takashi > --- > sound/usb/card.h | 1 + > sound/usb/pcm.c | 19 +++++++++++++++++-- > 2 files changed, 18 insertions(+), 2 deletions(-) > > diff --git a/sound/usb/card.h b/sound/usb/card.h > index ed4a664e24e5..6d59995440c3 100644 > --- a/sound/usb/card.h > +++ b/sound/usb/card.h > @@ -165,6 +165,7 @@ struct snd_usb_substream { > unsigned int pkt_offset_adj; /* Bytes to drop from beginning of packets (for non-compliant devices) */ > unsigned int stream_offset_adj; /* Bytes to drop from beginning of stream (for non-compliant devices) */ > > + unsigned int opened:1; /* pcm device opened */ > unsigned int running: 1; /* running status */ > unsigned int period_elapsed_pending; /* delay period handling */ > > diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c > index 3adb09ce1702..c2cb52cd5d23 100644 > --- a/sound/usb/pcm.c > +++ b/sound/usb/pcm.c > @@ -1241,8 +1241,15 @@ static int snd_usb_pcm_open(struct snd_pcm_substream *substream) > struct snd_usb_stream *as = snd_pcm_substream_chip(substream); > struct snd_pcm_runtime *runtime = substream->runtime; > struct snd_usb_substream *subs = &as->substream[direction]; > + struct snd_usb_audio *chip = subs->stream->chip; > int ret; > > + mutex_lock(&chip->mutex); > + if (subs->opened) { > + mutex_unlock(&chip->mutex); > + return -EBUSY; > + } > + > runtime->hw = snd_usb_hardware; > /* need an explicit sync to catch applptr update in low-latency mode */ > if (direction == SNDRV_PCM_STREAM_PLAYBACK && > @@ -1259,13 +1266,17 @@ static int snd_usb_pcm_open(struct snd_pcm_substream *substream) > > ret = setup_hw_info(runtime, subs); > if (ret < 0) > - return ret; > + goto out; > ret = snd_usb_autoresume(subs->stream->chip); > if (ret < 0) > - return ret; > + goto out; > ret = snd_media_stream_init(subs, as->pcm, direction); > if (ret < 0) > snd_usb_autosuspend(subs->stream->chip); > + subs->opened = 1; > +out: > + mutex_unlock(&chip->mutex); > + > return ret; > } > > @@ -1274,6 +1285,7 @@ static int snd_usb_pcm_close(struct snd_pcm_substream *substream) > int direction = substream->stream; > struct snd_usb_stream *as = snd_pcm_substream_chip(substream); > struct snd_usb_substream *subs = &as->substream[direction]; > + struct snd_usb_audio *chip = subs->stream->chip; > int ret; > > snd_media_stop_pipeline(subs); > @@ -1287,6 +1299,9 @@ static int snd_usb_pcm_close(struct snd_pcm_substream *substream) > > subs->pcm_substream = NULL; > snd_usb_autosuspend(subs->stream->chip); > + mutex_lock(&chip->mutex); > + subs->opened = 0; > + mutex_unlock(&chip->mutex); > > return 0; > }
On Sat, 03 Feb 2024 03:36:24 +0100, Wesley Cheng wrote: > > Allow for checks on a specific USB audio device to see if a requested PCM > format is supported. This is needed for support when playback is > initiated by the ASoC USB backend path. > > Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Just cosmetic: > +struct snd_usb_stream *snd_usb_find_suppported_substream(int card_idx, > + struct snd_pcm_hw_params *params, int direction) > +{ > + struct snd_usb_audio *chip; > + struct snd_usb_substream *subs; > + struct snd_usb_stream *as; > + const struct audioformat *fmt; > + > + /* > + * Register mutex is held when populating and clearing usb_chip > + * array. > + */ > + mutex_lock(®ister_mutex); > + chip = usb_chip[card_idx]; > + if (!chip) { > + mutex_unlock(®ister_mutex); > + return NULL; > + } > + > + if (enable[card_idx]) { > + list_for_each_entry(as, &chip->pcm_list, list) { > + subs = &as->substream[direction]; > + fmt = snd_usb_find_substream_format(subs, params); > + if (fmt) { > + mutex_unlock(®ister_mutex); > + return as; > + } > + } > + } > + mutex_unlock(®ister_mutex); I prefer having the single lock/unlock call pair, e.g. struct snd_usb_stream *as, *ret; ret = NULL; mutex_lock(®ister_mutex); chip = usb_chip[card_idx]; if (chip && enable[card_idx]) { list_for_each_entry(as, &chip->pcm_list, list) { subs = &as->substream[direction]; if (snd_usb_find_substream_format(subs, params)) { ret = as; break; } } } mutex_unlock(®ister_mutex); return ret; } In this case, we shouldn't reuse "as" for the return value since it can be non-NULL after the loop end. thanks, Takashi
On Tue, Feb 06, 2024 at 02:12:44PM +0100, Takashi Iwai wrote: > On Sat, 03 Feb 2024 03:36:24 +0100, > Wesley Cheng wrote: > > > > Allow for checks on a specific USB audio device to see if a requested PCM > > format is supported. This is needed for support when playback is > > initiated by the ASoC USB backend path. > > > > Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> > > Just cosmetic: > > > +struct snd_usb_stream *snd_usb_find_suppported_substream(int card_idx, > > + struct snd_pcm_hw_params *params, int direction) > > +{ > > + struct snd_usb_audio *chip; > > + struct snd_usb_substream *subs; > > + struct snd_usb_stream *as; > > + const struct audioformat *fmt; > > + > > + /* > > + * Register mutex is held when populating and clearing usb_chip > > + * array. > > + */ > > + mutex_lock(®ister_mutex); > > + chip = usb_chip[card_idx]; > > + if (!chip) { > > + mutex_unlock(®ister_mutex); > > + return NULL; > > + } > > + > > + if (enable[card_idx]) { > > + list_for_each_entry(as, &chip->pcm_list, list) { > > + subs = &as->substream[direction]; > > + fmt = snd_usb_find_substream_format(subs, params); > > + if (fmt) { > > + mutex_unlock(®ister_mutex); > > + return as; > > + } > > + } > > + } > > + mutex_unlock(®ister_mutex); > > I prefer having the single lock/unlock call pair, e.g. > > struct snd_usb_stream *as, *ret; > > ret = NULL; > mutex_lock(®ister_mutex); > chip = usb_chip[card_idx]; > if (chip && enable[card_idx]) { > list_for_each_entry(as, &chip->pcm_list, list) { > subs = &as->substream[direction]; > if (snd_usb_find_substream_format(subs, params)) { > ret = as; > break; > } > } > } > mutex_unlock(®ister_mutex); > return ret; > } > > In this case, we shouldn't reuse "as" for the return value since it > can be non-NULL after the loop end. Why not just use guard(mutex) for this, making it all not an issue? thanks, greg k-h
On Tue, 06 Feb 2024 15:50:21 +0100, Greg KH wrote: > > On Tue, Feb 06, 2024 at 02:12:44PM +0100, Takashi Iwai wrote: > > On Sat, 03 Feb 2024 03:36:24 +0100, > > Wesley Cheng wrote: > > > > > > Allow for checks on a specific USB audio device to see if a requested PCM > > > format is supported. This is needed for support when playback is > > > initiated by the ASoC USB backend path. > > > > > > Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> > > > > Just cosmetic: > > > > > +struct snd_usb_stream *snd_usb_find_suppported_substream(int card_idx, > > > + struct snd_pcm_hw_params *params, int direction) > > > +{ > > > + struct snd_usb_audio *chip; > > > + struct snd_usb_substream *subs; > > > + struct snd_usb_stream *as; > > > + const struct audioformat *fmt; > > > + > > > + /* > > > + * Register mutex is held when populating and clearing usb_chip > > > + * array. > > > + */ > > > + mutex_lock(®ister_mutex); > > > + chip = usb_chip[card_idx]; > > > + if (!chip) { > > > + mutex_unlock(®ister_mutex); > > > + return NULL; > > > + } > > > + > > > + if (enable[card_idx]) { > > > + list_for_each_entry(as, &chip->pcm_list, list) { > > > + subs = &as->substream[direction]; > > > + fmt = snd_usb_find_substream_format(subs, params); > > > + if (fmt) { > > > + mutex_unlock(®ister_mutex); > > > + return as; > > > + } > > > + } > > > + } > > > + mutex_unlock(®ister_mutex); > > > > I prefer having the single lock/unlock call pair, e.g. > > > > struct snd_usb_stream *as, *ret; > > > > ret = NULL; > > mutex_lock(®ister_mutex); > > chip = usb_chip[card_idx]; > > if (chip && enable[card_idx]) { > > list_for_each_entry(as, &chip->pcm_list, list) { > > subs = &as->substream[direction]; > > if (snd_usb_find_substream_format(subs, params)) { > > ret = as; > > break; > > } > > } > > } > > mutex_unlock(®ister_mutex); > > return ret; > > } > > > > In this case, we shouldn't reuse "as" for the return value since it > > can be non-NULL after the loop end. > > Why not just use guard(mutex) for this, making it all not an issue? Heh, it's too new ;) That should work gracefully, yes. Takashi
Hi Takashi, On 2/6/2024 5:07 AM, Takashi Iwai wrote: > On Sat, 03 Feb 2024 03:36:27 +0100, > Wesley Cheng wrote: >> >> With USB audio offloading, an audio session is started from the ASoC >> platform sound card and PCM devices. Likewise, the USB SND path is still >> readily available for use, in case the non-offload path is desired. In >> order to prevent the two entities from attempting to use the USB bus, >> introduce a flag that determines when either paths are in use. >> >> If a PCM device is already in use, the check will return an error to >> userspace notifying that the stream is currently busy. This ensures that >> only one path is using the USB substream. >> >> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> > > Hm, I'm not sure whether it's safe to hold chip->mutex there for the > long code path. It even kicks off the auto-resume, which may call > various functions at resuming, and some of them may re-hold > chip->mutex. > That's a good point. > If it's only about the open flag, protect only the flag access with > the mutex, not covering the all open function. At least the re-entry > can be avoided by that. > Sure, let me re-order the check/assignment and the mutex locking. Since this is now checked here in USB PCM and the QC offload driver, we want to make sure that if there was some application attempting to open both at the same time, we prevent any possible races. I think the best way to address this would be something like: static int snd_usb_pcm_open(struct snd_pcm_substream *substream) { ... mutex_lock(&chip->mutex); if (subs->opened) { mutex_unlock(&chip->mutex); return -EBUSY; } subs->opened = 1; mutex_unlock(&chip->mutex); //Execute bulk of PCM open routine ... return 0; // If any errors are seen, unwind err_resume: snd_usb_autosuspend(subs->stream->chip); err_open: mutex_lock(&chip->mutex); subs->opened = 0; mutex_unlock(&chip->mutex); return ret; } Set the opened flag first, so that if QC offload checks it, it can exit early and vice versa. Otherwise, if we set the opened flag at the same position as the previous patch, we may be calling the other routines in parallel to the QC offload enable stream routine. The only thing with this patch is that we'd need some error handling unwinding. Thanks Wesley Cheng
Hi Takashi, On 2/6/2024 5:12 AM, Takashi Iwai wrote: > On Sat, 03 Feb 2024 03:36:24 +0100, > Wesley Cheng wrote: >> >> Allow for checks on a specific USB audio device to see if a requested PCM >> format is supported. This is needed for support when playback is >> initiated by the ASoC USB backend path. >> >> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> > > Just cosmetic: > >> +struct snd_usb_stream *snd_usb_find_suppported_substream(int card_idx, >> + struct snd_pcm_hw_params *params, int direction) >> +{ >> + struct snd_usb_audio *chip; >> + struct snd_usb_substream *subs; >> + struct snd_usb_stream *as; >> + const struct audioformat *fmt; >> + >> + /* >> + * Register mutex is held when populating and clearing usb_chip >> + * array. >> + */ >> + mutex_lock(®ister_mutex); >> + chip = usb_chip[card_idx]; >> + if (!chip) { >> + mutex_unlock(®ister_mutex); >> + return NULL; >> + } >> + >> + if (enable[card_idx]) { >> + list_for_each_entry(as, &chip->pcm_list, list) { >> + subs = &as->substream[direction]; >> + fmt = snd_usb_find_substream_format(subs, params); >> + if (fmt) { >> + mutex_unlock(®ister_mutex); >> + return as; >> + } >> + } >> + } >> + mutex_unlock(®ister_mutex); > > I prefer having the single lock/unlock call pair, e.g. > > struct snd_usb_stream *as, *ret; > > ret = NULL; > mutex_lock(®ister_mutex); > chip = usb_chip[card_idx]; > if (chip && enable[card_idx]) { > list_for_each_entry(as, &chip->pcm_list, list) { > subs = &as->substream[direction]; > if (snd_usb_find_substream_format(subs, params)) { > ret = as; > break; > } > } > } > mutex_unlock(®ister_mutex); > return ret; > } > > In this case, we shouldn't reuse "as" for the return value since it > can be non-NULL after the loop end. > > Sure will do, thanks for taking a look. Thanks Wesley Cheng
Hi Takashi, On 2/6/2024 4:57 AM, Takashi Iwai wrote: > On Sat, 03 Feb 2024 03:36:40 +0100, > Wesley Cheng wrote: >> >> In order to allow userspace/applications know about USB offloading status, >> expose a sound kcontrol that fetches information about which sound card >> index is associated with the ASoC platform card supporting offloading. In >> the USB audio offloading framework, the ASoC BE DAI link is the entity >> responsible for registering to the SOC USB layer. SOC USB will expose more >> details about the current offloading status, which includes the USB sound >> card and USB PCM device indexes currently being used. >> >> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> > > The concept is understandable, but the control element name ("SNDUSB > OFFLD playback available") looks non-intrusive and non-conformant. > Use a bit more understandable name instead. > > This provides a card number where the offload driver is bound, and the > name should indicate something about that. > Hmmm, does USB sound have a naming convention that it usually follows for mixer/control interfaces? For something that is more closely related, how about: "USB offload capable card" > Also, about the implementation: > >> +static int >> +snd_usb_offload_create_mixer(struct usb_mixer_interface *mixer, >> + const struct snd_kcontrol_new *new_kctl) >> +{ >> + struct snd_kcontrol *kctl; >> + struct usb_mixer_elem_info *elem; >> + >> + elem = kzalloc(sizeof(struct usb_mixer_elem_info), GFP_KERNEL); >> + if (!elem) >> + return -ENOMEM; >> + >> + elem->head.mixer = mixer; >> + elem->val_type = USB_MIXER_S32; >> + elem->control = 0; >> + elem->head.id = 0; >> + elem->channels = 1; >> + >> + kctl = snd_ctl_new1(new_kctl, elem); >> + if (!kctl) { >> + kfree(elem); >> + return -ENOMEM; >> + } >> + kctl->private_free = snd_usb_mixer_elem_free; >> + >> + return snd_usb_mixer_add_control(&elem->head, kctl); > > This control has almost little to do with the standard USB interface, > and it'll be much simpler if you create a raw control element. > Pass the bus or the sysdev to private_data, and that's all you need in > the get callback. > Sure, I'll remove the need to register over the SND USB mixer API, and just use the core SND control APIs. > Also, don't forget to set the proper access bits (it's read-only). > Thanks for pointing this out, will fix. Thanks Wesley Cheng > > thanks, > > Takashi
On Wed, 07 Feb 2024 02:24:46 +0100, Wesley Cheng wrote: > > Hi Takashi, > > On 2/6/2024 4:57 AM, Takashi Iwai wrote: > > On Sat, 03 Feb 2024 03:36:40 +0100, > > Wesley Cheng wrote: > >> > >> In order to allow userspace/applications know about USB offloading status, > >> expose a sound kcontrol that fetches information about which sound card > >> index is associated with the ASoC platform card supporting offloading. In > >> the USB audio offloading framework, the ASoC BE DAI link is the entity > >> responsible for registering to the SOC USB layer. SOC USB will expose more > >> details about the current offloading status, which includes the USB sound > >> card and USB PCM device indexes currently being used. > >> > >> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> > > > > The concept is understandable, but the control element name ("SNDUSB > > OFFLD playback available") looks non-intrusive and non-conformant. > > Use a bit more understandable name instead. > > > > This provides a card number where the offload driver is bound, and the > > name should indicate something about that. > > > > Hmmm, does USB sound have a naming convention that it usually follows > for mixer/control interfaces? The old rule is found in Documentation/sound/designs/control-names.rst (although the prefix and the suffix are often dropped for non-standard controls). > For something that is more closely related, how about: > "USB offload capable card" Yes, it looks better. But usually each word begins with an upper letter. Takashi
On Wed, 07 Feb 2024 01:08:00 +0100, Wesley Cheng wrote: > > Hi Takashi, > > On 2/6/2024 5:07 AM, Takashi Iwai wrote: > > On Sat, 03 Feb 2024 03:36:27 +0100, > > Wesley Cheng wrote: > >> > >> With USB audio offloading, an audio session is started from the ASoC > >> platform sound card and PCM devices. Likewise, the USB SND path is still > >> readily available for use, in case the non-offload path is desired. In > >> order to prevent the two entities from attempting to use the USB bus, > >> introduce a flag that determines when either paths are in use. > >> > >> If a PCM device is already in use, the check will return an error to > >> userspace notifying that the stream is currently busy. This ensures that > >> only one path is using the USB substream. > >> > >> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> > > > > Hm, I'm not sure whether it's safe to hold chip->mutex there for the > > long code path. It even kicks off the auto-resume, which may call > > various functions at resuming, and some of them may re-hold > > chip->mutex. > > > > That's a good point. > > > If it's only about the open flag, protect only the flag access with > > the mutex, not covering the all open function. At least the re-entry > > can be avoided by that. > > > > Sure, let me re-order the check/assignment and the mutex locking. > Since this is now checked here in USB PCM and the QC offload driver, > we want to make sure that if there was some application attempting to > open both at the same time, we prevent any possible races. > > I think the best way to address this would be something like: > > static int snd_usb_pcm_open(struct snd_pcm_substream *substream) > { > ... > mutex_lock(&chip->mutex); > if (subs->opened) { > mutex_unlock(&chip->mutex); > return -EBUSY; > } > subs->opened = 1; > mutex_unlock(&chip->mutex); > > //Execute bulk of PCM open routine > ... > return 0; > > // If any errors are seen, unwind > err_resume: > snd_usb_autosuspend(subs->stream->chip); > err_open: > mutex_lock(&chip->mutex); > subs->opened = 0; > mutex_unlock(&chip->mutex); > > return ret; > } > > Set the opened flag first, so that if QC offload checks it, it can > exit early and vice versa. Otherwise, if we set the opened flag at > the same position as the previous patch, we may be calling the other > routines in parallel to the QC offload enable stream routine. The > only thing with this patch is that we'd need some error handling > unwinding. The above is what I had in mind. But, thinking on this again, you might be able to get the same result by using the ALSA PCM core substream open_mutex and hw_opened flag. This is already held and set at snd_pcm_core() (the hw_opened flag is set after open callback, though). The offload driver can use those instead of the own lock and flag, too, although it's not really well-mannered behavior (hence you need proper comments). thanks, Takashi
Hi Takashi, On 2/6/2024 11:05 PM, Takashi Iwai wrote: > On Wed, 07 Feb 2024 01:08:00 +0100, > Wesley Cheng wrote: >> >> Hi Takashi, >> >> On 2/6/2024 5:07 AM, Takashi Iwai wrote: >>> On Sat, 03 Feb 2024 03:36:27 +0100, >>> Wesley Cheng wrote: >>>> >>>> With USB audio offloading, an audio session is started from the ASoC >>>> platform sound card and PCM devices. Likewise, the USB SND path is still >>>> readily available for use, in case the non-offload path is desired. In >>>> order to prevent the two entities from attempting to use the USB bus, >>>> introduce a flag that determines when either paths are in use. >>>> >>>> If a PCM device is already in use, the check will return an error to >>>> userspace notifying that the stream is currently busy. This ensures that >>>> only one path is using the USB substream. >>>> >>>> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> >>> >>> Hm, I'm not sure whether it's safe to hold chip->mutex there for the >>> long code path. It even kicks off the auto-resume, which may call >>> various functions at resuming, and some of them may re-hold >>> chip->mutex. >>> >> >> That's a good point. >> >>> If it's only about the open flag, protect only the flag access with >>> the mutex, not covering the all open function. At least the re-entry >>> can be avoided by that. >>> >> >> Sure, let me re-order the check/assignment and the mutex locking. >> Since this is now checked here in USB PCM and the QC offload driver, >> we want to make sure that if there was some application attempting to >> open both at the same time, we prevent any possible races. >> >> I think the best way to address this would be something like: >> >> static int snd_usb_pcm_open(struct snd_pcm_substream *substream) >> { >> ... >> mutex_lock(&chip->mutex); >> if (subs->opened) { >> mutex_unlock(&chip->mutex); >> return -EBUSY; >> } >> subs->opened = 1; >> mutex_unlock(&chip->mutex); >> >> //Execute bulk of PCM open routine >> ... >> return 0; >> >> // If any errors are seen, unwind >> err_resume: >> snd_usb_autosuspend(subs->stream->chip); >> err_open: >> mutex_lock(&chip->mutex); >> subs->opened = 0; >> mutex_unlock(&chip->mutex); >> >> return ret; >> } >> >> Set the opened flag first, so that if QC offload checks it, it can >> exit early and vice versa. Otherwise, if we set the opened flag at >> the same position as the previous patch, we may be calling the other >> routines in parallel to the QC offload enable stream routine. The >> only thing with this patch is that we'd need some error handling >> unwinding. > > The above is what I had in mind. > > But, thinking on this again, you might be able to get the same result > by using the ALSA PCM core substream open_mutex and hw_opened flag. > This is already held and set at snd_pcm_core() (the hw_opened flag is > set after open callback, though). The offload driver can use those > instead of the own lock and flag, too, although it's not really > well-mannered behavior (hence you need proper comments). > I think I had looked into this as well previously, and it was difficult to achieve, because from the USB offloading perspective, we don't ever call: snd_usb_pcm_open() This is actually where we populate the pcm_substream parameter within struct snd_usb_substream based on when userspace opens the USB SND PCM device (which is not the case for offloading). So the offload driver doesn't have a way to fetch the struct snd_pcm that is allocated to the PCM device created by the USB SND card. Thanks Wesley Cheng
On 2/6/2024 6:53 AM, Takashi Iwai wrote: > On Tue, 06 Feb 2024 15:50:21 +0100, > Greg KH wrote: >> >> On Tue, Feb 06, 2024 at 02:12:44PM +0100, Takashi Iwai wrote: >>> On Sat, 03 Feb 2024 03:36:24 +0100, >>> Wesley Cheng wrote: >>>> >>>> Allow for checks on a specific USB audio device to see if a requested PCM >>>> format is supported. This is needed for support when playback is >>>> initiated by the ASoC USB backend path. >>>> >>>> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> >>> >>> Just cosmetic: >>> >>>> +struct snd_usb_stream *snd_usb_find_suppported_substream(int card_idx, >>>> + struct snd_pcm_hw_params *params, int direction) >>>> +{ >>>> + struct snd_usb_audio *chip; >>>> + struct snd_usb_substream *subs; >>>> + struct snd_usb_stream *as; >>>> + const struct audioformat *fmt; >>>> + >>>> + /* >>>> + * Register mutex is held when populating and clearing usb_chip >>>> + * array. >>>> + */ >>>> + mutex_lock(®ister_mutex); >>>> + chip = usb_chip[card_idx]; >>>> + if (!chip) { >>>> + mutex_unlock(®ister_mutex); >>>> + return NULL; >>>> + } >>>> + >>>> + if (enable[card_idx]) { >>>> + list_for_each_entry(as, &chip->pcm_list, list) { >>>> + subs = &as->substream[direction]; >>>> + fmt = snd_usb_find_substream_format(subs, params); >>>> + if (fmt) { >>>> + mutex_unlock(®ister_mutex); >>>> + return as; >>>> + } >>>> + } >>>> + } >>>> + mutex_unlock(®ister_mutex); >>> >>> I prefer having the single lock/unlock call pair, e.g. >>> >>> struct snd_usb_stream *as, *ret; >>> >>> ret = NULL; >>> mutex_lock(®ister_mutex); >>> chip = usb_chip[card_idx]; >>> if (chip && enable[card_idx]) { >>> list_for_each_entry(as, &chip->pcm_list, list) { >>> subs = &as->substream[direction]; >>> if (snd_usb_find_substream_format(subs, params)) { >>> ret = as; >>> break; >>> } >>> } >>> } >>> mutex_unlock(®ister_mutex); >>> return ret; >>> } >>> >>> In this case, we shouldn't reuse "as" for the return value since it >>> can be non-NULL after the loop end. >> >> Why not just use guard(mutex) for this, making it all not an issue? > > Heh, it's too new ;) > That should work gracefully, yes. > Thanks Greg/Takashi. That is nifty. Thanks Wesley Cheng
Hi Takashi, On 2/7/2024 4:02 PM, Wesley Cheng wrote: > Hi Takashi, > > On 2/6/2024 11:05 PM, Takashi Iwai wrote: >> On Wed, 07 Feb 2024 01:08:00 +0100, >> Wesley Cheng wrote: >>> >>> Hi Takashi, >>> >>> On 2/6/2024 5:07 AM, Takashi Iwai wrote: >>>> On Sat, 03 Feb 2024 03:36:27 +0100, >>>> Wesley Cheng wrote: >>>>> >>>>> With USB audio offloading, an audio session is started from the ASoC >>>>> platform sound card and PCM devices. Likewise, the USB SND path is >>>>> still >>>>> readily available for use, in case the non-offload path is >>>>> desired. In >>>>> order to prevent the two entities from attempting to use the USB bus, >>>>> introduce a flag that determines when either paths are in use. >>>>> >>>>> If a PCM device is already in use, the check will return an error to >>>>> userspace notifying that the stream is currently busy. This >>>>> ensures that >>>>> only one path is using the USB substream. >>>>> >>>>> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> >>>> >>>> Hm, I'm not sure whether it's safe to hold chip->mutex there for the >>>> long code path. It even kicks off the auto-resume, which may call >>>> various functions at resuming, and some of them may re-hold >>>> chip->mutex. >>>> >>> >>> That's a good point. >>> >>>> If it's only about the open flag, protect only the flag access with >>>> the mutex, not covering the all open function. At least the re-entry >>>> can be avoided by that. >>>> >>> >>> Sure, let me re-order the check/assignment and the mutex locking. >>> Since this is now checked here in USB PCM and the QC offload driver, >>> we want to make sure that if there was some application attempting to >>> open both at the same time, we prevent any possible races. >>> >>> I think the best way to address this would be something like: >>> >>> static int snd_usb_pcm_open(struct snd_pcm_substream *substream) >>> { >>> ... >>> mutex_lock(&chip->mutex); >>> if (subs->opened) { >>> mutex_unlock(&chip->mutex); >>> return -EBUSY; >>> } >>> subs->opened = 1; >>> mutex_unlock(&chip->mutex); >>> >>> //Execute bulk of PCM open routine >>> ... >>> return 0; >>> >>> // If any errors are seen, unwind >>> err_resume: >>> snd_usb_autosuspend(subs->stream->chip); >>> err_open: >>> mutex_lock(&chip->mutex); >>> subs->opened = 0; >>> mutex_unlock(&chip->mutex); >>> >>> return ret; >>> } >>> >>> Set the opened flag first, so that if QC offload checks it, it can >>> exit early and vice versa. Otherwise, if we set the opened flag at >>> the same position as the previous patch, we may be calling the other >>> routines in parallel to the QC offload enable stream routine. The >>> only thing with this patch is that we'd need some error handling >>> unwinding. >> >> The above is what I had in mind. >> >> But, thinking on this again, you might be able to get the same result >> by using the ALSA PCM core substream open_mutex and hw_opened flag. >> This is already held and set at snd_pcm_core() (the hw_opened flag is >> set after open callback, though). The offload driver can use those >> instead of the own lock and flag, too, although it's not really >> well-mannered behavior (hence you need proper comments). >> > > I think I had looked into this as well previously, and it was difficult > to achieve, because from the USB offloading perspective, we don't ever > call: snd_usb_pcm_open() > > This is actually where we populate the pcm_substream parameter within > struct snd_usb_substream based on when userspace opens the USB SND PCM > device (which is not the case for offloading). So the offload driver > doesn't have a way to fetch the struct snd_pcm that is allocated to the > PCM device created by the USB SND card. > Sorry, took a look at it again, and found a way. Although not pretty, we can access it using: subs->stream->pcm->streams[direction].substream->hw_opened Thanks Wesley Cheng
On Thu, 08 Feb 2024 02:12:00 +0100, Wesley Cheng wrote: > > Hi Takashi, > > On 2/7/2024 4:02 PM, Wesley Cheng wrote: > > Hi Takashi, > > > > On 2/6/2024 11:05 PM, Takashi Iwai wrote: > >> On Wed, 07 Feb 2024 01:08:00 +0100, > >> Wesley Cheng wrote: > >>> > >>> Hi Takashi, > >>> > >>> On 2/6/2024 5:07 AM, Takashi Iwai wrote: > >>>> On Sat, 03 Feb 2024 03:36:27 +0100, > >>>> Wesley Cheng wrote: > >>>>> > >>>>> With USB audio offloading, an audio session is started from the ASoC > >>>>> platform sound card and PCM devices. Likewise, the USB SND path > >>>>> is still > >>>>> readily available for use, in case the non-offload path is > >>>>> desired. In > >>>>> order to prevent the two entities from attempting to use the USB bus, > >>>>> introduce a flag that determines when either paths are in use. > >>>>> > >>>>> If a PCM device is already in use, the check will return an error to > >>>>> userspace notifying that the stream is currently busy. This > >>>>> ensures that > >>>>> only one path is using the USB substream. > >>>>> > >>>>> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> > >>>> > >>>> Hm, I'm not sure whether it's safe to hold chip->mutex there for the > >>>> long code path. It even kicks off the auto-resume, which may call > >>>> various functions at resuming, and some of them may re-hold > >>>> chip->mutex. > >>>> > >>> > >>> That's a good point. > >>> > >>>> If it's only about the open flag, protect only the flag access with > >>>> the mutex, not covering the all open function. At least the re-entry > >>>> can be avoided by that. > >>>> > >>> > >>> Sure, let me re-order the check/assignment and the mutex locking. > >>> Since this is now checked here in USB PCM and the QC offload driver, > >>> we want to make sure that if there was some application attempting to > >>> open both at the same time, we prevent any possible races. > >>> > >>> I think the best way to address this would be something like: > >>> > >>> static int snd_usb_pcm_open(struct snd_pcm_substream *substream) > >>> { > >>> ... > >>> mutex_lock(&chip->mutex); > >>> if (subs->opened) { > >>> mutex_unlock(&chip->mutex); > >>> return -EBUSY; > >>> } > >>> subs->opened = 1; > >>> mutex_unlock(&chip->mutex); > >>> > >>> //Execute bulk of PCM open routine > >>> ... > >>> return 0; > >>> > >>> // If any errors are seen, unwind > >>> err_resume: > >>> snd_usb_autosuspend(subs->stream->chip); > >>> err_open: > >>> mutex_lock(&chip->mutex); > >>> subs->opened = 0; > >>> mutex_unlock(&chip->mutex); > >>> > >>> return ret; > >>> } > >>> > >>> Set the opened flag first, so that if QC offload checks it, it can > >>> exit early and vice versa. Otherwise, if we set the opened flag at > >>> the same position as the previous patch, we may be calling the other > >>> routines in parallel to the QC offload enable stream routine. The > >>> only thing with this patch is that we'd need some error handling > >>> unwinding. > >> > >> The above is what I had in mind. > >> > >> But, thinking on this again, you might be able to get the same result > >> by using the ALSA PCM core substream open_mutex and hw_opened flag. > >> This is already held and set at snd_pcm_core() (the hw_opened flag is > >> set after open callback, though). The offload driver can use those > >> instead of the own lock and flag, too, although it's not really > >> well-mannered behavior (hence you need proper comments). > >> > > > > I think I had looked into this as well previously, and it was > > difficult to achieve, because from the USB offloading perspective, > > we don't ever call: snd_usb_pcm_open() > > > > This is actually where we populate the pcm_substream parameter > > within struct snd_usb_substream based on when userspace opens the > > USB SND PCM device (which is not the case for offloading). So the > > offload driver doesn't have a way to fetch the struct snd_pcm that > > is allocated to the PCM device created by the USB SND card. > > > > Sorry, took a look at it again, and found a way. Although not pretty, > we can access it using: > subs->stream->pcm->streams[direction].substream->hw_opened Yes, it's not easy to follow it. So if we want to this path, worth for a detailed comment. That said, I don't mind to introduce the new local mutex and flag as you did if the above became too messy in the end. thanks, Takashi
Hi Takashi, On 2/8/2024 12:33 AM, Takashi Iwai wrote: > On Thu, 08 Feb 2024 02:12:00 +0100, > Wesley Cheng wrote: >> >> Hi Takashi, >> >> On 2/7/2024 4:02 PM, Wesley Cheng wrote: >>> Hi Takashi, >>> >>> On 2/6/2024 11:05 PM, Takashi Iwai wrote: >>>> On Wed, 07 Feb 2024 01:08:00 +0100, >>>> Wesley Cheng wrote: >>>>> >>>>> Hi Takashi, >>>>> >>>>> On 2/6/2024 5:07 AM, Takashi Iwai wrote: >>>>>> On Sat, 03 Feb 2024 03:36:27 +0100, >>>>>> Wesley Cheng wrote: >>>>>>> >>>>>>> With USB audio offloading, an audio session is started from the ASoC >>>>>>> platform sound card and PCM devices. Likewise, the USB SND path >>>>>>> is still >>>>>>> readily available for use, in case the non-offload path is >>>>>>> desired. In >>>>>>> order to prevent the two entities from attempting to use the USB bus, >>>>>>> introduce a flag that determines when either paths are in use. >>>>>>> >>>>>>> If a PCM device is already in use, the check will return an error to >>>>>>> userspace notifying that the stream is currently busy. This >>>>>>> ensures that >>>>>>> only one path is using the USB substream. >>>>>>> >>>>>>> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> >>>>>> >>>>>> Hm, I'm not sure whether it's safe to hold chip->mutex there for the >>>>>> long code path. It even kicks off the auto-resume, which may call >>>>>> various functions at resuming, and some of them may re-hold >>>>>> chip->mutex. >>>>>> >>>>> >>>>> That's a good point. >>>>> >>>>>> If it's only about the open flag, protect only the flag access with >>>>>> the mutex, not covering the all open function. At least the re-entry >>>>>> can be avoided by that. >>>>>> >>>>> >>>>> Sure, let me re-order the check/assignment and the mutex locking. >>>>> Since this is now checked here in USB PCM and the QC offload driver, >>>>> we want to make sure that if there was some application attempting to >>>>> open both at the same time, we prevent any possible races. >>>>> >>>>> I think the best way to address this would be something like: >>>>> >>>>> static int snd_usb_pcm_open(struct snd_pcm_substream *substream) >>>>> { >>>>> ... >>>>> mutex_lock(&chip->mutex); >>>>> if (subs->opened) { >>>>> mutex_unlock(&chip->mutex); >>>>> return -EBUSY; >>>>> } >>>>> subs->opened = 1; >>>>> mutex_unlock(&chip->mutex); >>>>> >>>>> //Execute bulk of PCM open routine >>>>> ... >>>>> return 0; >>>>> >>>>> // If any errors are seen, unwind >>>>> err_resume: >>>>> snd_usb_autosuspend(subs->stream->chip); >>>>> err_open: >>>>> mutex_lock(&chip->mutex); >>>>> subs->opened = 0; >>>>> mutex_unlock(&chip->mutex); >>>>> >>>>> return ret; >>>>> } >>>>> >>>>> Set the opened flag first, so that if QC offload checks it, it can >>>>> exit early and vice versa. Otherwise, if we set the opened flag at >>>>> the same position as the previous patch, we may be calling the other >>>>> routines in parallel to the QC offload enable stream routine. The >>>>> only thing with this patch is that we'd need some error handling >>>>> unwinding. >>>> >>>> The above is what I had in mind. >>>> >>>> But, thinking on this again, you might be able to get the same result >>>> by using the ALSA PCM core substream open_mutex and hw_opened flag. >>>> This is already held and set at snd_pcm_core() (the hw_opened flag is >>>> set after open callback, though). The offload driver can use those >>>> instead of the own lock and flag, too, although it's not really >>>> well-mannered behavior (hence you need proper comments). >>>> >>> >>> I think I had looked into this as well previously, and it was >>> difficult to achieve, because from the USB offloading perspective, >>> we don't ever call: snd_usb_pcm_open() >>> >>> This is actually where we populate the pcm_substream parameter >>> within struct snd_usb_substream based on when userspace opens the >>> USB SND PCM device (which is not the case for offloading). So the >>> offload driver doesn't have a way to fetch the struct snd_pcm that >>> is allocated to the PCM device created by the USB SND card. >>> >> >> Sorry, took a look at it again, and found a way. Although not pretty, >> we can access it using: >> subs->stream->pcm->streams[direction].substream->hw_opened > > Yes, it's not easy to follow it. So if we want to this path, worth > for a detailed comment. That said, I don't mind to introduce the new > local mutex and flag as you did if the above became too messy in the > end. > If you don't mind, I prefer to keep it the way it was with the local mutex and flag. It makes it a lot easier to follow, and for other users to adopt as well compared to the long equation above :). Thanks Wesley Cheng
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 USB | ASoC -------------------------------------------------------------------- | _________________________ | |sm8250 platform card | | |_________________________| | | | | ___V____ ____V____ | |Q6USB | |Q6AFE | | |"codec" | |"cpu" | | |________| |_________| | ^ ^ ^ | | |________| | ___V____ | | |SOC-USB | | ________ ________ | | | |USB SND |<--->|QC offld|<------------>|________| | |(card.c)| | |<---------- | |________| |________|___ | | | ^ ^ | | | ____________V_________ | | | | | |APR/GLINK | __ V_______________V_____ | | | |______________________| |USB SND (endpoint.c) | | | | ^ |_________________________| | | | | ^ | | | ___________V___________ | | | |->|audio DSP | ___________V_____________ | | |_______________________| |XHCI HCD |<- | |_________________________| | Adding ASoC binding layer: soc-usb: Intention is to treat a USB port similar to a headphone jack. 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 Changelog -------------------------------------------- Changes in v13: - Pulled in secondary/primary interrupter rework from Mathias from: https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/drivers/usb/host?h=fix_eventhandling - Did some cleanup and commit message updates, and tested on current code base. - Added mutex locking to xhci sideband to help prevent any race conditions, esp. for when accessing shared references. - Addresed concerns from Hillf about gfp_flags and locking used in qc_usb_audio_offload. - Rebased onto usb-next Changes in v12: - Updated copyright year to 2024. Happy new years! - Fixed newline format on mixer offload driver. Changes in v11: - Modified QMI format structures to be const Changes in v10: - Added new mixer for exposing kcontrol for sound card created by USB SND. This allows for applications to know which platform sound card has offload support. Will return the card number. - Broke down and cleaned up some functions/APIs within qc_audio_offload driver. - Exported xhci_initialize_ring_info(), and modified XHCI makefile to allow for the XHCI sideband to exist as a module. - Reworked the jack registration and moved it to the QCOM platform card driver, ie sm8250. - Added an SOC USB API to fetch a standard component tag that can be appended to the platform sound card. Added this tag to sm8250 if any USB path exists within the DT node. - Moved kcontrols that existed in the Q6USB driver, and made it a bit more generic, so that naming can be standardized across solutions. SOC USB is now responsible for creation of these kcontrols. - Added a SOC USB RST document explaining some code flows and implementation details so that other vendors can utilize the framework. - Addressed a case where USB device connection events are lost if usb offload driver (qc_audio_offload) is not probed when everything else has been initialized, ie USB SND, SOC USB and ASoC sound card. Add a rediscover device call during module init, to ensure that connection events will be propagated. - Rebased to usb-next. Changes in v9: - Fixed the dt binding check issue with regards to num-hc-interrupters. Changes in v8: - Cleaned up snd_soc_usb_find_priv_data() based on Mark's feedback. Removed some of the duplicate looping code that was present on previous patches. Also renamed the API. - Integrated Mathias' suggestions on his new sideband changes: https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters - Addressed some of Mathias' fixme tags, such as: - Resetting transfer ring dequeue/enqueue pointers - Issuing stop endpoint command during ep removal - Reset ERDP properly to first segment ring during interrupter removal. (this is currently just being cleared to 0, but should be pointing to a valid segment if controller is still running. Changes in v7: - Fixed dt check error for q6usb bindings - Updated q6usb property from qcom,usb-audio-intr-num --> qcom,usb-audio-intr-idx - Removed separate DWC3 HC interrupters num property, and place limits to XHCI one. - Modified xhci_ring_to_sgtable() to use assigned IOVA/DMA address to fetch pages, as it is not ensured event ring allocated is always done in the vmalloc range. Changes in v6: - Fixed limits and description on several DT bindings (XHCI and Q6USB) - Fixed patch subjects to follow other ALSA/ASoC notations. USB SND - Addressed devices which expose multiple audio (UAC) interfaces. These devices will create a single USB sound card with multiple audio streams, and receive multiple interface probe routines. QC offload was not properly considering cases with multiple probe calls. - Renamed offload module name and kconfig to fit within the SND domain. - Renamed attach/detach endpoint API to keep the hw_params notation. Changes in v5: - Removed some unnescessary files that were included - Fixed some typos mentioned - Addressed dt-binding issues and added hc-interrupters definition to usb-xhci.yaml XHCI: - Moved secondary skip events API to xhci-ring and updated implementation - Utilized existing XHCI APIs, such as inc_deq and xhci_update_erst_dequeue() USB SND - Renamed and reworked the APIs in "sound: usb: Export USB SND APIs for modules" patch to include suggestions to utilize snd_usb_hw_params/free and to avoid generic naming. - Added a resume_cb() op for completion sake. - Addressed some locking concerns with regards to when registering for platform hooks. - Added routine to disconnect all offloaded devices during module unbind. ASoC - Replaced individual PCM parameter arguments in snd_soc_usb_connect() with new snd_soc_usb_device structure to pass along PCM info. - Modified snd_jack set report to notify HEADPHONE event, as we do not support record path. Changes in v4: - Rebased to xhci/for-usb-next - Addressed some dt-bindings comments XHCI: - Pulled in latest changes from Mathias' feature_interrupters branch: https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters - Fixed commit text and signage for the XHCI sideband/interrupter related changes - Added some logic to address the FIXME tags mentioned throughout the commits, such as handling multi segment rings and building the SGT, locking concerns, and ep cleanup operations. - Removed some fixme tags for conditions that may not be needed/addressed. - Repurposed the new endpoint stop sync API to be utilized in other places. - Fixed potential compile issue if XHCI sideband config is not defined. ASoC: - Added sound jack control into the Q6USB driver. Allows for userpsace to know when an offload capable device is connected. USB SND: - Avoided exporting _snd_pcm_hw_param_set based on Takashi's recommendation. - Split USB QMI packet header definitions into a separate commit. This is used to properly allow the QMI interface driver to parse and route QMI packets accordingly - Added a "depends on" entry when enabling QC audio offload to avoid compile time issues. 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. Mathias Nyman (13): xhci: fix possible null pointer dereference at secondary interrupter removal xhci: fix off by one check when adding a secondary interrupter. xhci: Add interrupt pending autoclear flag to each interrupter xhci: Add helper to set an interrupters interrupt moderation interval xhci: make isoc_bei_interval variable interrupter specific. xhci: remove unnecessary event_ring_deq parameter from xhci_handle_event() xhci: update event ring dequeue pointer position to controller correctly xhci: move event processing for one interrupter to a separate function xhci: add helper that checks for unhandled events on a event ring xhci: Don't check if the event ring is valid before every event TRB xhci: Decouple handling an event from checking for unhandled events xhci: add helper to stop endpoint and wait for completion xhci: sideband: add initial api to register a sideband entity Wesley Cheng (40): usb: host: xhci: Export enable and disable interrupter APIs usb: host: xhci: Repurpose event handler for skipping interrupter events xhci: export XHCI IMOD setting helper for interrupters usb: host: xhci-sideband: Expose a sideband interrupter enable API usb: host: xhci-mem: Cleanup pending secondary event ring events usb: host: xhci-mem: Allow for interrupter clients to choose specific index 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: qdsp6: Add USB backend ASoC driver for Q6 ALSA: usb-audio: Introduce USB SND platform op callbacks ALSA: usb-audio: Export USB SND APIs for modules ALSA: usb-audio: Save UAC sample size information usb: dwc3: Specify maximum number of XHCI interrupters usb: host: xhci-plat: Set XHCI max interrupters if property is present ALSA: usb-audio: qcom: Add USB QMI definitions ALSA: usb-audio: qcom: Introduce QC USB SND offloading support ALSA: usb-audio: Check for support for requested audio format ASoC: usb: Add PCM format check API for USB backend ASoC: qcom: qdsp6: Ensure PCM format is supported by USB audio device ALSA: usb-audio: Prevent starting of audio stream if in use ALSA: usb-audio: Do not allow USB offload path if PCM device is in use ASoC: dt-bindings: Add Q6USB backend ASoC: dt-bindings: Update example for enabling USB offload on SM8250 ALSA: usb-audio: qcom: Populate PCM and USB chip information ASoC: qcom: qdsp6: Add support to track available USB PCM devices ASoC: Introduce SND kcontrols to select sound card and PCM device ASoC: qcom: qdsp6: Add SOC USB offload select get/put callbacks ASoC: Add SND kcontrol for fetching USB offload status ASoC: qcom: qdsp6: Add PCM ops to track current state ASoC: usb: Create SOC USB SND jack kcontrol ASoC: qcom: qdsp6: Add headphone jack for offload connection status ASoC: usb: Fetch ASoC sound card information ALSA: usb-audio: mixer: Add USB offloading mixer control ALSA: usb-audio: qcom: Use card and PCM index from QMI request ALSA: usb-audio: Allow for rediscovery of connected USB SND devices ASoC: usb: Rediscover USB SND devices on USB port add ASoC: qcom: Populate SoC components string ASoC: doc: Add documentation for SOC USB .../devicetree/bindings/sound/qcom,q6usb.yaml | 55 + .../bindings/sound/qcom,sm8250.yaml | 15 + Documentation/sound/soc/index.rst | 1 + Documentation/sound/soc/usb.rst | 611 ++++++ drivers/usb/dwc3/core.c | 12 + drivers/usb/dwc3/core.h | 2 + drivers/usb/dwc3/host.c | 5 +- drivers/usb/host/Kconfig | 9 + drivers/usb/host/Makefile | 2 + drivers/usb/host/xhci-mem.c | 53 +- drivers/usb/host/xhci-plat.c | 2 + drivers/usb/host/xhci-ring.c | 240 ++- drivers/usb/host/xhci-sideband.c | 439 ++++ drivers/usb/host/xhci.c | 97 +- drivers/usb/host/xhci.h | 21 +- .../sound/qcom,q6dsp-lpass-ports.h | 1 + include/linux/usb/xhci-sideband.h | 70 + include/sound/q6usboffload.h | 20 + include/sound/soc-usb.h | 90 + sound/soc/Makefile | 2 +- sound/soc/qcom/Kconfig | 4 + sound/soc/qcom/common.c | 41 + sound/soc/qcom/common.h | 4 +- sound/soc/qcom/qdsp6/Makefile | 1 + sound/soc/qcom/qdsp6/q6afe-dai.c | 60 + sound/soc/qcom/qdsp6/q6afe.c | 193 +- sound/soc/qcom/qdsp6/q6afe.h | 36 +- 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 | 401 ++++ sound/soc/qcom/sm8250.c | 14 +- sound/soc/soc-usb.c | 538 +++++ sound/usb/Kconfig | 19 + sound/usb/Makefile | 3 +- sound/usb/card.c | 123 ++ sound/usb/card.h | 24 + sound/usb/endpoint.c | 1 + sound/usb/format.c | 1 + sound/usb/helper.c | 1 + sound/usb/mixer.c | 5 + sound/usb/mixer_usb_offload.c | 82 + sound/usb/mixer_usb_offload.h | 17 + sound/usb/pcm.c | 94 +- sound/usb/pcm.h | 11 + sound/usb/qcom/Makefile | 2 + sound/usb/qcom/qc_audio_offload.c | 1910 +++++++++++++++++ sound/usb/qcom/usb_audio_qmi_v01.c | 892 ++++++++ sound/usb/qcom/usb_audio_qmi_v01.h | 162 ++ 49 files changed, 6243 insertions(+), 176 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/qcom,q6usb.yaml create mode 100644 Documentation/sound/soc/usb.rst create mode 100644 drivers/usb/host/xhci-sideband.c create mode 100644 include/linux/usb/xhci-sideband.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/mixer_usb_offload.c create mode 100644 sound/usb/mixer_usb_offload.h 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