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.
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?
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?
Regards
Greg
Zitat von Greg Ungerer <[EMAIL PROTECTED]>:
Hi markus,
Markus Franke wrote:
Zitat von Greg Ungerer <[EMAIL PROTECTED]>:
As a general rule you want to follow the way Linux does things.
This is especially true for modern versions of the kernel (2.6.x),
and especially if you want the code to be acceptable for main
line inclusion.
apart from <LINUX/Documentation/DMA-API.txt>, is there any further
documentation about the linux DMA subsystem available. LDD3 also talks
As far as I am aware that is all there is. Look at the code
for other architectures as an example as well.
more about the usage of the Generic DMA Layer, rather than saying
something about how to connect your target specific DMA code to the
DMA core. I am especially interested in the function stubs/macros
one need to provide to the Linux DMA Layer.
The code for other architectures will probably provide the
best example of what to do.
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
--
------------------------------------------------------------------------
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
