On 6/16/08, Liam Girdwood <lg@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
