[PATCH V6 1/2] of: Add generic device tree DMA helpers
David Brown
davidb at codeaurora.org
Tue Sep 18 09:06:15 EST 2012
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
More information about the devicetree-discuss
mailing list