Messages in this thread | | | Date | Sat, 18 Jul 2009 11:25:10 -0700 | Subject | Re: Intended usage of the dmaengine | From | Dan Williams <> |
| |
On Fri, Jul 17, 2009 at 3:33 AM, Per Forlin<per.lkml@gmail.com> wrote: > Hi, > > I work with Linux in embedded systems and I got more interested in > dmaengine after Haavard Skinnemoen added the DMA SLAVE support. DMA > SLAVE opens up the dmaengine for embedded users and I wonder if there > is more room for support towards the embedded world. I've made a test > implementation of the dmaengine for our DMAC. Some parts that weren't > supported by the dmaengine had to be exported by the driver code. A > similar example of this is cyclic DMA jobs in dw_dmac.h. > Is this the preferable way to handle it? Or could this functionality > be added to the dmaengine instead? > > Additional support that I would like to have in the "struct dma_engine" is > * stopping the dma channel transfer > * continue a stopped transfer > * PER2PER transfers (dma transfer between two peripherals) > * dma transfers from phy mem to per, and per to phy mem > * function to return the transfer count of an active dma transfer > (useful when the dma channel has been stopped deliberately) > > I am willing to propose and contribute updates to the dmaengine > regarding this matter. With this email I would like to check with you > whether these types of new support are welcome in the dmaengine.
I had a similar conversation with Ira Snyder recently as his DMA_SLAVE implementation required architecture specific extensions. The problem is that once you step outside pure memory-to-memory offload the implementation rapidly gets architecture specific and quirky very quickly. I am not convinced that it is worth the effort to shoehorn functionality that is by definition architecture specific into a generic api. Outside of providing a channel allocation scheme and a capability for maintaining some private context for a "slave-dma" channel I do not see a consistent role for dmaengine to play in these embedded usage models. You can see that the ARM/pxa developers have arrived at a similar conclusion and are not leveraging dmaengine for their channel management.
So I would say keep those bits you mentioned above architecture specific for now, if we start to see generic cross-architecture duplication then we can think about up-leveling the implementation of those pieces.
Regards, Dan
| |