Re: [PATCH 1/2] ASoC: Allow drivers to specify how many bits are significant on a DAI

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

On Tue, Jan 17, 2012 at 06:55:29PM +0100, Peter Ujfalusi wrote:
> On 01/17/2012 05:44 PM, Mark Brown wrote:

> > The datasheet isn't terribly machine parseable.

> True, and the information that the chip internally works in 24 bit mode
> is irrelevant. Why would any application care when it plays 16bit sample
> that the HW will internally convert it to 24 bit?

Off the top of my head it may decide that if it happens to have 24 bit
data then passing it straight through was sensible.  But frankly I'm
just working on the basis that if it's more effort to hide information
than to provide it then providing it seems like the way forwards.  I've
certainly got no intention of writing any code here myself unless
there's some issue found.

> >> This is not a point. If it does it's internal digital volume on the full
> >> 32bit resolution from which the HW just discards 8bits we will loose
> >> resolution. If PA knows that out of the 32bit only the 24bit msbit is
> >> going to be used it can apply the gain correctly.

> > This isn't a correctness thing really, it's just that it's doing more
> > work than it needs to because nothing is going to pay attention to the
> > the lower bits it outputs.  A gain applied with 24 bits just has an
> > output with a bit less resolution than one applied with 32 bits but it
> > shouldn't be substantially different.

> Yeah, but it is not correct. If it does not know this we have 8bit
> 'latency' in gain control. Pulse can change the gain which will have no
> effect.

Which will have the same overall effect as if it doesn't do anything
based on knowing the resolution.