[alsa-devel] Thoughts on ASOC v2 driver architecture

[Jon Smirl]

On 6/16/08, Liam Girdwood <lg at opensource.wolfsonmicro.com> wrote:
> Ok, I think I have a good idea of what you are proposing here.
>
>  The ASoC DMA is currently very much like a library in that it exports
>  it's ALSA PCM functions to the core (by registering itself) and whilst
>  the DMA functions are not directly called by client CPU DAI drivers they
>  are indirectly called on the client DAIs behalf by the ASoC core (in
>  response to ALSA core). This means we don't have to burden our DAI
>  drivers with CPU DMA specific calls.

Doesn't the current model of a global ASOC DMA driver require that all
cpu_dai channels use the same transport? Should the model allow
different transports on different cpu_dai channels (maybe some
programmed IO, and some DMA)?

I don't need this for my hardware, I'm just wondering if it should be allowed.

>  Fwiw, I do think platform driver could really be better named to be more
>  function specific e.g. dma driver. I'm also considering a rename of
>  machine to fabric.
>
>  We also have CPU DAIs that are shared between different CPU
>  architectures (with different DMA). e.g. i.MX31 and FSL PPC share the
>  same SSI architecture - breaking the tightly coupled library model.
>
>
>  Liam
>
>


-- 
Jon Smirl
jonsmirl at gmail.com