Hi Takashi,
On 2/13/2024 2:54 AM, Takashi Iwai wrote:
On Tue, 13 Feb 2024 01:54:11 +0100,
Wesley Cheng wrote:
+static int soc_usb_get_offload_dev(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_component *component = snd_kcontrol_chip(kcontrol);
+ struct snd_soc_usb *ctx = snd_soc_usb_find_priv_data(component->dev);
+ int ret = 0;
+
+ mutex_lock(&ctx_mutex);
+ if (ctx && ctx->get_offload_dev)
+ ret = ctx->get_offload_dev(kcontrol, ucontrol);
+ mutex_unlock(&ctx_mutex);
It might be safer to initialize the values with -1 in case when the
callback isn't available?
Make sense, will do.
/**
* snd_soc_usb_get_components_tag() - Retrieve SOC USB component tag
* @playback: direction of audio stream
@@ -157,6 +218,12 @@ EXPORT_SYMBOL_GPL(snd_soc_usb_free_port);
*/
int snd_soc_usb_add_port(struct snd_soc_usb *usb)
{
+ int ret;
+
+ ret = snd_soc_usb_control_init(usb->component);
+ if (ret < 0)
+ return ret;
+
mutex_lock(&ctx_mutex);
list_add_tail(&usb->list, &usb_ctx_list);
mutex_unlock(&ctx_mutex);
We may need to remove the control element upon the driver removal,
too? In theory, you can unload the offload stuff while snd-usb-audio
is still active.
This is managing the control for the ASoC platform card that supports
offloading. If we compile the different kernel entities as modules, we
see that the soc_usb layer has the following users:
soc_usb 16384 3 q6usb,snd_usb_audio_qmi,snd_soc_qcom_offload_utils
So we'd need to remove all these modules before we can unload soc_usb.
The entity which would be related to the kcontrols created for the ASoC
sound card would be the q6usb module. Since the q6usb module is tightly
coupled with the platform soundcard itself in our design, for the q6usb
module to be removed, we have to remove the entire ASoC sound card. (in
which the kcontrols will also be removed)
However, that might not always be the case...so its a good idea to just
manually remove the kcontrols in soc-usb as you guided.
Thanks
Wesley Cheng
