Hi Greg,
Zitat von Greg Ungerer <[EMAIL PROTECTED]>:
Hi Markus,
Markus Franke wrote:
well, as far as I understand the generic DMA API in the Linux
kernel should provide an abstraction layer to driver developers and
tries to hide all the specifics about DMA implementation. That
means a developer should be able to use DMA in it's drivers by
simply using some kind of a call flow:
request_dma
set_dma_addr
set_dma_mode
set_dma_count
enable_dma
disable_dma
free_dma
As such, no specific knowledge about the DMA controller is needed
by the driver developer to set up DMA transfers.
The MCF548x uses a very different DMA controller than for example
the MCF5272. Now, Freescale provides the MCDMAAPI in order to
control all the tiny bits in the controller. Furthermore, I have a
modified version of the FEC-driver, from Freescale's latest BSP,
running within uClinux. This driver strongly depends on the
MCDMAAPI and some internals of the DMA controller itself. (e.g.
setting descriptors which point to microcode necessary for the DMA
engine)
I want to move this code on top of the generic linux DMA layer.
Now, my problem is that there are lot's of things to be followed in
the FEC driver in order to get DMA working. Actually, all these
things should be moved somewhere in target specific DMA code (maybe
arch/m68knommu/dma.c???)
Perhaps something like arch/m68knommu/platform/547x/dma.c
may be more appropriate. I expect this will remain specific
to the 547x/548x parts.
Yeah, I think I will go for this approach.
in order to hide these things from the driver developer, right? The
idea is now to remove all the MCDMAAPI-calls from the FEC-driver
and replace them with the generic API calls listed above. Would
this be the right way?
Yes, I think that is the right way to do it.
The DMA engine can be used for other things than the FEC ethernets
right?
Yes. The DMA engine can be used for different mem-to-mem,
periph-to-mem and mem-to-periph transfers. It is a mulitfunctional
controller although it is very different from a traditional DMA
controller. It's a microcoded engine, that means Freescale offers
special microcode (undocumented) for supporting FEC transaction.
Similar to this they provide generic microcode for doing
memory-to-memory transactions.
If so I have some doubts that with the small amount of functions
above, I will be able to use all the functionality of the MCF548x's
DMA controller.
What parts of supporting don't you think will fit in that
framework?
I have just some doubts with respect to this microcoded DMA engine
which is not a DMA controller in a usual way. I think I will go for
the approach described above and the I'll how see how things are going
on. I also thought about just providing a generic interface for
mem-to-mem transfers in a first step and leaving the special
microcoded FEC transfers beside.
Thanks and with best regards,
Markus
_______________________________________________
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
