[PATCH] s3cmci: port DMA code to dmaengine API

[arnd@arndb.de (Arnd Bergmann)]

On Tuesday 20 May 2014 14:36:49 Vasily Khoruzhick wrote:
> On Tue, May 20, 2014 at 1:39 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 20 May 2014 13:22:35 Vasily Khoruzhick wrote:
> >> Hi Arnd,
> >>
> >> On Mon, May 19, 2014 at 10:02 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > For this driver, you don't have to go that far, as long as it's
> >> > ensure that the pointer to the filter function is available to
> >> > the driver, i.e. you can't have a built-in s3mci driver when the
> >> > dmaengine driver is a loadable module.
> >>
> >> OK, so I guess I need to add explicit dependency on
> >> CONFIG_S3C24XX_DMAC for s3cmci driver.
> >>
> >> Btw, I didn't understand if it's acceptable to pass DMA channel number
> >> through DMA resource for non-DT case or not?
> >
> > It's commonly done on certain SoCs, but I'd prefer to not start doing
> > it on those that don't do it today.
> >
> > At the moment, we do it only on s3c64xx, s5p, davinci, omap1, and pxa
> > on ARM, as well as arch/blackfin and one MIPS machine.
> > I suppose we have to introduce it on s3c24xx in order to keep
> > supporting sound, unless we put the audio dma channels into
> > s3c_audio_pdata.
> >
> > I think that would be a better approach, given that you also need
> > to put the filter function pointer for the audio stuff somewhere.
> >
> > Maybe Mark Brown has a strong preference to how he wants this done
> > in the audio drivers, then you can do it the same way for s3cmci.
> 
> Let's just leave channel number hardcoded, how it was before conversion.
> It doesn't seem to be a good idea to clean non-DT machine code now, since
> it's better to put some effort into converting s3c2410 and s3c244{0,2} to DT.

Ok, fair enough.

I'm actually more interested in making s3c24xx multiplatform capable than
moving it to DT, but we that requires a few other patches as well, and
we can fix this one along with those.

	Arnd