On 6/16/08, Liam Girdwood lg@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