On Thu, 2018-06-07 at 20:45 +0100, Liam Girdwood wrote:
On Thu, 2018-06-07 at 10:26 -0700, Ranjani Sridharan wrote:
I did some experiments with the new API suggested and ran into issues with the APL platform. And the problem was with the ipc DMAC. What type would I use for ipc? We've been using the GP LP DMA for ipc but with this API, there's no way for me to request a GPLP DMA and requesting a capability of mem_to_mem or mem_dev/dev_to_mem, just to get a GP_LP DMA , would be misleading. So I think I am leaning back to the original solution proposed by Liam.
We will have to qualify DMAC with a type and copy cap like like these:
DMAC_TYPE would be one of: GP_LP_DMA, GP_HP_DMA, Host_DMA or Link DMA
DMAC_COPY_CAP would be one of: REDA, WRITE or DUPLEX
With this it is easy for me to choose the dma like this:
host: dma_get(Host_DMA, READ/WRITE, FLAGS) dai: dma_get(GP_LP_DMA, READ/WRITE, FLAGS) page table: dma_get(HOST_DMA, READ, FLAGS) ipc: dma_get(GP_LP_DMA, DUPLEX)
ipc is host DMA.
This is what is breaking for me atm on APL. In the current implementation, we are using GP_LP_DMA for ipc.
Before doing v3, maybe best to reply with proposed flags and types ?
Thanks
Liam
Let me know your thoughts.
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware