[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140403160254.GV14763@sirena.org.uk>
Date: Thu, 3 Apr 2014 17:02:54 +0100
From: Mark Brown <broonie@...nel.org>
To: Takashi Iwai <tiwai@...e.de>
Cc: Lars-Peter Clausen <lars@...afoo.de>,
Arun Shamanna Lakshmi <aruns@...dia.com>,
lgirdwood@...il.com, swarren@...dotorg.org, perex@...ex.cz,
alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
Songhee Baek <sbaek@...dia.com>
Subject: Re: [PATCH] ASoC: dapm: Add support for multi register mux
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.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists