Re: [PATCH 00/13] pxa3xx patches to support mvebu builds

[Daniel Mack <zonque@gmail.com>]

On 30.07.2013 15:15, Ezequiel Garcia wrote:
> Hello Daniel,
> 
> On Tue, Jul 30, 2013 at 10:18:09AM +0200, Thomas Petazzoni wrote:
>> On Tue, 30 Jul 2013 10:02:04 +0200, Daniel Mack wrote:
>>> On 30.07.2013 09:53, Thomas Petazzoni wrote:
>>>> On Tue, 30 Jul 2013 09:43:54 +0200, Daniel Mack wrote:
>>>>> Interesting, because I'm working on a dmaengine implementation for
>>>>> PXA right now. I'm not even half through, but I'm making progress,
>>>>> and I'm not sure yet how to merge it. Because there won't be any
>>>>> migration path, it'll be a bigger set that has to go in in one in
>>>>> order to prevent build breakage.
>>>>
>>>> Aren't drivers/dma/mmp_pdma.c and drivers/dma/mmp_tdma.c already
>>>> dmaengine drivers for PXA ?
>>>
>>> Yes, I saw the pdma driver as well, after I started my own
>>> implementation. However, the tree is full of users of the proprietary
>>> API, and moving them over won't be gap-less.
>>
> 
> Mmmm.. I'm a bit confused by this: is your dmaengine driver any
> different/better from the already existent mmp_{p,t}dma.c ?

As I said, I saw this after I started my own implementation, which isn't
a big deal. At least, I now understand the internals of dmaengine
drivers :) The mmp_pdma looks suitable for PXA2xx chips, but it doesn't
work yet for me. I'll try and fix this first, and then port over all the
drivers.

> Here's a patch posted in July 2012 converting pxa3xx-nand to dmaengine.

Where?

> That patch was never merged because (just as Thomas says) both
> dma drivers (mmp dmaengine on one side, mach-pxa dma on the other) don't
> work together. In other words, you have to convert *all* drivers at the
> same time.
> 
> Thomas proposed an idea for this conversion a few months ago: (quoting
> him from IRC)
> 
> """
> First have a patch that reimplements the existing plat-pxa/dma.c API on
> top of dmaengine, so that you don't have to change any driver.
> Then, go through each driver, one per patch to switch to the dmaengine API.
> And finally get rid of the compatibility layer created in the first
> patch.
> """
> 
> Does this sound sane?

Unfortunately, no. I thought so too, but the problem is that all users
of the proprietary PXA DMA implementation access the registers directly,
and also allocate their own DMA coherent register space, which is
unneeded with a proper dmaengine implementation.

So there's nothing else we can do than really change all the drivers,
which is what I'm currently doing. I'll put you on Cc: once I post patches.


Thanks,
Daniel