[lkml]   [2013]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

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?


> > 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())
else if (is_inventra())
else if (is_omap_sdma())

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.

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2013-02-04 18:24    [W:0.112 / U:0.824 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site