From: Lars-Peter Clausen <lars@metafoo.de>
To: Songhee Baek <sbaek@nvidia.com>
Cc: Arun Shamanna Lakshmi <aruns@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>,
"broonie@kernel.org" <broonie@kernel.org>
Subject: Re: [PATCH] ASoC: Add support for multi register mux
Date: Thu, 27 Mar 2014 10:19:54 +0100 [thread overview]
Message-ID: <5333ED3A.7040908@metafoo.de> (raw)
In-Reply-To: <D6C615D3E4730340AE82D5BD856631C0A26CB319B2@HQMAIL02.nvidia.com>
On 03/26/2014 11:41 PM, Songhee Baek wrote:
>> -----Original Message-----
>> From: Lars-Peter Clausen [mailto:lars@metafoo.de]
>> Sent: Wednesday, March 26, 2014 12:39 PM
>> To: Arun Shamanna Lakshmi
>> Cc: lgirdwood@gmail.com; broonie@kernel.org; swarren@wwwdotorg.org;
>> Songhee Baek; alsa-devel@alsa-project.org; tiwai@suse.de; linux-
>> kernel@vger.kernel.org
>> Subject: Re: [alsa-devel] [PATCH] ASoC: Add support for multi register mux
>>
>> On 03/26/2014 01:02 AM, Arun Shamanna Lakshmi wrote:
>>> If the mux uses 1 bit position per input, and requires to set one
>>> single bit at a time, then an N bit register can support up to N
>>> inputs. In more recent Tegra chips, we have at least greater than
>>> 64 inputs which requires at least 2 .reg fields in struct soc_enum.
>>>
>>> Signed-off-by: Arun Shamanna Lakshmi <aruns@nvidia.com>
>>> Signed-off-by: Songhee Baek <sbaek@nvidia.com>
>>
>> The way you describe this it seems to me that a value array for this kind of
>> mux would look like.
>>
>> 0x00000000, 0x00000000, 0x00000001
>> 0x00000000, 0x00000000, 0x00000002
>> 0x00000000, 0x00000000, 0x00000003
>> 0x00000000, 0x00000000, 0x00000004
>> 0x00000000, 0x00000000, 0x00000008
>> ...
>>
>> That seems to be extremely tedious. If the MUX uses a one hot encoding
>> how about storing the index of the bit in the values array and use (1 << value)
>> when writing the value to the register?
>
> If we store the index of the bit, the value will be duplicated for each registers inputs since register has 0 to 31bits to shift, then we need to decode the index to interpret value for which registers to set. If we need to interpret the decoded value of index, it is better to have custom put/get function in our driver, isn't it?
>
I'm not sure I understand. If you use (val / 32) to pick the register and
(val % 32) to pick the bit in the register this should work just fine. Maybe
I'm missing something. Do you have a real world code example of of the this
type of enum is used?
>>> - int reg;
>>> + int reg[SOC_ENUM_MAX_REGS];
>>> unsigned char shift_l;
>>> unsigned char shift_r;
>>> unsigned int items;
>>> - unsigned int mask;
>>> + unsigned int mask[SOC_ENUM_MAX_REGS];
>>
>> If you make mask and reg pointers instead of arrays this should be much
>> more flexible and not be limited to 3 registers.
>>
>
> To use pointers instead of arrays, it will be flexible but I need to update SOC_ENUM SINGLE/DOUBLE macros.
> It will changes a lot in current soc-core.c and soc-dapm.c.
In the existing macros you can do something like this:
...
.reg = &(unsigned int){(xreg)},
...
>
>>> const char * const *texts;
>>> const unsigned int *values;
>>> + unsigned int num_regs;
>>> };
>>>
>
next prev parent reply other threads:[~2014-03-27 9:19 UTC|newest]
Thread overview: 23+ 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 [this message]
2014-03-27 18:24 ` 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
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
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=5333ED3A.7040908@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