On Thu, Apr 03, 2014 at 05:06:28PM +0200, Takashi Iwai wrote:
Lars-Peter Clausen wrote:
It would be nice, but it also requires some slight restructuring. The issue we have right now is that there is strictly speaking a bit of a layering violation. The DAPM widgets should not need to know how the kcontrols that are attached to the widget do their IO. What we essentially do in dapm_connect_mux() (and also dapm_connect_mixer) is an open-coded version of the controls get handler. Replacing that by calling the get handler instead should allow us to use different structs for enums and onehot enums.
Right, that's because DAPM has always just reimplemented everything and the virtual controls were grafted on the side of the existing register stuff rather than adding an abstraction layer.
So, something like below? It's totally untested, just a proof of concept.
Yes, that looks sensible to me but I didn't test it yet either.
If the performance matters, we can optimize it by checking kcontrol->get == snd_soc_dapm_get_enum_double or kcontrol->get == snd_soc_dapm_get_volsw and bypass to the current open-code functions instead of the generic get/put callers.
Performance isn't that big a deal, probably avoiding the alloc/frees by just keeping one around somewhere convenient would be useful too.