[alsa-devel] [PATCH 0/3] ASoC: twl4030/tpa6130a2:?DB_RANGE mapping fixes

[Peter Ujfalusi]

Hi Mark,

On Friday 16 July 2010 15:33:25 ext Mark Brown wrote:
> Sure, and the forward mapping in particular seems to make it very clear
> what should be happening here.  The way I'd parse this the ability to
> specify ranges is just a way of saving on typing and we should always
> end up with single mapping entries between raw values and dB values.
> The API is inherently getting a list of specific point values, it's just
> using a compact encoding for some of them.

If all ranges are are covered (even with overlaps, but with consistent mapping), 
than alsa-lib needs less fixing.
The whole thing boiled down on how the _DB_RANGE is handled in alsa-lib.
It goes through the sub _DB_* ranges, and tries to find the correct mapping.
If we have 'holes' in the array, than it will fail to find the item. In case of 
non overlapping array, we can have several 'holes' (in between two DB_SCALE), so 
alsa-lib seemingly will fail to find the requested dB 'randomly'.

> Isn't this going to get messy when the increments don't line up so that
> it's easy to overlap the start of one range with the beginning of the
> next?

Well, I assume however writes the driver knows how to build up a lookup table 
which is consistent, so I don't really see a problem.

> > Probably alsa-lib can be fixed somehow to look in between the ranges,
> > when it is looking for certain dB value, but at first look it is not
> > that straight forward.
> 
> Well, I'd expect it to do something like go through all the ranges
> available and look for the closest match which doesn't seem terribly
> complex.  I haven't looked at the code at all, though.

I don't share your concern regarding to overlapping array for TLV, but I can fix 
alsa-lib instead of the drivers to behave correctly.
I'll post patches against alsa-lib to fix the _DB_RANGE handling. It will take 
some time to understand, and fix the code + testing it.

Thanks,
Péter