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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
