Messages in this thread | | | Date | Wed, 26 Jul 2023 16:06:41 -0700 | Subject | Re: [PATCH v4 27/32] sound: soc: qdsp6: Add SND kcontrol to select offload device | From | Wesley Cheng <> |
| |
Hi Pierre,
On 7/25/2023 2:16 AM, Pierre-Louis Bossart wrote: > > > On 7/25/23 04:34, Wesley Cheng wrote: >> Expose a kcontrol on the platform sound card, which will allow for >> userspace to determine which USB card number and PCM device to offload. >> This allows for userspace to potentially tag an alternate path for a >> specific USB SND card and PCM device. Previously, control was absent, and >> the offload path would be enabled on the last USB SND device which was >> connected. This logic will continue to be applicable if no mixer input is >> received for specific device selection. >> >> An example to configure the offload device using tinymix: >> tinymix -D 0 set 'Q6USB offload SND device select' 1 0 >> >> The above will set the Q6AFE device token to choose offload on card#1 and >> pcm#0. Device selection is made possible by setting the Q6AFE device >> token. The audio DSP utilizes this parameter, and will pass this field >> back to the USB offload driver within the QMI stream requests. > > I must be missing something... If you have a card 0 which exposes a > control to change what the card1 does, then it means you have a card0 > with a PCM device what can potentially be used concurrently with the > card1 exposing an offload device. > > Is there any sort of mutual exclusion to make sure the same USB endpoint > is not used twice? > > One would hope that when a device is opened the matching non-offloaded > one (or ones in the case of implicit feedback) is disabled or marked as > used? > > I would guess in your Android setup you have control on such behavior at > the HAL level, but in the more generic Linux use I don't see what > would orchestrate the use of two devices, and at the kernel level what > would prevent it. > Still going through the comments and trying to address the suggestions in the code, so will reply pack to those as I make the needed changes.
As for the above question, the following change was made with the intention to prevent the above scenario.
https://lore.kernel.org/linux-usb/20230725023416.11205-23-quic_wcheng@quicinc.com/
Thanks Wesley Cheng
| |