Hi Pierre, On 8/30/2024 2:34 AM, Pierre-Louis Bossart wrote: > > On 8/29/24 21:40, Wesley Cheng wrote: >> The USB SND path may need to know how the USB offload path is routed, so >> that applications can open the proper sound card and PCM device. The >> implementation for the QC ASoC design has a "USB Mixer" kcontrol for each >> possible FE (Q6ASM) DAI, which can be utilized to know which front end link >> is enabled. >> >> When an application/userspace queries for the mapped offload devices, the >> logic will lookup the USB mixer status though the following path: >> >> MultiMedia* <-> MM_DL* <-> USB Mixer* >> >> The "USB Mixer" is a DAPM widget, and the q6routing entity will set the >> DAPM connect status accordingly if the USB mixer is enabled. If enabled, >> the Q6USB backend link can fetch the PCM device number from the FE DAI >> link (Multimedia*). With respects to the card number, that is >> straightforward, as the ASoC components have direct references to the ASoC >> platform sound card. >> >> An example output can be shown below: >> >> Number of controls: 9 >> name value >> Capture Channel Map 0, 0 (range 0->36) >> Playback Channel Map 0, 0 (range 0->36) >> Headset Capture Switch On >> Headset Capture Volume 1 (range 0->4) >> Sidetone Playback Switch On >> Sidetone Playback Volume 4096 (range 0->8192) >> Headset Playback Switch On >> Headset Playback Volume 20, 20 (range 0->24) >> USB Offload Playback Route PCM#0 0, 1 (range -1->255) >> >> The "USB Offload Playback Route PCM#*" kcontrol will signify the >> corresponding card and pcm device it is offload to. (card#0 pcm - device#1) >> If the USB SND device supports multiple audio interfaces, then it will >> contain several PCM streams, hence in those situations, it is expected >> that there will be multiple playback route kcontrols created. >> >> Signed-off-by: Wesley Cheng <quic_wcheng@xxxxxxxxxxx> >> --- >> sound/soc/qcom/qdsp6/q6usb.c | 104 +++++++++++++++++++++++++++++++++++ >> 1 file changed, 104 insertions(+) >> >> diff --git a/sound/soc/qcom/qdsp6/q6usb.c b/sound/soc/qcom/qdsp6/q6usb.c >> index 10337d70eb27..c2fc0dedf430 100644 >> --- a/sound/soc/qcom/qdsp6/q6usb.c >> +++ b/sound/soc/qcom/qdsp6/q6usb.c >> @@ -132,6 +132,109 @@ static int q6usb_audio_ports_of_xlate_dai_name(struct snd_soc_component *compone >> return ret; >> } >> >> +static int q6usb_get_pcm_id_from_widget(struct snd_soc_dapm_widget *w) >> +{ >> + struct snd_soc_pcm_runtime *rtd; >> + struct snd_soc_dai *dai; >> + >> + for_each_card_rtds(w->dapm->card, rtd) { >> + dai = snd_soc_rtd_to_cpu(rtd, 0); >> + /* >> + * Only look for playback widget. RTD number carries the assigned >> + * PCM index. >> + */ >> + if (dai->stream[0].widget == w) >> + return rtd->num; >> + } >> + >> + return -1; >> +} >> + >> +static int q6usb_usb_mixer_enabled(struct snd_soc_dapm_widget *w) >> +{ >> + struct snd_soc_dapm_path *p; >> + >> + /* Checks to ensure USB path is enabled/connected */ >> + snd_soc_dapm_widget_for_each_sink_path(w, p) >> + if (!strcmp(p->sink->name, "USB Mixer") && p->connect) >> + return 1; >> + >> + return 0; >> +} >> + >> +static int q6usb_get_pcm_id(struct snd_soc_component *component) >> +{ >> + struct snd_soc_dapm_widget *w; >> + struct snd_soc_dapm_path *p; >> + int pidx; >> + >> + /* >> + * Traverse widgets to find corresponding FE widget. The DAI links are >> + * built like the following: >> + * MultiMedia* <-> MM_DL* <-> USB Mixer* >> + */ >> + for_each_card_widgets(component->card, w) { >> + if (!strncmp(w->name, "MultiMedia", 10)) { >> + /* >> + * Look up all paths associated with the FE widget to see if >> + * the USB BE is enabled. The sink widget is responsible to >> + * link with the USB mixers. >> + */ >> + snd_soc_dapm_widget_for_each_sink_path(w, p) { >> + if (q6usb_usb_mixer_enabled(p->sink)) { >> + pidx = q6usb_get_pcm_id_from_widget(w); >> + return pidx; >> + } >> + } > Humm, there should be a note that the design assumes that the USB > offload path exposes a single PCM per endpoints - same as the > non-offloaded path. If the ASoC card has multiple PCMs for each > endpoint, possibly with different processing on each PCM, then the > mapping would fail. Sure I'll add a note within the comments on the above. > The other question is whether you need to walk in the DAPM graph, in > theory DPCM has helpers to find which FEs are connected to which BE. Hmm...Yes, I've tried to see if I could utilize some of the helpers that were present, but none of them was able to fetch the DAPM widget that was associated with the FE, hence why I had to implement the lookup that would work for our current design. Thanks Wesley Cheng