[alsa-devel] ASOC: codec_reg_show and variable length registers
codec_reg_show() can't handle my TAS5504 codec. The codec has 104 (sparse out of 256) registers with variable lengths from 1 to 32 bytes.
Should the register cache really be part of the core? The core could still make the sysfs entries and use a callback to print them. reg_cache_size/reg_cache_step would then become private.
It's the sprintf that is the problem. I need to push that into my driver so that I can print out variable lengths. Or we need to make the core use an indirect table that encodes the lengths.
On Sat, Jul 05, 2008 at 09:37:45AM -0400, Jon Smirl wrote:
Should the register cache really be part of the core? The core could still make the sysfs entries and use a callback to print them. reg_cache_size/reg_cache_step would then become private.
It's still useful to share as much of the code as possible to ensure consistency between devices. Most devices are able to use the generic register cache formatting (which is all that uses the size and step) as is and as a general rule it makes maintinence easier when code is factored out of individual drivers.
It's the sprintf that is the problem. I need to push that into my driver so that I can print out variable lengths. Or we need to make the core use an indirect table that encodes the lengths.
I'd suggest adding an optional callback that drivers can use to replace the register value display (just the value) so that existing drivers don't need modification to cope with larger register sizes - it's not the common case, after all.
If there are devices that use these larger registers for operations that are handled by snd_soc_update_bits() and friends that'd require more but I'd be surprised to see such devices.
On 7/5/08, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Sat, Jul 05, 2008 at 09:37:45AM -0400, Jon Smirl wrote:
Should the register cache really be part of the core? The core could still make the sysfs entries and use a callback to print them. reg_cache_size/reg_cache_step would then become private.
It's still useful to share as much of the code as possible to ensure consistency between devices. Most devices are able to use the generic register cache formatting (which is all that uses the size and step) as is and as a general rule it makes maintinence easier when code is factored out of individual drivers.
I'll post my code when I get it working. The chip is a TI TAS5504 or TAS5508.
It's the sprintf that is the problem. I need to push that into my driver so that I can print out variable lengths. Or we need to make the core use an indirect table that encodes the lengths.
I'd suggest adding an optional callback that drivers can use to replace the register value display (just the value) so that existing drivers don't need modification to cope with larger register sizes - it's not the common case, after all.
If there are devices that use these larger registers for operations that are handled by snd_soc_update_bits() and friends that'd require more but I'd be surprised to see such devices.
The big registers are arrays. For example register 0x41 is 32 bytes. It is an array of eight 32b float gains for that channel's mixer inputs.
Or register 0x51 - 20 bytes, five 32b floats describing a biquad filter.
Datasheet: http://www.ti.com/lit/gpn/tas5504
On Sat, Jul 05, 2008 at 08:43:30PM -0400, Jon Smirl wrote:
The big registers are arrays. For example register 0x41 is 32 bytes. It is an array of eight 32b float gains for that channel's mixer inputs.
Or register 0x51 - 20 bytes, five 32b floats describing a biquad filter.
Datasheet: http://www.ti.com/lit/gpn/tas5504
Yeah, I checked that it's not a problem for this codec before replying. I'd imagine that other usages of this sort of large register would be for similar things and therefore OK with the current implementation.
participants (2)
-
Jon Smirl -
Mark Brown