[RFC] dmaengine: Moving TI SDMA driver to dmaengine - design plan

[RFC] dmaengine: Moving TI SDMA driver to dmaengine - design plan

[Raju, Sundaram]

Hi,

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. 

I would like to follow the Freescale i.MX DMA driver model,
where imx-dma.c in drivers/dma which implements all the
dmaengine hooks, internally uses the APIs in dma-v1.c file in 
arch/arm/mach-imx. All APIs in dma-v1.c are also exported
out for direct use by clients.

Advantages of this model:
1. No compilation breaks for any of the existing client drivers.
2. Client drivers can be moved one by one to the new SDMA driver 
after complete testing on all OMAP boards.

We can mark the old SDMA driver APIs as deprecated and insist on
all client drivers to be moved to the new SDMA driver in the
dmaengine framework soon.

I have made the preliminary changes in code for this design and
I am in the phase of testing a few client drivers. If this is a good way
to proceed then I will send out my patches with the client drivers I
have changed for review once I am done with the testing.

Let me know your thoughts.

Regards,
Sundaram

[RFC] dmaengine: Moving TI SDMA driver to dmaengine - design plan

[Russell King - ARM Linux]

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.

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.

[RFC] dmaengine: Moving TI SDMA driver to dmaengine - design plan

[Raju, Sundaram]

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Friday, July 08, 2011 3:34 PM
> To: Raju, Sundaram
> Cc: linux-arm-kernel at lists.infradead.org; linux-omap at vger.kernel.org; Dan;
> Shilimkar, Santosh; linux-kernel at 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

[RFC] dmaengine: Moving TI SDMA driver to dmaengine - design plan

[Tony Lindgren]

* Raju, Sundaram <sundaram@ti.com> [110708 03:09]:
> > -----Original Message-----
> > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> > Sent: Friday, July 08, 2011 3:34 PM
> > To: Raju, Sundaram
> > Cc: linux-arm-kernel at lists.infradead.org; linux-omap at vger.kernel.org; Dan;
> > Shilimkar, Santosh; linux-kernel at 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.

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

[RFC] dmaengine: Moving TI SDMA driver to dmaengine - design plan

[Vinod Koul]

On Fri, 2011-07-08 at 11:04 +0100, Russell King - ARM Linux wrote:
> 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.
> 
> 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.
Russel,

Remember we have addressed the documentation part, is there something
else you feel is still missing?

-- 
~Vinod Koul
Intel Corp.

[RFC] dmaengine: Moving TI SDMA driver to dmaengine - design plan

[Linus Walleij]

On Fri, Jul 8, 2011 at 10:22 AM, Raju, Sundaram <sundaram@ti.com> wrote:

> I would like to follow the Freescale i.MX DMA driver model,
> where imx-dma.c in drivers/dma which implements all the
> dmaengine hooks, internally uses the APIs in dma-v1.c file in
> arch/arm/mach-imx. All APIs in dma-v1.c are also exported
> out for direct use by clients.
>(...)
> Let me know your thoughts.

Sounds like a plan, just do it.
I think Samsung are currently using the scheme to migrate to
dmaengine as well.

Thanks,
Linus Walleij