Subject: Re: [RFC] Interface to hardware-assisted data movers
To: Cliff Neighbors <cliff@allegronetworks.com>
From: Jason R Thorpe <thorpej@wasabisystems.com>
List: tech-kern
Date: 06/19/2002 18:01:26
On Wed, Jun 19, 2002 at 05:41:08PM -0700, Jason R Thorpe wrote:
> > These can be useful when moving data through device fifo registers,
> > or for block fill & zero. Perhaps the API can define flags for set up
> > addr hold mode (or none).
>
> Hm, can you give me a better idea of what you mean by "hold" in this
> case? I.e. what are the exact semantics, here?
Hm, to follow-up... Matt Thomas mentioned to me what you might mean
by this... like "source address doesn't auto-increment" or "dest address
doesn't auto-increment", right?
If that is the case, then this could (and, I think, should :-) be handled
by using a different "function", i.e. instead of "copy-block", you might
have "stream32-out" to slurp from a held source 32-bits at a time and
a "stream32-in" to slurp from a memory region into a held destination
32-bits at a time. Since dmover uses strings to describe the functions,
you can add whatever your back-ends might provide, and the API handles it
transparently.
BTW, the reason I want it as a separate function is so that the name
of the function is the only thing a back-end has to do to advertise its
capabilities. E.g. if a device can do a 6-way XOR operation, then it
would provide an algdesc named "xor-6". I want to avoid having to introduce
flags, because flags don't always scale well, esp. if you're trying to
describe complex combinations of operations.
--
-- Jason R. Thorpe <thorpej@wasabisystems.com>