From: Matt Sealey <matt@genesi-usa•com>
To: Clifford Wolf <clifford@clifford•at>
Cc: Arnd Bergmann <arnd@arndb•de>, linuxppc-embedded@ozlabs•org
Subject: Re: Mem-2-Mem DMA - Generalized API
Date: Mon, 25 Jun 2007 22:20:26 +0100 [thread overview]
Message-ID: <4680319A.5050503@genesi-usa.com> (raw)
In-Reply-To: <20070625180110.GH20463@clifford.at>
Clifford Wolf wrote:
> Hi,
>
> However, i don't think that implementing stuff like memset() in a dma
> controller is any good because that would just flood the memory bus which
> would then block in 99% of all cases the cpu until the dma is finished.
>
> It would however cost less power than doing that in the CPU. ;-)
At least while the DMA transfer is happening, you could preempt to some
other task. Would it flood the memory bus? When a DMA transfer happens
would it really do it in such a way that it would stall the CPU on a
memory access far more than it would usually?
I think it would have to be extremely badly designed to be even ABLE to do
that, or at least, you'd be doing some incredibly unwise things to be able
to flood it like that.
>> 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.
>
> I don't think that this would actually be powerpc specific in any way. But
> since such general purpose dma controllers are more common in embedded
> hardware this still seams to be the right place to discuss the issue.
I meant powerpc platform (as in ARCH=powerpc) specific. Rather than dropping
it in the global drivers, just keep it as a library for powerpc. Everyone
else can get it later with a move into the full tree. As long as the headers
have common, easy to get to names that do not conflict with anything
preexisting, it would not affect anything.
Taking IOAT as an example and fixing it's weirdness would be a better start
than making a whole new API, but I think doing development *WITH* IOAT and
potentially trashing all.. umm.. 4 users, and the weird Linux kernel tripling
of development cost when heavily updating an actively maintained subsystem
that everyone else wants to touch, that would be detrimental. We don't want
to break Intel and we don't want to be tracking Intel's patches or having
extra weirdness break in (or for the number of users of that DMA system to
explode underneath New DMA Development)
--
Matt Sealey <matt@genesi-usa•com>
Genesi, Manager, Developer Relations
next prev parent reply other threads:[~2007-06-25 21:19 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
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 [this message]
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=4680319A.5050503@genesi-usa.com \
--to=matt@genesi-usa$(echo .)com \
--cc=arnd@arndb$(echo .)de \
--cc=clifford@clifford$(echo .)at \
--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