Mem-2-Mem DMA - Generalized API

[Matt Sealey]

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 at genesi-usa.com>
Genesi, Manager, Developer Relations