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?