Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Fri, Feb 01, 2013 at 01:59:59PM -0500, Matt Porter wrote:
> On Fri, Feb 01, 2013 at 07:52:46PM +0000, Sergei Shtylyov wrote:
> > Hello.
> > 
> > On 02/01/2013 09:49 PM, Matt Porter wrote:
> > 
> > >>> Move mach-davinci/dma.c to common/edma.c so it can be used
> > >>> by OMAP (specifically AM33xx) as well.
> > 
> > >> I think this should rather go to drivers/dma/?
> > 
> > > No, this is the private EDMA API. It's the analogous thing to
> > > the private OMAP dma API that is in plat-omap/dma.c. The actual
> > > dmaengine driver is in drivers/dma/edma.c as a wrapper around
> > > this...same way OMAP DMA engine conversion is being done.
> > 
> >   Keeps me wondering why we couldn't have the same with CPPI 4.1 when I proposed
> > that, instead of waiting indefinitely for TI to convert it to drivers/dma/
> > directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... Sigh.
> 
> That is a shame. Yeah, I've pointed out that I was doing this exactly
> the same way as was acceptable for the OMAP DMA conversion since it was
> in RFC. The reasons are sound since in both cases, we have many drivers
> to convert that need to continue using the private DMA APIs.

It's very simple.

The OMAP DMA stuff in plat-omap/dma.c has existed for a long time, well
before things like the DMA engine API came into being.  Same with a lot
of the DMA code in arch/arm.  It is therefore in the privileged position
of having "grandfather" rights when it comes to existing in mainline.

However, today what we're finding is that these private per-platform APIs
are sub-optimal; they prevent the peripheral drivers in the drivers/
subtree from being re-used on other SoCs.  So, even through they pre-exist
the DMA engine support, they're being gradually converted to the API.

Moreover, we have _far_ too much code in arch/arm.  It's something that
has been attracted complaints from Linus.  It's something that's got us
close to having updates to arch/arm refused during merge windows.  It's
got us close to having parts of arch/arm deleted from the mainline kernel.

The long term plan is _still_ to remove arch/arm/*omap*/dma.c and move
the whole thing to drivers/dma.  That can only happen when everything is
converted (or the drivers which aren't converted have been retired and
deleted) - and provided that TI decide to continue funding that work.
That's still uncertain since the whole TI OMAP thing imploded two months
ago.

Now, CPPI is brand new code to arch/arm - always has been.  It post-dates
the DMA engine API.  And it's been said many times about moving it to
drivers/dma.  The problem is Sergei doesn't want to do it - he's anti the
DMA engine API for whatever reasons he can dream up.  He professes no
knowledge of my dislike for having it in arch/arm, yet there's emails
from years back showing that he knew about it.  TI knows about it; Ajay
about it.  Yet... well... history speaks volumes about this.

Now, there may be a new problem with CPPI.  That being we're now requiring
DT support.  _Had_ this been done prior to the push for DT, then it would
not have been a concern, because then the problem becomes one for DT.
But now that OMAP is being converted to DT, and DT is The Way To Go now,
that's an additional problem that needs to be grappled with - or it may
make things easier.

However, as I've said now many times: CPPI is _not_ going in arch/arm.
Period.  That makes it not my problem.  Period.

I really have nothing further to say on CPPI; everything that can be said
has already been said.  If there's still pressure to have it in arch/arm,
I will _NOT_ respond to it, because there's nothing to be said about it
which hasn't been said before.  The only reason it's still being pressed
for is a total reluctance to do anything about it being in arch/arm.