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

[Vinod Koul]

On Fri, May 30, 2014 at 09:22:07AM +0200, Lars-Peter Clausen wrote:
> 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.
Yes I agree that if this is the approach we take we can remove the code snippet
here, which would make sense IMO
>
> 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.
Not for this version sure, but future platforms of our need some custom stuff to
be done. I will try to minimize those ones and once your component work is
complete redo these bits. Would be too happy to remove if it works out that way,
which is not the case with today. So till then we need these bits and exporting
of the dapm_kcontrol_set_value()

-- 
~Vinod