Re: [PATCH v9 29/34] ASoC: qcom: qdsp6: Add SND kcontrol to select offload device

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

 



Hi Pierre,

On 10/17/2023 3:50 PM, Pierre-Louis Bossart wrote:


On 10/17/23 15:01, 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.

This still begs the question on how userspace would figure what the
card1 is and which endpoint is used when PCM0 is opened?


Assuming we have something maybe in the component string for card1, then maybe that will help in this case as you mentioned earlier. Again, I think my understanding of "endpoint" here is referring to the USB endpoint. However, that isn't normally how we should think about it. From the USB sound perspective, it would be the USB interface that is selected, and the USB endpoints that that interface descriptor includes (up to 2 usb eps).

Ideally userpace would not have to know anything about "Q6USB".
Presumably when other vendors expose their USB offload solution, we
would want a generic control name, no?


Hmm...initially I was keeping the sound kcontrol implementation based on a vendor specific approach. Although, it might be good to standardize it a bit. I could see if we can add this to within soc-usb so whenever we just create a soc usb device, it would also create and initialize the kcontrols as well?

Jaroslav should chime in on this one :-)


Signed-off-by: Wesley Cheng <quic_wcheng@xxxxxxxxxxx>
---
  sound/soc/qcom/qdsp6/q6usb.c | 125 ++++++++++++++++++++++++++++++++++-
  1 file changed, 122 insertions(+), 3 deletions(-)

diff --git a/sound/soc/qcom/qdsp6/q6usb.c b/sound/soc/qcom/qdsp6/q6usb.c
index d697cbe7f184..a95276b7d91d 100644
--- a/sound/soc/qcom/qdsp6/q6usb.c
+++ b/sound/soc/qcom/qdsp6/q6usb.c
@@ -14,6 +14,7 @@
  #include <linux/dma-map-ops.h>
#include <sound/pcm.h>
+#include <sound/control.h>
  #include <sound/soc.h>
  #include <sound/soc-usb.h>
  #include <sound/pcm_params.h>
@@ -35,9 +36,12 @@ struct q6usb_port_data {
  	struct q6afe_usb_cfg usb_cfg;
  	struct snd_soc_usb *usb;
  	struct q6usb_offload priv;
+	struct mutex mutex;

missing comment on what this protects. "mutex" is really a poor
choice/name if I am honest.

  	unsigned long available_card_slot;
  	struct q6usb_status status[SNDRV_CARDS];
-	int active_idx;
+	bool idx_valid;
+	int sel_card_idx;
+	int sel_pcm_idx;
  };

+/* Build a mixer control for a UAC connector control (jack-detect) */
+static void q6usb_connector_control_init(struct snd_soc_component *component)
+{
+	int ret;
+
+	ret = snd_ctl_add(component->card->snd_card,
+				snd_ctl_new1(&q6usb_offload_dev_ctrl, component));
+	if (ret < 0)
+		return;

that error handling does not seem terribly useful...


Based on your earlier comment, this might change :)

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