On Tue, Sep 09, 2014 at 07:00:10PM +0400, Matwey V. Kornilov wrote: > 2014-09-09 18:45 GMT+04:00 Felipe Balbi <balbi@xxxxxx>: > > On Tue, Sep 09, 2014 at 01:28:55PM +0400, Matwey V. Kornilov wrote: > >> Hi George, > >> > >> Why dma_controller_create can not be set in struct musb_platform_ops? > >> Then each module would be able to set dma_controller_create it wants, > >> and musb_init_controller would use musb->ops->dma_controller_create > >> instead of just dma_controller_create. > > > > patches are welcome :-) > > > > Will the following approach be acceptable? > > 1. musbhsdma.o cppi_dma.o tusb6010_omap.o ux500_dma.o musb_cppi41.o > became independent modules (tristate), each module exports two > symbols: PREFIX_dma_controller_create and ..._destroy. > 2. add two callbacks to musb_platform_ops, when pointers are NULL then > no DMA is used > 3. every module uses appropriate &PREFIX_dma_controller_create in its > PREFIX_ops structure > 4. musb_core uses wrappers which calls > musb->ops->dma_controller_create and destroy > > In this case every DMA mode can be reused more by several drivers if > necessarily. the proper way would be to move everything to dma_engine. OMAP already has support for DMA engine and both CPPI and Ux500 are already using that. What we need it move inventra dma and cppi 3.x to DMA engine, then move DMA engine into the core driver and have it grab a DMA through that, instead of using this private API. -- balbi
Attachment:
signature.asc
Description: Digital signature
