Hi, On Mon, Feb 04, 2013 at 08:54:17PM +0300, Sergei Shtylyov wrote: > > 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 > > Not true at all. There is a separate set of registers (at offset 0) which > copes with USB specifics, but CPPI 4.1 itself doesn't know about USB anything.
CPPI 4.1 was made for USB transfers. > It's just the way the driver was written that it used both sets of registers > but > this needs to be changed into more abstacted accesses to the USB-specific > part, > to cope with it being different on different platfroms, like AM35x. The driver > as it was last posted, just needs rework now. are you saying you will do the work ? > >> 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. > > That part -- yes. There were attempt to get rid of this, but without > changing > the DMA API. It was left halfway done after my only critical comment, IIRC. > Will > we ever see the continuation of this effort? patches are welcome -- balbi
signature.asc
Description: Digital signature
