Hi Markus,
Markus Franke wrote:
thanks for the reply.
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?
Hmm, good question. There doesn't seem to be much architecture
support for the generic code in drivers/dma/. Really there are
not a lot of users of the traditional *_dma() interface either.
Plenty of other architectures still seem to have a asm-*/dma.h,
with real support. So that API still seems to be alive.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
Secure Computing Corporation PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
_______________________________________________
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
