[uClinux-dev] Freescale's MCDMAAPI vs. Generic Linux DMA API on Coldfire MCF548x

John Williams jwilliams at itee.uq.edu.au
Sun Feb 24 20:30:01 EST 2008


Hi Markus,

Markus Franke wrote:

> Zitat von John Williams <jwilliams at itee.uq.edu.au>:
> 
>> I've been looking at the 2.6 kernel's generic DMA layer recently.
>> There are two aspects, the stuff described in DMA-IPA.txt is really
>> more about how to allocate DMA-suitable memory regions for DMA, rather
>> than the mechanics of DMA transactions themselves.
> 
> That's exactly what I was thinking.
> 
>> In the 2.6 kernel, drivers/dma/dmaengine.c implements a fairly generic
>> DMA API for "standalone" DMA controllers, as opposed to DMA-capable
>> peripherals (bus masters).  DMA controllers register themselves as
>> devices, and clients register themselves as, well, clients.  THey then
>> request a channel, and launch DMA transactiosn via the client API.
> 
> I am quite surprised to see this API. Thanks for the hint. Actually I  
> was thinking about to provide functions like request_dma, free_dma,  
> set_dma_count, set_dma_address, etc. in arch/m68knommu/dma.c for my  
> MCF548x.
> 
> So what is the prefered way now or are both ways equal and it's just a  
> matter of taste?

Well, if you've got the time and inclination, going along with the 
standard kernel API is always a good idea.  It might be a bit more work 
upfront than just hackin gsomething together for your arch, but in the 
long run there are benefits to you and everyone else.

It may be necessary to extend the standard kernel API to support your 
DMa controller, that's what I'll need to do since our arch's DMA engine 
can do e.g. keyhole DMA (non-incrementing source or dest address) for 
moving data to/from hardware devices.  That's not an option in the 
kernel API, so I'll need to add it.

Regards,

John


More information about the uClinux-dev mailing list