Re: RFC: usb: musb: Changes proposed for adding CPPI4.1 DMA

From: Sergei Shtylyov
Date: Thu Feb 02 2012 - 06:06:31 EST


On 02-02-2012 8:57, Gupta, Ajay Kumar wrote:

As a next step to dma-engine based cppi4.1 driver implementation
this RFC has the overview of changes in the musb driver.
RFC on CPPI slave driver changes will follow next.

Overview of changes in the musb driver

1)Add a dma-engine.c file in the drivers/usb/musb folder
2)This file will host the current musb dma APIs and translates them to
dmaengine APIs.
3)This will help to keep the changes in drivers/usb/musb/musb* files
minimal and also to retain compatibility other DMA (Mentor etc.)
drivers which are yet to be moved to drivers/dma
4)drivers/usb/musb/dma-engine.c, will wrap the dmaengine APIs to
make existing musb APIs compatible.
5)drivers/usb/musb/dma-engine.c file will implement the filter
functions and also implement .dma_controller_create (allocates
& provides "dma_controller" object) and .dma_controller_delete
6)CPPI4.1 DMA specific queue and buffer management will be internal
to slave CPPI DMA driver implementation.

You mean drivers/dma/ driver?


I think you are forgotting that CPPI 4.1 MUSB
has some registers controlling DMA/interrupts beside those of CPPI 4.1
controller and MUSB core itself. How do they fit in your scheme?

We have been discussing on how to handle these in slave driver and

These certainly cannot be handled in the slave driver because the
registers are different for every controller implementation and, the
main thing, they don't belong to CPPI 4.1 as such.

Felipe suggested to use device tree for differences in register maps
among different platforms.

I don't see how the device tree would magically help here.

I do see issues in reading wrapper interrupt status register and then
calling musb_interrupt() [defined inside musb_core.c] from slave driver.

would post our proposal in RFC for slave driver design. Do you have
any proposal?

I think this will need hooks from dma-engine.c to the glue layers. I
was going to implement such in my version of MUSB CPPI 4.1 driver (in order
to also support AM35x) but lacked time.

That would mean a change in current drivers/dma API.

No, it doesn't. I'm proposing hooks from dma-engine.c which is situated in drivers/usb/musb/ if I got you right. It just means that the calls to dma-engine.c as MUSB DMA driver won't map to the calls to the DMA slave driver as directly as you've presented before.



WBR, Sergei
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at