[Sound-open-firmware] [RFC PATCH 3/6] dma: introduce new API for requesting DMAC
Liam Girdwood
liam.r.girdwood at linux.intel.com
Thu Jun 7 21:45:07 CEST 2018
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.
Before doing v3, maybe best to reply with proposed flags and types ?
Thanks
Liam
>
> Let me know your thoughts.
More information about the Sound-open-firmware
mailing list