Re: [PATCH] ASoC: dapm: Add support for multi register mux

[Takashi Iwai <tiwai@suse.de>]

At Mon, 07 Apr 2014 14:54:11 +0200,
Lars-Peter Clausen wrote:
> 
> On 04/05/2014 02:12 AM, Arun Shamanna Lakshmi wrote:
> > 1. Modify soc_enum struct to handle pointers for reg and mask
> > 2. Add dapm get and put APIs for multi register one hot encoded mux
> > 3. Update snd_soc_dapm_update struct to support multiple reg update
> >
> > Signed-off-by: Arun S L <aruns@nvidia.com>
> > Signed-off-by: Songhee Baek <sbaek@nvidia.com>
> 
> Looks good to me, so:
> 
> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
> 
> 
> As Takashi said it is not that nice that there is a bit of code churn by 
> having to update all the existing users of e->reg and e->mask. But 
> implementing this properly seems to cause even more code churn.

Well, I'm not sure about it.  It's already too late for 3.15, so we
have some time to enhance for this feature properly.

I personally like a hackish solution, too, but only if it really gives
a clear benefit over the generic solution.  In this case, it changes
the data type and yet increases the data size significantly, which
isn't a good sign.  (Note that replacing int with pointer can be twice
on 64bit, and there will be pads for alignment, in addition to the
extra space for number instances by this implementation.)

Also, as the data handling is branched per type, a more readable
implementation would be to impose a union between normal and onehot
types in soc_enum struct, I guess.  But, then a question comes to the
point whether we really want such a unification at all.

Last but not least, another concern is that there can be multiple
onehot types: with 0 or without 0 handling.  It'd be easy to add the
implementation, but it indicates that the implementation isn't generic
enough in comparison with the existing snd_soc code for single
register.

> And I think 
> it will be done best in an effort to consolidate the kcontrol helpers and 
> the DAPM kcontrol helpers by adding an additional layer of abstraction 
> between the kcontrols and the hardware access that translates between the 
> logical value and the physical value(s).
> 
> E.g. something like
> 
> struct kcontrol_ops {
> 	int (*read)(...);
> 	int (*write)(...);
> };
> 
> And then have one kind of ops for each kind of control type and at the high 
> level only have put and get handlers for enums and for switches/volumes.

This might work well, indeed.  But, let the actual code talk :)


thanks,

Takashi