Messages in this thread | | | From | "Raju, Sundaram" <> | Date | Fri, 8 Jul 2011 15:44:02 +0530 | Subject | RE: [RFC] dmaengine: Moving TI SDMA driver to dmaengine - design plan |
| |
> -----Original Message----- > From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk] > Sent: Friday, July 08, 2011 3:34 PM > To: Raju, Sundaram > Cc: linux-arm-kernel@lists.infradead.org; linux-omap@vger.kernel.org; Dan; > Shilimkar, Santosh; linux-kernel@vger.kernel.org > 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.
> > What we must make sure though is that the DMA engine slave API (which > isn't well documented) is correctly implemented before drivers are > converted over to use the DMA engine support code, otherwise we may > end up with lots of drivers that require re-fixing several times over. >
Very true! Agreed! I will send over the patches for review once I am done with testing.
Regards, Sundaram
| |