All of lore.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2014-03-31 11:55 UTC|newest]

Thread overview: 24+ 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  0:02 ` 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  9:19       ` [alsa-devel] " Lars-Peter Clausen
2014-03-27 18:24       ` Songhee Baek
     [not found]       ` <5571431004A69147BCABABE4E097D66BA3EFF70CFC@HQMAIL02.nvidia.com>
2014-03-28 18:10         ` Songhee Baek
2014-03-28 18:10           ` [alsa-devel] " Songhee Baek
2014-03-29  2:30         ` 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-03-31 12:07                     ` [alsa-devel] " Mark Brown
2014-04-01  6:08                     ` Arun Shamanna Lakshmi
2014-03-27  1:08   ` Mark Brown
2014-03-27  4:33     ` Songhee Baek
2014-03-27  1:29 ` Mark Brown
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               ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.