Mem-2-Mem DMA - Generalized API

Clifford Wolf clifford at clifford.at
Mon Jun 25 18:03:16 EST 2007


Hi,

On Sun, Jun 24, 2007 at 10:21:57PM +0200, Arnd Bergmann wrote:
> On Sunday 24 June 2007, Clifford Wolf wrote:
> > I'm working on an MPC8349E based project and as some of you might know this
> > chip has a four channel (bus-) memory-to-memory DMA controller.
> > 
> > Unfortunately the linux kernel is atm lacking a generic interface for such
> > DMA controllers.
> 
> So what's wrong with the include/linux/dmaengine.h API? I thought it was
> designed to cover this sort of DMA controller?

nothing. I was just to blind to find it..  ;-)

though there are some points:

on the first glimpse it seams like this api does not support scatter/gather
and fifo mode, right? in fact that's no problem at all for my project but
it would be a pity to lose that hardware functionality because of the api..

i have also had a quick look at the ioatdma driver and it apears to me that
it can only operate on address regions which are visible on the pci bus.
The MPC8349E dma can operate on everything which is visible on the coherent
local bus, i.e. everything that is also visible to the cpu. there seams to
be no way to specify the bus a dma channel is needed for when requesting a
channel thru this interface.

It also appears to me that the dmaengine.h API is not capable of
overcommiting. I.e. assigning a small pool of dma channels to a big pool of
drivers in the hope that not all of the drivers are doing dma transfers at
the same time (and schedule transfers if this assumtion turns out to be
wrong).

Wouldn't it be better to let the backend handle stuff like binding dma
channels to specific cpus and let the user just commit dma requests which
are then scheduled to the dma channel which fits the needs best (or done in
cpu if no dma channel exists which would be capable of doing this kind of
transfer)?

yours,
 - clifford

-- 
"The generation of random numbers is too important to be left to chance."
 - Robert R. Coveyou, Oak Ridge National Laboratory.



More information about the Linuxppc-embedded mailing list