[Sound-open-firmware] [RFC PATCH 3/6] dma: introduce new API for requesting DMAC

Ranjani Sridharan ranjani.sridharan at linux.intel.com
Fri Jun 8 02:25:22 CEST 2018


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 at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware


More information about the Sound-open-firmware mailing list