[uClinux-dev] Freescale's MCDMAAPI vs. Generic Linux DMA API on Coldfire MCF548x

[Markus Franke]

Hi Greg,

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???) 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? 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.


Thanks for any comments on this and with best regards,

Markus


Zitat von Greg Ungerer <gerg at snapgear.com>:

> Hi markus,
>
> Markus Franke wrote:
>> Zitat von Greg Ungerer <gerg at snapgear.com>:
>>> 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:     gerg at snapgear.com
> 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 at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev