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
