From: Lars-Peter Clausen <lars@metafoo.de>
To: Mark Brown <broonie@kernel.org>
Cc: Arun Shamanna Lakshmi <aruns@nvidia.com>,
Songhee Baek <sbaek@nvidia.com>,
"'alsa-devel@alsa-project.org'" <alsa-devel@alsa-project.org>,
"'swarren@wwwdotorg.org'" <swarren@wwwdotorg.org>,
"'tiwai@suse.de'" <tiwai@suse.de>,
"'lgirdwood@gmail.com'" <lgirdwood@gmail.com>,
"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [alsa-devel] [PATCH] ASoC: Add support for multi register mux
Date: Mon, 31 Mar 2014 13:55:52 +0200 [thread overview]
Message-ID: <533957C8.2030105@metafoo.de> (raw)
In-Reply-To: <20140331112140.GO2269@sirena.org.uk>
On 03/31/2014 01:21 PM, Mark Brown wrote:
> On Sat, Mar 29, 2014 at 11:12:30PM -0700, Arun Shamanna Lakshmi wrote:
>
> Fix your mailer to word wrap within paragraphs, your mails are
> excessively hard to read.
>
>>> I'm not sure I understand how that MUX_OFFSET would work. To get the
>>> selected mux output you can use the ffs instruction.
>
>>> foreach(reg) {
>>> reg_val = read(reg) & mask;
>>> if (reg_val != 0) {
>>> val = __ffs(reg_val);
>>> break;
>>> }
>>> }
>
>> There are 2 options to do this. The first option is what you specified
>> above, in which case I think we cannot share get and put functions as
>> they use the reg_val directly inside snd_soc_enum_val_to_item API (not
>> the bit position being set). If we change to bit position like above,
>> then the current users of these APIs should also change their soc_enum
>> value table. And, the second option being the one that we proposed.
>
> Sharing the functions isn't the goal, coming up with a usable API is.
>
>> That being said, MUX_OFFSET which is the second option works in the
>> following way. We know that reg_val is a power of 2 (2^0 to 2^31)
>> which is one hot code. This method adds a unique offset for this
>> reg_val for each incremental register that we want to set (say 2^n +
>> MUX_OFFSET(reg_id)) inside get function and does the reverse of it in
>> put function. For current users of only one register, it doesn't
>> change anything as we use reg_val.
>
> I'm afraid I can't understand the above at all, sorry. The code below
> is quoted like Lars wrote it but I think it's actually written by you,
> please check your quoting when replying:\
>
>>> if (e->reg[0] != SND_SOC_NOPM) {
>>> for (reg_idx = 0; reg_idx < e->num_regs; reg_idx++) {
>>> reg_val = snd_soc_read(codec, e->reg[reg_idx]);
>>> val = (reg_val >> e->shift_l) & e->mask[reg_idx];
>>> if (val) {
>>> val += MULTI_MUX_INPUT_OFFSET(reg_idx);
>>> break;
>>> }
>>> }
>>> } else {
>>> reg_val = dapm_kcontrol_get_value(kcontrol);
>>> val = (reg_val >> e->shift_l) & e->mask[0];
>>> }
>
> The above is a bit confusing... partly this is because of a lack of
> context (what is MULTI_MUX_INPUT_OFFSET?) and partly because it isn't
> entirely obvious that stopping as soon as we see any value set is the
> right choice, especially given the addition to rather than setting of
> val.
I think the idea is that since we know that for one-hot encodings only
powers of two are valid values the other bits are used to encode the
register number. E.g 0x4 means bit 3 in register 0, 0x5 means bit 3 in
register 1, 0x6 means bit 3 in register 2 and so on. I guess it is possible
to make it work. But this seems to be quite hack-ish to me. You'd have to be
careful that MULTI_MUX_INPUT_OFFSET(reg_idx) never evaluates to a power of
two and there are probably some more pitfalls.
- Lars
next prev parent reply other threads:[~2014-03-31 11:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-26 0:02 [PATCH] ASoC: Add support for multi register mux Arun Shamanna Lakshmi
2014-03-26 19:38 ` [alsa-devel] " Lars-Peter Clausen
2014-03-26 22:41 ` Songhee Baek
2014-03-27 9:19 ` Lars-Peter Clausen
2014-03-27 18:24 ` [alsa-devel] " Songhee Baek
[not found] ` <5571431004A69147BCABABE4E097D66BA3EFF70CFC@HQMAIL02.nvidia.com>
2014-03-28 18:10 ` Songhee Baek
2014-03-29 2:30 ` [alsa-devel] " Songhee Baek
2014-03-29 10:53 ` Lars-Peter Clausen
2014-03-30 6:12 ` Arun Shamanna Lakshmi
2014-03-31 11:21 ` Mark Brown
2014-03-31 11:55 ` Lars-Peter Clausen [this message]
2014-03-31 12:07 ` Mark Brown
2014-04-01 6:08 ` [alsa-devel] " Arun Shamanna Lakshmi
2014-03-27 1:08 ` Mark Brown
2014-03-27 4:33 ` Songhee Baek
2014-03-27 1:29 ` Mark Brown
-- strict thread matches above, loose matches on Subject: below --
2014-03-18 23:51 Arun Shamanna Lakshmi
2014-03-18 23:59 ` Mark Brown
2014-03-19 23:44 ` Arun Shamanna Lakshmi
2014-03-20 11:48 ` Mark Brown
2014-03-20 18:20 ` Stephen Warren
2014-03-20 18:36 ` Mark Brown
2014-03-20 19:05 ` [alsa-devel] " Lars-Peter Clausen
2014-03-20 19:40 ` Lars-Peter Clausen
2014-03-21 11:37 ` [alsa-devel] " Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=533957C8.2030105@metafoo.de \
--to=lars@metafoo.de \
--cc=alsa-devel@alsa-project.org \
--cc=aruns@nvidia.com \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sbaek@nvidia.com \
--cc=swarren@wwwdotorg.org \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox