Message-ID: <20120126090245.GF15110@legolas.emea.dhcp.ti.com>
Date:	Thu, 26 Jan 2012 11:02:47 +0200
From:	Felipe Balbi <balbi@...com>
To:	"Gupta, Ajay Kumar" <ajay.gupta@...com>
Cc:	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Pasupathy, Visuvanadan" <vichu@...com>,
	"Balbi, Felipe" <balbi@...com>
Subject: Re: RFC: usb: musb: Changes proposed for adding CPPI4.1 DMA

Hi,

(please format your emails better next time)

On Wed, Jan 25, 2012 at 03:22:32PM +0000, 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.

looks good.

> Brief on each DMA related API used in /drivers/usb/musb*
> ========================================================= 
> 1)
> MUSB DMA API currently used: dma_controller_create()          
> MUSB DMA API parameters currently used: 
> 		struct musb  *musb, 
> 		void __iomem *mregs
> 
> Proposal: This API will be implemented in the dma-engine.c and will
> allocate and populate dma_controller object.

k

> 2)
> MUSB DMA API currently used: dma_controller_delete() 
> MUSB DMA API parameters currently used: 
> 		struct dma_controller *controller
> 
> Proposal: This API will be implemented in the dma-engine.c and frees
>          the dma_controller object

k

> 3)
> MUSB DMA API currently used: dma_controller.start()
> MUSB DMA API parameters currently used: 
> 		struct dma_controller *controller
> 
> Proposal: This will be an empty function. The current actions intended
>           for start of HW DMA (as whole engine - not the specific channel)
>	    will be implemented in cppi41 slave driver.

why don' you make this one actually enable the hw ? Maybe call
pm_runtime_get_sync(), enable the DMA, increase a usecount on the
controller and stuff like that ?

> 4)
> MUSB DMA API currently used: dma_controller.stop()
> MUSB DMA API parameters currently used: 
> 		struct dma_controller *controller
> 
> Proposal: This will be an empty function. The current actions intended
>           for stop of HW DMA (as whole engine - not the specific channel)
>	    will be implemented in cppi41 slave driver.

likewise, but reversing start ?

> 5)
> MUSB DMA API currently used: dma_controller.chan_alloc()       
> MUSB DMA API parameters currently used: 
> 				struct dma_controller *,	
> 				struct musb_hw_ep *,		  
> 				u8 is_tx                
> Proposal
> * This function translates to the dma_request_channel API of dma-engine.
> * The filter function that helps to acquire the channel is also part of
>   this implementation.
> * The dma_chan structure returned by dma-engine API is going to be 
>   different from "dma_channel" structure. As the channel structure 
>   does not carry any important information except status and
>   associating DMA-HW channel structure, dma engine.c could still
>   translate/emulate the similar (almost same) structure to musb* files.
> * The endpoint and direction information is used in filter function.
> * A challenge here is to implement a filter function that scales up 
>   for more number of channels (64 channels at this point)

to start, make it as simple as necessary. Implement other trickery
later.

> * Another challenge is the maintain the platform data on endpoints vs 
>   channels (which change between SoCs)

We need to move out of platform_data. While doing that, make it match on
DT attributes.

> 6)		
> MUSB DMA API currently used: dma_controller.chan_program() 
> MUSB DMA API parameters currently used: 
> 				struct dma_channel * 
> 				u16 maxpacket
> 				u8 mode, 
> 				dma_addr_t dma_addr,
> 				u32 length  
> 
> Proposal:
> * All the parameters except the maxpacket directly applies in dma-engine API
> * Max packet is used for Transparent (mode0) mode of DMA where, each
>   burst of DMA programming will be of maxpacket size.
> * For all generic DMA requests - SG structure of DMA engine API will 
>   have only one entry
> * DMA driver would require the "maxpacket" size, for deciding type of 
>   DMA transfer. As the current API does not provide option, it can be 
>   part of a private data to slave DMA driver through dma_chan structure.
>   Alternatively, dmaengine's "DMA_SLAVE_CONFIG" control command also
>   can be used for this purpose
> * For ISO requests, each frame buffer is treated as an entry of SG structure.
>   ISO programming will require some changes in musb_host.c as it currently 
>   programs each frame buffer as a separate DMA request.

k

> 7)
> MUSB DMA API currently used: dma_controller.chan_release()
> MUSB DMA API parameters currently used: 
> 		struct dma_channel	*channel
> 
> Proposal: Releases the channel - typically happens only during the rmmod 
>         of the driver

k

> 8)
> MUSB DMA API currently used: dma_controller.chan_abort()
> MUSB DMA API parameters currently used: 
> 		struct dma_channel	*channel
> 
> Proposal: This translates into the control commands of DMA engine. We can use 
>           "DMA_TERMINATE_ALL" control command for this purpose.

k

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists