At Mon, 07 Apr 2014 14:54:11 +0200, Lars-Peter Clausen wrote:
On 04/05/2014 02:12 AM, Arun Shamanna Lakshmi wrote:
- Modify soc_enum struct to handle pointers for reg and mask
- Add dapm get and put APIs for multi register one hot encoded mux
- 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