lkml.org 
[lkml]   [2012]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: RFC: usb: musb: Changes proposed for adding CPPI4.1 DMA
Date
Hi,
> 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 ?

Sounds good, will look into this.
>
> > 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.

Yes, ofcourse.
>
> > * 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.

Ok fine.

Regards,
Ajay

>
> > 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


\
 
 \ /
  Last update: 2012-01-27 16:03    [W:0.060 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site