From: Matt Sealey <matt@genesi-usa•com>
To: Clemens Koller <clemens.koller@anagramm•de>
Cc: Arnd Bergmann <arnd@arndb•de>, linuxppc-embedded@ozlabs•org
Subject: Re: Mem-2-Mem DMA - Generalized API
Date: Mon, 25 Jun 2007 15:31:59 +0100 [thread overview]
Message-ID: <467FD1DF.4000602@genesi-usa.com> (raw)
In-Reply-To: <467FBABD.9040103@anagramm.de>
Clemens Koller wrote:
> Hello, Matt!
>
>> There is so much you can do with most SoC DMA controllers, and it's not
>> even limited to PowerPC (most ARM/XScale SoCs have very capable devices
>> inside too). I can only imagine that nobody got excited over IOAT because
>> the entire programming interface stinks of "offloading gigabit ethernet"
>> and not much else.
>
> The main question remains: Is it possible to have a flexible cross platform
> DMA API which handles even complex requests and does scheduling,
> prioritizing, queuing, locking, (re-)building/caching of SG lists... automagically.
I would think so. I think there is a fairly generic example in many parts
of the Linux kernel. Dare I say the Via Unichrome AGP subsystem? And a
bunch of the ARM/OMAP platforms..? A lot of the code is even identical,
I wonder why it isn't some library rather than platform drivers.
> Filling memory with zero is also a simple task for a DMA engine.
> (Thinking about malloc() and memset())
Also xor and logical operations, byte swapping huge chunks of data, that
kind of thing. Most DMA engines in SoCs have cute features like that. I
think BestComm can even calculate CRCs for IP packets.
> The problem is IMHO similar to video acceleration. Within the
> Xorg's XAA/EXA/whatever framework, the drivers accelerate certain
> calls if the hardware has the capability to do so. Other calls fall back
> to some default non accelerated memcpy() & friends.
>
> Sounds like a lot of fun... replacing kernel's and libc's memcpy() with
> memcpy_with_dma_if_possible(). :-)
Indeed. I wonder if we could pull apart the IOAT/DMA stuff and genericise
it (it should be possible) or simply add to it, or if making a powerpc
specific dma engine abstraction would be an easier idea.
Probably the latter to be merged with the former at a later date would
be easier to manage. Take inspiration but don't be bound by Intel's
weird "new" (i.e. 15 year old) concept?
--
Matt Sealey <matt@genesi-usa•com>
Genesi, Manager, Developer Relations
next prev parent reply other threads:[~2007-06-25 14:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-24 19:39 Mem-2-Mem DMA - Generalized API Clifford Wolf
2007-06-24 20:21 ` Arnd Bergmann
2007-06-25 8:03 ` Clifford Wolf
2007-06-25 11:03 ` Matt Sealey
2007-06-25 12:53 ` Clemens Koller
2007-06-25 14:31 ` Matt Sealey [this message]
2007-06-25 17:00 ` Olof Johansson
2007-06-25 17:48 ` Clifford Wolf
2007-06-25 18:01 ` Clifford Wolf
2007-06-25 21:20 ` Matt Sealey
2007-07-04 9:05 ` Clifford Wolf
2007-07-04 10:11 ` Clemens Koller
2007-07-07 5:24 ` Timur Tabi
2007-07-07 8:41 ` Clifford Wolf
2007-07-07 13:08 ` Arnd Bergmann
2007-07-07 13:27 ` Clifford Wolf
2007-07-07 13:28 ` Arnd Bergmann
2007-07-07 13:34 ` Clifford Wolf
2007-07-11 9:35 ` Clifford Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=467FD1DF.4000602@genesi-usa.com \
--to=matt@genesi-usa$(echo .)com \
--cc=arnd@arndb$(echo .)de \
--cc=clemens.koller@anagramm$(echo .)de \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox