Messages in this thread | | | Date | Mon, 4 Feb 2013 18:47:12 +0200 | From | Felipe Balbi <> | Subject | Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common |
| |
Hi,
On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote: > > opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1, > > Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver. > > > Granted, CPPI 4.1 makes some assumptions about the fact that it's > > handling USB tranfers, > > What CPPI 4.1 code makes this assumptions? MUSB DMA driver? Then it's just
HW makes the asumptions
> > but nevertheless, the IP can be, and in fact is, > > used with many different DMA engines and driver needs to cope with it. > > What IP, CPPI 4.1 or MUSB?
MUSB
> > Current DMA abstraction is quite poor, for example there's no way to > > compile support for multiple DMA engines. Code also makes certain, IMO > > unnecessary, assumptions about the underlying DMA engine (abstraction is > > poor, as said above but it we could follow MUSB's programming guide when > > it comes to programming DMA transfers). > > Don't know, I was quite content with the abstraction when writing CPPI 4.1 > driver for MUSB...
look closer. The whole:
if (is_cppi()) foo(); else if (is_inventra()) bar(); else if (is_omap_sdma()) baz();
is bogus.
> > Considering all of the above, it's far better to use DMA engine and get > > rid of all the mess. > > In my eyes, getting rid of the mess doesn't justify breaking the rules that > Russell formulated above.
MUSB is no PCI, there is no single, standard interface to the DMA engine (unlike Synopsys' dwc-usb3 and dwc-usb2, where we don't use DMA engine), every DMA engine comes with its own set of registers, its own programming model and so forth.
-- balbi [unhandled content-type:application/pgp-signature] | |