lkml.org 
[lkml]   [2008]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-01-30 19:31    [W:0.160 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site