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

[Ezequiel Garcia]

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 ?

(I'm sure I've misunderstood something, otherwise why would you be
working in something that's already available?)

> Indeed. Some patches migrating the pxa3xx_nand driver to use the
> dmaengine API have been posted a while ago, but they haven't been
> merged because one needs to convert *all* the PXA drivers to the
> dmaengine API to get the thing working.
> 

Here's a patch posted in July 2012 converting pxa3xx-nand to dmaengine.
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?
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com