Hi, On Tue, Sep 09, 2014 at 08:17:32PM +0400, Matwey V. Kornilov wrote: > 2014-09-09 20:09 GMT+04:00 Felipe Balbi <balbi@xxxxxx>: > > On Tue, Sep 09, 2014 at 07:52:59PM +0400, Matwey V. Kornilov wrote: > >> 2014-09-09 19:11 GMT+04:00 Felipe Balbi <balbi@xxxxxx>: > >> > 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. > >> > >> If so, ux500_dma.c and musb_cppi41.c should be almost identically > >> wrapping dmaengine, but they aren't. > > > > heh, the difference is mostly because ux500 supports scatter-gather > > while cppi41 doesn't. That can be handled generically. The other > > differences are due to silicon errata, and that should be hidden inside > > DMA engine driver itself, not in MUSB. > > > > That is, If I understand correctly, one may start from the other side. > Firstly create musb_dmaengine.c using generic dmaengine API (not > relying on hardware model) and providing private API and then drop one > by one existing DMA implementations from musb. Eventually, only > musb_dmaengine.c will be kept suitable for all kinds of drivers. you've just read my mind and that's a bit freaky :-) But you're right. At the time we drop all other implementations, we might as well merge musb_dmaengine.c into the core driver itself and completely rid ourselves of MUSB private DMA API :-) Clearly, that cannot be done in one development cycle, so we need to find a way to introduce all this code and, meanwhile, not break anything :-) cheers -- balbi
Attachment:
signature.asc
Description: Digital signature
