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

[Greg Ungerer]

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 <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
> 
> 
> 
> 
> 

-- 
------------------------------------------------------------------------
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