On 7/20/08, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Sun, Jul 20, 2008 at 03:51:20PM -0400, Jon Smirl wrote:
The issue is the time taken to do the I/O via the I2C bus, not the implementation in the chip - if anything I'd expect this to be slower than a direct hardware implementation but not perceptibly. If applications try to step through all the values for a control with anything approaching the available resolution then that'd be a lot of data being written. Like I say, it may not be a practical issue (I'd expect applications to be smarter) but it raised my eyebrows.
Yes, stepping through 4096 volume levels individually would be a pain. A UI would need to initially move in larger increments.
I have thought about building a pseudo interface for the chip that would be compatible with the existing ASLA controls, and then using an
I'd just ignore it initially and if it's a problem look at doing things like deferring the register writes by a short amount. Most UIs won't be able to display anything like the resolution required to cause trouble in the first place - they are scaling the resolution of the control into the resolution of the UI anyway.
IOCTL to bypass for finer control. But isn't this problem going to reoccur as we encounter more HD audio level hardware?
My own expectation would be that if it is a serious issue it'll be dealt with in user space - my concern here was that the effects are being magnified by the combination of the slow control bus and the large registers that contain the controls. As I say, it may not be a real issue.
0x49-0x50, bass management 4 bytes, contain 5.23 coefficients
OK, so the bass management looks like it should be able to fit in a processor word?
If the word is 64 bits.
Err... you said it's 4 bytes?
The chip supports DRC (compression and expansion), some of the DRC parameters are 48bits in 25.23 format. Loudness is 25.23 too. 0x92 and 0x94 are examples of 64 bit registers.
Most registers are 5.23. About eight of them are 25.23. 5.23 fits in 4 bytes, 25.23 (48bits) needs 2 words, 8 bytes.
To support this chip you could add the concept of fields to ALSA
ASoC?
registers. Fields would be 32 bit. For backward compatibility the existing chips would just set field to 0.
The use of a shift plus mask is largely a function of the fact that that maps well onto how datasheets are usually written - I'm not sure that using numbered fields would help there. I'm also not sure that it's a good idea to build the 32 bit assumption in - someone is bound to come up with controls that are either larger that or cross a 32 bit boundary within a register.
A better idea might be to expand the current 'shift' from 4 bits to 8 bits. And then allow masks for upto 64 bits. But this messes with the current register interface since you would need to pass the value and shift into the driver.
I have registers that are 256 bits. That's a 32 bit value with a shift of 224. Another is 64 bits with a shift of zero.
The problem is encoding all of this into .private_value, it's too small.
I have to go read the control code since I don't know exactly how it works. I haven't located any doc for it.