* Raju, Sundaram <sundaram@xxxxxx> [110708 03:09]: > > -----Original Message----- > > From: Russell King - ARM Linux [mailto:linux@xxxxxxxxxxxxxxxx] > > Sent: Friday, July 08, 2011 3:34 PM > > To: Raju, Sundaram > > Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-omap@xxxxxxxxxxxxxxx; Dan; > > Shilimkar, Santosh; linux-kernel@xxxxxxxxxxxxxxx > > Subject: Re: [RFC] dmaengine: Moving TI SDMA driver to dmaengine - design > > plan > > > > On Fri, Jul 08, 2011 at 01:52:17PM +0530, Raju, Sundaram wrote: > > > I am planning to move TI SDMA driver in OMAP tree > > > into the dmaengine framework. > > > > > > The first immediate issue of concern I noticed is the > > > huge number of client drivers that use the existing SDMA driver. > > > More than 15 client drivers are using the current SDMA driver. > > > > > > Moving the SDMA driver along with all of these client drivers at a > > > single stretch seems a humungous task. > > > I noticed a model in the existing DMA drivers in dmaengine > > > framework that will over come this issue. > > > > It _is_ sane to build a dmaengine driver on top of the existing SoC > > private API, then convert the drivers to DMA engine, and then cleanup > > the resulting DMA engine driver. > > Yes, that is what I thought. Thanks. Yes that's what we did with the gpiolib changes. That allows then converting the drivers over to the DMA engine API one function at a time (or one driver at a time). Regards, Tony -- 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
