On Fri, Jan 13, 2012 at 11:41:13PM +0300, Sergei Shtylyov wrote: > Hello. > > On 01/13/2012 01:40 PM, Gupta, Ajay Kumar wrote: > > >CPPI4.1 (Communication Port Programming Interface) is a TI specific DMA > >controller used in multiple TI platform such as AM33x, DA8x, AM35x, TI81x. > >The DMA engine is mainly used by musb controller on above platform. > > There are (at least out of tree) platforms using CPPI 4.1 for Ethernet. if they are out of tree, I'm sorry but we don't care about them. If they are in tree, then that needs to be sorted out on the same patchset. > >Earlier version of the driver was submitted by Sergei Shtylyov at [1] but > >was not merged due to disagreement on the location of driver in kernel. > > To be precise, TI requested pulling out already queued (to > arch/arm/common/) CPPI 4.1 driver from RMK's patch system without > even notifying me. At least that was RMK's version... > > >Refer the discussions at [1] for more details. > > >[1] http://marc.info/?l=linux-usb&m=125087318308323 > > Unfortunately, that's not all of the discussion of interest. > > >The new implementation of the CPPI4.1 DMA slave driver will be in the > >drivers/dma folder, complying to dmaengine framework. > > Has there been any work in this direction done yet? > > >It would involve changes in existing musb driver also for which current > >plan is to maintain the compatibility of non-CPPI4.1 DMA in musb driver. > > I didn't quite understand this part... how come ? What he's saying is that while moving cppi-dma.c to drivers/dma he will not move all the other dma engines (Inventra, OMAP, TUSB-over-GPMC, etc). > >The task is planned to be spitted into below subtasks. > > >(1) Post RFC on the API details, changes envisaged in musb driver and other > >challenges > > First of all, I foresee changes in drivers/dma/ to cope with the > entity in CPPI 4.1 called the queue manager (there's also buffer > manager but it wasn't implemented on DA8xx, so I didn't design any > API for it). that's why the kernel is open source, right ? If we need to improve the framework so that it understands other types of DMAs, so be it. -- balbi
Attachment:
signature.asc
Description: Digital signature
