ASoC: qcom: qdsp6: Fetch USB offload mapped card and PCM device
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@quicinc.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20250409194804.3773260-27-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>