Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Tony Lindgren <tony@atomide.com>]

* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [160802 01:33]:
> On Tuesday 02 Aug 2016 09:48:53 Peter Ujfalusi wrote:
> > >> drivers/media/platform/omap/omap_vout_vrfb.c
> > 
> > Needs the interleaved transfer type support in omap-dma. Now it is in -next.
> 
> Thank you for your work on this. When you'll have patches for 
> omap_vout_vrfb.c, please let me know and I'll test them.
> 
> > >> drivers/mtd/onenand/omap2.c
> > 
> > Using memcpy, I have sent the patches:
> > https://patchwork.kernel.org/patch/7842891/
> > https://patchwork.kernel.org/patch/7851881/
> >
> > but I need to revisit. I think the 'fix' will be to drop the DMA support
> > from it.

Yeah let's remove the DMA support from onenand/omapp.c. It's
wrongly using GPIO line instead of the external DMA trigger
line, and already mostly disabled. I doubt that anybody will
miss the DMA support here.

> > >> drivers/usb/gadget/udc/omap_udc.c
> > >> drivers/usb/musb/tusb6010_omap.c
> > 
> > They are mostly slave implementations, but. As I recall they do some really
> > interesting non symmetric setup for the TX/RX DMA which I still need to
> > figure out. And I'm looking for HW to check for regression...

I think the omap_udc.c is also used for modems on omap4 based
phones?

The tusb6010_omap.c case is a very good test case with variable
size ping test over USB Ethernet :) It's probably also the only
mainline DMA test case for omap external DMA request pins, so I'd
rather have it updated,

> > >> (and a bit of drivers/video/fbdev/omap/omapfb_main.c)
> > 
> > Hrm, that is OMAP1. Looks like highly coupled with mach-omap1/lcd_dma.c.
> > This is going to be a bit complicated IMHO.
> > 
> > > Peter?
> > > 
> > >> I guess we could improve build coverage by moving
> > >> arch/arm/plat-omap/dma.c into drivers/dma/omap-dma.c, but that
> > >> has the disadvantage of exposing a nonstandard interface from
> > >> somewhere inside of the dmaengine subsystem.
> > > 
> > > yeah that won't be nice. I think we should get these removed... We have
> > > omap as well as edma driver in dmaengine.
> > 
> > I'm not going to move the legacy API under dmaengine, it makes no sense.
> > 
> > My plan is to do what I did with the eDMA driver stack:
> > - convert drivers using the legacy API to dmaengine
> > - 'merge' the code from plat-omap to the dmaengine driver
> >   - while doing this the legacy API will vanish along with the
> > plat-omap/dma.c
> > 
> > As with the eDMA, the sDMA stack will need some cleanup, but the good thing
> > is that the dmaengine driver have minimal dependency on the legacy
> > plat-omap/dma.c API.

We can move the omap1 legacy dma support to be mach-omap1 specific
once the problem drivers are fixed.

Regards,

Tony