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

[Markus Franke]

Hi Greg,

Zitat von Greg Ungerer <gerg at snapgear.com>:
> 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