[alsa-devel] [PATCH 06/19] ASoC: fsl: Don't set unused struct snd_pcm_hardware fields

Mark Brown broonie at kernel.org
Fri Dec 20 19:27:27 CET 2013

On Fri, Dec 20, 2013 at 03:04:08PM +0100, Lars-Peter Clausen wrote:
> On 12/20/2013 03:25 PM, Timur Tabi wrote:

> > Is this new?  There are formats that the codec and the SSI support that the
> > DMA controller does NOT support, like packed 24-bit samples.  How do we
> > ensure that we never get those?

> No, this is how it has always been. If there are restrictions imposed by the
> DMA controller we need to add support for expressing this inside the ASoC
> framework. But I think it will probably be more complex than just saying the
> DMA controller supports format A, B, C and the DAI controller supports
> format B, C, D and then just do the intersection of both. E.g. the DAI
> controller probably does not care whether the samples are packed or not if
> it only sees one sample at a time, while

The most common pattern I've seen is that the DAIs expect to see whole
samples at a time get written into their FIFOs since the FIFOs tend to
be stored in samples rather than bytes.  With that pattern it'd be a bit
cleaner to have them advertise sample sizes and transfer sizes and then
have the core work out that if you can for example do 24 bit samples
with four byte transfers and have a DMA controller that needs a 1:1
mapping between data read and written then we can't do packed format.

I think in general we want to be moving the DAIs to a sample size based
interface and then mapping that onto the DMA controller when we connect
the DMA and CPU DAIs.  This would help with clarity on the CODEC side as
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20131220/ee46eee0/attachment.sig>

More information about the Alsa-devel mailing list