Re: [PATCH 1/4] Revert "ASoC: tlv320dac33: Use core to set the msbits constraint"

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Sat, Jan 21, 2012 at 04:05:06PM +0200, Peter Ujfalusi wrote:

> AFAIK we only place this constraint to 32bit samples. I have not
> encountered any other HW limitation.
> What if we just simply convert the msbit core support to apply the
> constraint to 32 bit samples only?

I do think we can safely drop the 8 and 16 bit entries from the array,
even where there are lower accuracy devices (like basebands) I can't see
anyone caring.  However I think if we go and check there's also going to
be some cases where 24 bit will be used due to 16-23 bit ADCs and DACs,
grep turned up a few non-ASoC devices using 20 bits for example.  

> With the current code we are not able to apply different constraint to
> different sample size anyway.
> Locally I have added the support for this, but it looks like over
> engineering.

I can't think of any hardware where that would be required, as I as far
as I am aware this mostly comes from devices using a fixed internal
resolution independant of the audio interface format.

> I have the patch(s) for both way, but I think we are better off if we
> support 32 samples only (simple, clean, covers 99% of use case, well as
> it is now it covers 100%).

The 32 bit only one is better, yes, though like I say I think will have
to add in the 24 bit case again if it gets dropped.

> > We've got real CPU consumption problems in ASoC - the DAPM algorithm is

> And things aren't getting any simpler. For sure we need to do something
> about this.

Yeah, I will probably actually do something about the stream start/stop
soon as it's inconvenient for the CODEC<>CODEC link stuff.

> > We'll all get *much* more benefit from working on improvements of things
> > like that (and on the memory consumption which isn't great either and
> > probably manages to burn measurable CPU cycles due to cache misses) than
> > we ever will from anything we do with this code.
> 
> You know Mark, I'm an engineer. It bothers me. It bothers me more since
> I _know_ it is there. I just can not help myself...

One way or another I've always done a lot of work on old code and code
I'm not familiar with and obviously recently I've been doing a lot of
review as well so I do tend to value maintainability really highly, if
only from a "do unto others" point of view.