[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140321113751.GK11706@sirena.org.uk>
Date: Fri, 21 Mar 2014 11:37:51 +0000
From: Mark Brown <broonie@...nel.org>
To: Lars-Peter Clausen <lars@...afoo.de>
Cc: Songhee Baek <sbaek@...dia.com>,
Arun Shamanna Lakshmi <aruns@...dia.com>,
"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
Stephen Warren <swarren@...dotorg.org>,
"tiwai@...e.de" <tiwai@...e.de>,
"lgirdwood@...il.com" <lgirdwood@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [alsa-devel] [PATCH] ASoC: Add support for multi register mux
On Thu, Mar 20, 2014 at 08:40:54PM +0100, Lars-Peter Clausen wrote:
> On 03/20/2014 08:05 PM, Lars-Peter Clausen wrote:
> >It might make sense to add special code for supported muxes with a one-hot
> >encoding instead of using a value mux. Having an large array where each
> >entry is just 1<<n is a bit ugly in my opinion, especially if the value
> >needs to be able to be larger than 2**64. But anyway the patch that modifies
> >the soc_enum struct should also add the code that makes use of the new
> >struct layout.
> On the other hand this can actually already be implemented without any core
> changes by using a virtual mux and connecting a supply widget to each input
> which sets the bit for that input. DAPM will take care that only one of the
> supply widgets is enabled at a time.
Yes, each works - either way I think we can probably come up with some
helpers in the header which hide the actual implementation from the
drivers or at least makes it obvious that this is the way to do things.
The supply widgets approach wouldn't need any changes in the core but
then generalising the two register code isn't a bad thing anyway.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists