Re: [PATCH 01/16] ASoC: core: Add multi reg control struct & macros

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1915 bytes --]

On Wed, Mar 21, 2012 at 01:07:47PM +0100, Kristoffer KARLSSON wrote:

*NEVER* top post...

> I believe that the assumption that all the registers are contiguous would pose a
> troublesome limitation in this case.

...it leads to people reading contextless things like this and having no
idea what you're talking about.

You should also fix your mailer to word wrap within 80 columns - note
how the quote above wraps.

> suggested would work just fine, we also have other controls with signed 32-bit
> values that span four 8-bit registers that mapped in the following manner:

> bits	31-24	23-16	15-8	7-0
> reg	0x59	0x5A	0x59	0x5A

> This means that to write one complete 32-bit value we would actually need to
> write to the same 8-bit registers twice.

This makes no sense - how do the vales "span four 8-bit registers" while
using only two register addresses?

> Also I believe that the definition S1R,S2R,S4R together with S8R might in fact
> already be a fairly complete set with no need to add some new crop of macros for
> this in future. Why? Well since the value handled by ASoC-framework when
> setting/reading a integer control is of type long (snd_ctl_elem_value) in
> combination with the fact that 1 byte being the smallest register size in
> framework means that in a 64-bit world this would translate to a maximum of
> eight registers mapping the composite value of that long value.

What happens when someone wants unsigned controls, or stereo controls,
or 24 bit registers or anything else?  There's way more things can vary
than just the word size.

> Anyhow in light of the situation above do you think we could stick to the
> submitted approach or do you have some other suggestion on how to define the
> signed 32-bit value control with registers mapped in the above described fashion?

No, sorry.  This stuff just all seems really painful to use, I'd at
least hope for more parameterisation.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]