[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