[alsa-devel] [PATCH - alsa-lib 2/3] tlv: Handle 'holes' in SND_CTL_TLVT_DB_RANGE array
tiwai at suse.de
Tue Jul 20 12:56:59 CEST 2010
At Tue, 20 Jul 2010 09:53:22 +0300,
Peter Ujfalusi wrote:
> 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).
OK, this sounds convincing enough to me.
I applied your new patches now.
More information about the Alsa-devel