[alsa-devel] [PATCH v2 1/2] ASoC: export dapm_kcontrol_set/get_value functions

[Lars-Peter Clausen]

On 05/30/2014 08:09 AM, Vinod Koul wrote:
> On Thu, May 29, 2014 at 12:55:07PM +0200, Lars-Peter Clausen wrote:
>> On 05/29/2014 12:03 PM, Vinod Koul wrote:
>>> The DSPs like Intel ones use the DPCM to represent the DSP toplogy. So when DAPM
>>> triggers the widget, the DSP needs to know the kcontrol values and pass on to DSP
>>> firmware, so export these for driver use
>>>
>>
>> As I said I feel a bit uneasy about exporting these and I'd rather
>> much prefer to see this patch in context (i.e. in the same series as
>> its user).
> I am still working on that series. The core patches could have gone ahead so
> posted.
>
> Here is the code snippet that will come in subsequent series:
>
> int sst_mix_put(struct snd_kcontrol *kcontrol,
>          struct snd_ctl_elem_value *ucontrol)
> {
>          struct snd_soc_dapm_widget_list *wlist =
> 			dapm_kcontrol_get_wlist(kcontrol);
>          struct snd_soc_dapm_widget *widget = wlist->widgets[0];
>          struct soc_mixer_control *mc =
>                  (struct soc_mixer_control *)kcontrol->private_value;
>          struct sst_data *sst = snd_soc_platform_get_drvdata(widget->platform);
>          unsigned int mask = (1 << fls(mc->max)) - 1;
>          unsigned int val;
>          int connect;
>          struct snd_soc_dapm_update update;
>
>          val = sst_reg_write(sst, mc->reg, mc->shift, mc->max,
> 				ucontrol->value.integer.value[0]);
>          connect = !!val;
>
>          dapm_kcontrol_set_value(kcontrol, val);

This looks similar to what I discussed with Peter the other day. You do not 
really need to call dapm_kcontrol_set_value() for controls that are not a 
virtual control or a auto-muted control. Neither is probably the case here. 
The conclusion of our discussion also was to move the 
dapm_kcontrol_set_value() call into snd_soc_dapm_mixer_update_power(), in 
case it ever becomes mandatory for other types of controls as well, because 
this means that not every custom put callback has to call the function on 
it's own.

Btw. in this case I think you should just use the default DAPM kcontrol put 
callback. There doesn't seem to be anything special in here and with the 
DAPM componentization series the default handler is also able to handle 
platforms.

- Lars