On Jan 30, 2008 3:52 AM, David Brownell <[EMAIL PROTECTED]> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
