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

[Chao Xie]

> 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.
>
If you are sending the patch for pdma and tdma, please include me as well.
Now we are trying to make audio to use DMA independent of pdma and
tdma(current driver are bound to tdma), and there are some modification for pdma too.

> 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.
>
It need many efforts. There are some drivers make use of old pxa DMA driver,
for example camera/smc Ethernet.
The difficult is some platform was produced almost 10 years ago, and I do not 
have such platform in my hand. So will you test them or just pass compilation?
>
> Thanks,
> Daniel