[PATCH V6 1/2] of: Add generic device tree DMA helpers

[davidb@codeaurora.org (David Brown)]

On Mon, Sep 17, 2012 at 08:42:11PM +0000, Arnd Bergmann wrote:
> On Saturday 15 September 2012, Russell King - ARM Linux wrote:
> > 
> > On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote:
> > > 3. Supporting legacy devices not using DMA Engine
> > > 
> > >    These devices present a problem, as there may not be a uniform way to easily
> > >    support them with regard to device tree. Ideally, these should be migrated
> > >    to DMA engine. However, if this is not possible, then they should still be
> > >    able to use this binding, the only constaint imposed by this implementation
> > >    is that when requesting a DMA channel via of_dma_request_slave_channel(), it
> > >    will return a type of dma_chan.
> > 
> > As far as devices not using DMA engine, the answer is we don't support
> > their specification in the DT model.  Note that the legacy OMAP DMA
> > API is scheduled for removal next year, so it's not going to be around
> > that much longer.
> 
> There are a few platforms using the ISA DMA API (rpc, h720x, shark, footbridge),
> and I agree that they are unlikely to see OF support, although if they did, it
> wouldn't be unreasonable to encode their DMA channels using the same binding.
> 
> The other ones that are currently around with their own DMA implementation are
> 
> bcmring --> platform is going away
> samsung --> gradually getting moved to dmaengine, already has its own binding
>             that needs to be replaced with this one, so best do it at the same
>             time.
> tegra   --> old dma code gone in 3.7
> pxa/mmp --> dmaengine implementation being worked on, should wait for that.
> msm     --> dma implementation only used by two drivers (serial and mmc). 
> 
> Outside of arch/arm, at least sh, cris, unicore32 and blackfin have their
> own dma APIs based on the ISA interfaces. I don't currently see any of them
> moving towards DT, but it's definitely possible. 
> 
> Among the above MSM seems to be the most likely candidate to use the binding
> before moving to DT. The msm_sdcc driver is (like much of the msm platform
> code) lagging far behind the internel version that qualcomm have, and the
> device tree binding they are using is incompatible with the common MMC
> binding (and of course the DMA binding here) as well. For getting MSM up
> to speed compared with the other platforms, they have to use proper DT
> bindings as well as proper DMA engine support. Between those two, I'd prefer
> fixing the DT binding first, in order to limit the amount of changes that
> have to be done to external device tree files.

There is also a lot of similarity between the mmci hardware and the
msm_sdcc hardware.  Enough so, that it is probably better for us to
make the mmci driver work with our hardware, rather than trying to
keep msm_sdcc going.

There is also an MSM nand device that appears to have not made it in.
It is heavily dependent on the weird features of the DMA hardware.  I
don't have any current plans to support this device, since most boards
using MSMs these days are using mmc/sd instead of bare NAND.

Our DMA hardware is really weird, but should be a bit reasonable.  It
is also being gradually replaced in newer chips with a different DMA
framework.

As far as I'm concerned, I consider making our DMA driver(s) use the
DMA engine API to be part of getting these platforms working with DT.

It is planned, but there are quite a few things that need to be
tackled first.

David

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation