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

[Kristoffer KARLSSON]

I believe that the assumption that all the registers are contiguous would pose a
troublesome limitation in this case.
We do have several controls that exposes signed 15-bit values that are mapped
across two 8-bit registers (16-bits in total) in a big-endian order.
While for those particular controls a contiguous (big endian) order like you
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.

I originally considered to put in two more parameters to consolidate the four
macros to one, one being no of registers and one specifying big- or
little-endian order. But as you can see unfortunately neither little or big
endian contiguous order would suffice in the case described above so therefore I
opted to give the user full control in specifying the registers and what order
they should map to the composite value when using the macro allowing for every
possible combination which seems to be the most generic approach allowing for
different formats.

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.
Actually in our driver we only need S1R, S2R and S4R. I added the S8R variant
just to provide a complete implementation covering up to the full 64 bit
(8*8-bit). So until we need to deal with 128-bit computers and someone would
need this exact type of composite control in 128-bit then I believe these four
macros should suffice for most cases.

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?


On 2012-03-13 22:39, Mark Brown wrote:

> On Tue, Mar 13, 2012 at 04:11:28PM +0100, Ola Lilja wrote:
> 
>> SOC_SINGLE_VALUE_S1R  One control value spans one register
>> SOC_SINGLE_VALUE_S2R  One control value spans two registers
>> SOC_SINGLE_VALUE_S4R  One control value spans four registers
>> SOC_SINGLE_VALUE_S8R  One control value spans eight registers
> 
> This is fairly painful; the number of registers really ought to be
> parameterised rather than having to add a new crop of macros every time
> there's a new format or a new count.  Can we possibly make the
> simplifying assumption that all the registers are contiguous?



-- 


*Kristoffer Karlsson*

Multimedia Platform Customization Lund

*ST-Ericsson*
Product Group Mobile Platforms

Scheelevägen 19B
223 63, Lund
Sweden
www.stericsson.com <http://www.stericsson.com/>
	Office: +46 46 10 3938
Mobile: +46 72 206 5192
Fax: +46 10 715 89 88
Email: kristoffer.karlsson at stericsson.com
<mailto:kristoffer.karlsson at stericsson.com>


This communication is confidential and intended solely for the addressee(s). Any
unauthorized review, use, disclosure or distribution is prohibited. If you
believe this message has been sent to you in error, please notify the sender by
replying to this transmission and delete the message without disclosing it.
Thank you.

E-mail including attachments is susceptible to data corruption, interception,
unauthorized amendment, tampering and viruses, and we only send and receive
emails on the basis that we are not liable for any such corruption,
interception, amendment, tampering or viruses or any consequences thereof.