[alsa-devel] [PATCH - alsa-lib 2/3] tlv: Handle 'holes' in SND_CTL_TLVT_DB_RANGE array

Peter Ujfalusi peter.ujfalusi at nokia.com
Tue Jul 20 08:53:22 CEST 2010


On Monday 19 July 2010 21:30:48 ext Takashi Iwai wrote:
> > It still seems silly to have to paper over this for every single dB
> > interval - if we need to link up the ranges it seems like we ought to
> > be fixing this in one place.
> Well, what I don't feel right is that this breaks the simpleness of
> DB_RANGE handling.  It's just damn simple, and works as long as the
> target point is covered by defined ranges.  If something is wrong,
> it's the definition, not the parser.  That's why I wondered first
> whether it can't be fixed in the driver side.  I want the parser stuff
> as simple as possible.

I think this patch still keeps the parser simple.
It does not break the existing functionality (overlapped mappings still works), 
but it can in addition handle the non-overlapped mapping of TLV ranges.
> So, practically seen, how many driver are buggy in this regard?
> And for how many of them should a new TLV entry added?
> The only worst case is discontinued lines you mentioned.  Is there
> a real device that behaves so (and implemented in that way)?
> If fixing in alsa-lib is a better compromise, I'd take it.  But I'd
> like to hear numbers first.

The following drivers have some sort of TLV_DB_RANGE_HEAD:
with overlapping ranges:

with non-overlapping ranges:
soc/codecs/tpa6130a2.c /* patch sent to convert to overlapping */
soc/codecs/wm8400.c /* only single SCALE_ITEM */
soc/codecs/wm8990.c /* only single SCALE_ITEM */
soc/codecs/twl4030.c /* patch sent to convert to overlapping */

I don't really know how many of these driver would require new TLV entry, but 
the twl4030, and tpa6130a2 (for tpa6140a2 chip) does not needed new entry, just 
modification of the TLV items.

I agree with Mark in regards, that the decision making is strictly 
policy/userspace stuff, but I also think that the drivers should also provide as 
much, and as accurate information to user space to make this decision (if it is 
in form of overlapped mapping, than like that).

Having said that, I believe, that the patch for alsa-lib alone would provide 
correct enough handling of non-overlapping TLV ranges (without breaking the 
handling of overlapped mappings).


More information about the Alsa-devel mailing list