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

[Peter Ujfalusi <peter.ujfalusi@ti.com>]

Hi Mark,

Sorry for the delay, I'm traveling.

On 01/19/2012 09:07 PM, Mark Brown wrote:
> Please take a step back (I know I'm rather annoyed and am trying to do
> so myself), none of this is getting us anywhere.

Agreed. This was not entertaining for me at least. I'm sure we just
overlook each other's point of view.
I had some time to think this over with a 'clean' head.
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?
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 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%).

> We've got real CPU consumption problems in ASoC - the DAPM algorithm is
> the biggest one, even with the work I did recently to mitigate against
> it it's still got the ability to explode dramatically to the point where
> it's user visible as the worst case is well over O(n^2).  There's plenty
> of low hanging fruit that it'd be much better to spend time on here - as
> a quick example every time we start or stop a stream we do a linear
> search of all DAPM widgets looking for those that might be affected
> based on a string match in order to kick DAPM for them.  That's O(n) in
> the number of widgets in the card plus the strcmp() costs.

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

> 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...
Sorry about that.

-- 
Péter