Messages in this thread | | | Date | Wed, 30 Jan 2008 11:28:20 -0700 | From | "Dan Williams" <> | Subject | Re: [RFC v2 2/5] dmaengine: Add slave DMA interface |
| |
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
| |