MPC85xx DMA support for Kernel 2.6?

Hello!

I am planning to use DMA/burst access for copying large chunks of data
(100MBytes) from the Local Bus (UPM accessed SRAM) to System Memory (DDR)
as fast as possible (200MBytes/s). (As you can guess, that's a framegrabber).

As far as I have seen, the DMA engines of the MPC85xx (fsl-dma) are not
supported in the classical way (dma_request(), free_dma()) in the kernel 2.6.x.
The memory allocators in arch/ppc/dma-mapping.c seem to be usable,
but there is no valuable dma support yet (true?).

I can program the DMA Controllers in my MPC8540 on my own to achieve what I want
but it would be great to get/produce/stick with as much cross-platform reusable
code as possible.

Is there any ongoing work to put DMA support for the mpc85xx and similar
devices into the kernel? Is there any ongoing work in this area
or is somebody working with the fsl-dma and can publish some code and
share some ideas?

Best greets,

Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19

On Jun 30, 2005, at 10:12 AM, Clemens Koller wrote:

Hello!

I am planning to use DMA/burst access for copying large chunks of data
(100MBytes) from the Local Bus (UPM accessed SRAM) to System Memory  
(DDR)
as fast as possible (200MBytes/s). (As you can guess, that's a  
framegrabber).

As far as I have seen, the DMA engines of the MPC85xx (fsl-dma) are  
not
supported in the classical way (dma_request(), free_dma()) in the  
kernel 2.6.x.
The memory allocators in arch/ppc/dma-mapping.c seem to be usable,
but there is no valuable dma support yet (true?).

I can program the DMA Controllers in my MPC8540 on my own to  
achieve what I want
but it would be great to get/produce/stick with as much cross- 
platform reusable
code as possible.

Is there any ongoing work to put DMA support for the mpc85xx and  
similar
devices into the kernel? Is there any ongoing work in this area
or is somebody working with the fsl-dma and can publish some code and
share some ideas?

I'm not aware of anyone work on such a thing.  I'd be more than happy  
to accept patches for it.  I know several of us have written some  
APIs on top of the DMA for 85xx.  Those however are non-standard APIs.

What APIs exist for general purpose DMA engines?  Last time I looked  
at this problem nothing really existed.

- kumar

Hi, Kumar...

I'm not aware of anyone work on such a thing.

*Sigh*... no holiday for me this summer .-(

I'd be more than happy  
to accept patches for it.  I know several of us have written some  APIs 
on top of the DMA for 85xx.  Those however are non-standard APIs.

But is there any code available for recycling?
Are there any Freescale-FAE's with some snippets?
(Hello, world!)
I am about to start more or less from scratch and re-invent the wheel.

What APIs exist for general purpose DMA engines?  Last time I looked  at 
this problem nothing really existed.

:-) I was wondering about that, too...
Maybe we can get some basics from this one:
Linux/Documentation/DMA-API.txt

And, well, code from:
asm-ppc/ppc4xx_dma.h
arch/ppc/syslib/ppc4xx_sgdma.c
and from the pci.h subsystem.

Hmm... and there is the factor that it's difficult to get
resources in my project for all that. :-(((

Best greets,

Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19

On Jun 30, 2005, at 11:56 AM, Clemens Koller wrote:

*Sigh*... no holiday for me this summer .-(

Before you start, just make sure such a thing is really a performance
enhancement.  Yes, the DMA does run in parallel with the core, but often
the overhead of the set up and clean up interrupt is more code and time
that if you just copied the data in a loop.  If possible, integrate the 
DMA
processing into other driver work, clean up a previous DMA the next time
the driver needs to use it, not with a separate completion handler.

Thanks.

	-- Dan

Hi, Dan!

Dan Malek wrote:

Before you start, just make sure such a thing is really a performance
enhancement.  Yes, the DMA does run in parallel with the core, but often
the overhead of the set up and clean up interrupt is more code and time
that if you just copied the data in a loop.  If possible, integrate the DMA
processing into other driver work, clean up a previous DMA the next time
the driver needs to use it, not with a separate completion handler.

Well... thanks. But the CPU is intended to do image processing while
data comes in. And currently, when I access (memcopy) the SRAM on my
Local Bus via UPM I cannot get it to generate bursts yet, so I hope the
DMA will speed up those things, too.

Greets,

Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19

On Jul 1, 2005, at 3:47 AM, Clemens Koller wrote:

.... And currently, when I access (memcopy) the SRAM on my
Local Bus via UPM I cannot get it to generate bursts yet, so I hope the
DMA will speed up those things, too.

If the CPU won't do it, the DMA won't either.  You better get that
UPM working first :-)


	-- Dan

On Jul 1, 2005, at 3:47 AM, Clemens Koller wrote:

quoted

.... And currently, when I access (memcopy) the SRAM on my
Local Bus via UPM I cannot get it to generate bursts yet, so I hope the
DMA will speed up those things, too.

If the CPU won't do it, the DMA won't either.  You better get that
UPM working first :-)


-- Dan

Is the SRAM being cached?  I don't think the CPU will generate bursts
unless it's cached, right?

Mark Chambers

On Jul 1, 2005, at 10:15 AM, Mark Chambers wrote:

Is the SRAM being cached?  I don't think the CPU will generate bursts
unless it's cached, right?

I don't really remember :-)  I know the 8xx will not burst if the line 
isn't
cached, and I know the 7xxx will.  I thought the 82xx and 85xx would
also burst if you had sufficient sequential operations queued.  On
83/85xx you have to further qualify the discussion based upon the DDR2
or the local bus interface :-)  The CPM and DMA will burst on all
buses for 8xx/82xx/83xx/85xx if the memory controller is configured
to do so.

I always end up writing code to test it, then those brain cells get
replaced by more meaningful experiences before I have to use
them again :-)

Thanks.


	-- Dan

Hi, Dan and Mark!

Dan Malek wrote:

On Jul 1, 2005, at 10:15 AM, Mark Chambers wrote:

quoted

Is the SRAM being cached?  I don't think the CPU will generate bursts
unless it's cached, right?

I don't really remember :-)  I know the 8xx will not burst if the line 
isn't
cached, and I know the 7xxx will.  I thought the 82xx and 85xx would
also burst if you had sufficient sequential operations queued.  On
83/85xx you have to further qualify the discussion based upon the DDR2
or the local bus interface :-)  The CPM and DMA will burst on all
buses for 8xx/82xx/83xx/85xx if the memory controller is configured
to do so.

Thanks, for your comments! I'll have a look at it during the
next days and let you know about my mileage :-)

Greets,

Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19