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

[Takashi Iwai]

At Tue, 20 Jul 2010 09:53:22 +0300,
Peter Ujfalusi wrote:
> 
> Hi,
> 
> 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:
> pci/as1838.c
> soc/codecs/wm8753.c
> 
> with non-overlapping ranges:
> soc/codecs/tpa6130a2.c /* patch sent to convert to overlapping */
> soc/codecs/uda1380.c
> soc/codecs/wm_hubs.c
> soc/codecs/max9877.c
> soc/codecs/wm8350.c
> soc/codecs/wm8400.c /* only single SCALE_ITEM */
> soc/codecs/wm8961.c
> soc/codecs/wm8990.c /* only single SCALE_ITEM */
> soc/codecs/wm8993.c
> soc/codecs/wm9081.c
> soc/codecs/wm9090.c
> soc/codecs/wm9713.c
> 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).

OK, this sounds convincing enough to me.
I applied your new patches now.

Thanks!


Takashi