[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