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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
