Hi Markus,
Markus Franke wrote:
Zitat von John Williams <[EMAIL PROTECTED]>:
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
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
