Re: [RFC v2 2/5] dmaengine: Add slave DMA interface

["Dan Williams" <dan.j.williams@intel.com>]

On Jan 30, 2008 3:52 AM, David Brownell <david-b@pacbell.net> wrote:
> On Wednesday 30 January 2008, Haavard Skinnemoen wrote:
> > Descriptor-based vs. register-based transfers sounds like something the
> > DMA engine driver is free to decide on its own.
>
> Not entirely.  The current interface has "dma_async_tx_descriptor"
> wired pretty thoroughly into the call structure -- hard to avoid.
> (And where's the "dma_async_rx_descriptor", since that's only TX??
> Asymmetry like that is usually not a healthy sign.)  The engine is
> not free to avoid those descriptors ...
>

For better or worse I picked async_tx to represent "asynchronous
transfers/transforms", not "transmit".  So there is no asymmetry as it
is used for operations in any direction, or multiple directions as is
the case with xor.  It is simply a gathering point for the common
functionality of descriptor-based offload-engines plus some extra
stuff to deal with creating arbitrary dependency chains.

> And consider that many DMA transfers can often be started (after
> cache synch operations) by writing less than half a dozen registers:
> source address, destination address, params, length, enable.  Being
> wildly generous, let's call that a couple dozen instructions, including
> saving "what to do when it's done".  The current framework requires
> several calls just to fill descriptors ... burning lots more than that
> many instructions even before getting around to the Real Work!  (So I
> was getting at low DMA overheads there, more than any particular way
> to talk to the controller.)
>

Well, it has gone from 4 calls to 2 recently for the memcpy case.  The
only reason it is not 1 call is to support switching dependency chains
between channels i.e. performing some copies on one channel followed
by an xor an another.

--
Dan