[alsa-devel] soc.h macros
Can you help me document these macros?
For example what does TLV stand for? I know it supplies a decibel range. R really mean two registers. What does EXT do? How about S8?
#define SOC_SINGLE(xname, reg, shift, max, invert) #define SOC_SINGLE_TLV(xname, reg, shift, max, invert, tlv_array) #define SOC_DOUBLE(xname, xreg, shift_left, shift_right, xmax, xinvert) #define SOC_DOUBLE_R(xname, reg_left, reg_right, xshift, xmax, xinvert) #define SOC_DOUBLE_TLV(xname, xreg, shift_left, shift_right, xmax, xinvert, tlv_array) #define SOC_DOUBLE_R_TLV(xname, reg_left, reg_right, xshift, xmax, xinvert, tlv_array) #define SOC_DOUBLE_S8_TLV(xname, xreg, xmin, xmax, tlv_array) #define SOC_ENUM(xname, xenum) #define SOC_SINGLE_EXT(xname, xreg, xshift, xmax, xinvert, xhandler_get, xhandler_put) #define SOC_SINGLE_EXT_TLV(xname, xreg, xshift, xmax, xinvert, xhandler_get, xhandler_put, tlv_array) #define SOC_SINGLE_BOOL_EXT(xname, xdata, xhandler_get, xhandler_put) #define SOC_ENUM_EXT(xname, xenum, xhandler_get, xhandler_put)
SOC_ENUM("3D Function", wm8753_enum[5]), SOC_ENUM seems really inefficient tracking those enum numbers. Could you declare the enum in place?
#define SOC_ENUM_SINGLE(xname, xreg, xshift, xmax, xtexts) \ { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname,\ .info = snd_soc_info_enum_double, \ .get = snd_soc_get_enum_double, .put = snd_soc_put_enum_double, \ .private_value = (unsigned long) &(struct soc_enum) \ .reg = xreg, .shift_l = xshift, .shift_r = xshift, \ .max = xmax, .texts = xtexts }
Is it possible to turn all of these macros into inline functions? Can an inline initialize a structure? Making them inlines would get us syntax checking without expansion.
I'm having some success getting 32b wide controls working.
On Sat, Jul 26, 2008 at 12:26:13AM -0400, Jon Smirl wrote:
Can you help me document these macros?
Have you seen Documentation/sound/alsa/soc/codec.txt (not that it's complete)?
For example what does TLV stand for? I know it supplies a decibel range.
Don't know for sure, sorry - this is just a straight pass-through of the generic ALSA API of the same name.
R really mean two registers.
Yes, it expands to register. Note that it only ever occurs for things that are already a SOC_DOUBLE of some description so is neater than it seems if you just try to document the convention.
What does EXT do?
EXT expands to external - it adds per control read and write operations so the machinery can be used for things not the primary CODEC (eg, an external amplifier like you'll see in the OpenMoko or the jack controls on the Zaurus machines).
Once we support multiple CODECs there will be less need for this, it's partly a bodge due to not being able to have more than one CODEC driver in the system.
How about S8?
Signed 8 bit - the 8 bit part of it is just due to the bitmasking, there shouldn't be any other need for it.
SOC_ENUM("3D Function", wm8753_enum[5]), SOC_ENUM seems really inefficient tracking those enum numbers.
The use of indexes into an array is mostly in older ASoC drivers - I believe it is a result of mechanical conversion from older, pre-ASoC drivers. It's not nice and there's no actual need for it but it's never been worth fixing. More modern drivers use variables with names, though some do end up with the big array due to templating off older drivers.
Could you declare the enum in place?
For the enum control itself then providing the compiler is happy I can't see any immediate reason why not. For the text it's quite useful to be able to specify the text separately since that means that multiple instances of the same set of enumerated values don't need to have the text written out again.
#define SOC_ENUM_SINGLE(xname, xreg, xshift, xmax, xtexts) \ { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname,\ .info = snd_soc_info_enum_double, \ .get = snd_soc_get_enum_double, .put = snd_soc_put_enum_double, \ .private_value = (unsigned long) &(struct soc_enum) \ .reg = xreg, .shift_l = xshift, .shift_r = xshift, \ .max = xmax, .texts = xtexts }
Is it possible to turn all of these macros into inline functions? Can an inline initialize a structure? Making them inlines would get us syntax checking without expansion.
You can't do anything at compile time outside of the preprocessor, unfortunately.
participants (2)
-
Jon Smirl -
Mark Brown