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

[Peter Ujfalusi]

Hi,

I'm waiting for comments for the series against alsa-lib regarding this issue...

On Monday 19 July 2010 11:51:41 ext Mark Brown wrote:
> On Mon, Jul 19, 2010 at 08:57:05AM +0300, Peter Ujfalusi wrote:
> > On Friday 16 July 2010 15:33:25 ext Mark Brown wrote:
> > > 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.
> 
> The problem I see is if the hardware step sizes result in discontinuties
> in the scale so you can't easily join the top end of one set of values
> with the bottom end of another you're pretty stuck - joining the ranges
> up will only work if they can be made to overlap which isn't always
> going to be the case.

Yeah, and the tpa6130a2 is even worst than most of the things that I have ever 
seen:
http://focus.ti.com/lit/ds/symlink/tpa6130a2.pdf, page 20
Basically there are no continuous ranges at all (sometimes it feels, that the 
steps are chosen via lottery).

> For example, something like:
> 
> 1: 0
> 2: 2
> 3: 4
> 4: 5
> 5: 7
> 6: 9
> 
> (a bit artificial but you get the idea) is going to be a bit tricky.

I see, but I still don't see problem with this:
non-overlapping (A):
static const unsigned int nonoverlapping_tlv[] = {
        TLV_DB_RANGE_HEAD(2),
        1, 3, TLV_DB_SCALE_ITEM(0, 200, 0),
        4, 6, TLV_DB_SCALE_ITEM(500, 200, 0),
};

overlapping (B):
static const unsigned int overlapping_tlv[] = {
        TLV_DB_RANGE_HEAD(3),
        1, 3, TLV_DB_SCALE_ITEM(0, 200, 0), /* at raw 3 the dB is 4 */
        3, 4, TLV_DB_SCALE_ITEM(400, 100, 0), /* at raw 4 the dB is 5 */
        4, 6, TLV_DB_SCALE_ITEM(500, 200, 0),
};

B covers all ranges, with 3 sub-range.
A covers the ranges, which has 2dB steps, and leaves a hole for the 1dB step 
between raw 3, and 4.

> > 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.

No problem.

With the patches I have sent for alsa-lib both A and B style of array going to 
be handled correctly.

If you have time, can you take a look at them?

Thanks,
Péter