Re: [PATCH v4 27/32] sound: soc: qdsp6: Add SND kcontrol to select offload device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx/

Thanks
Wesley Cheng



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux