Hi, > 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. > > > 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? Currently we are working on design flow and API details which will be posted first for review. Ajay > > > 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... > > > 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). > > > (2) Implement and post RFC for the CPPI4.1 DMA driver and changes > needed in > > musb driver. > > > Let me know if you have any thoughts/comments on this. > > > Regards, > > Ajay > > WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
