Hi,
I'm curently working on an embedded project using the Freescale MPC8349E
microcontroller (PPC e300 core + almost everything one needs for
communicating with the rest of the world on one ~100$ chip).
One feature of that microcontroller is a generic memory-2-memory four
channel dma controller. Unlike the PC 8237 DMA controller (which copies
data between the memory and dedicated DMA channels) the memory-2-memory
DMA controller of the MPC8349E can copy between any bus addresses and thus
can be used for copying data from one memory area to another, between
memory and periphery mapped on bus addresses as well as from one peripheral
device on the bus to another. The MPC8349E has four DMA channels which
(unlike the PC 8237 DMA) are not bound to be used exclusively for dma
transfers from or to a dedicated peripheral device.
I doubt that the MPC8349E is the only device out there with such a DMA
controller and so I was looking for a generalized kernel API for working
with such DMA controllers to add MPC8349E support to it (since grepping
the kernel for the register addresses didn't show up any usefull results
I assume that there is no existing implementaion).
Has anyone thought already about an API fur such a generic kernel
framework? I was thinking about a 'copy using DMA if possible' function
which is first sleeping until a DMA channel gets free, then reprograms
this channel and again sleeps until the DMA transfer has been finished.
The MPC8349E has scatter-gather features for source and destination and can
eighter increment the source/destination addresses during the transfer or
run in (8, 16 or 32 bit) fifo mode. So it is a bit more complicated than
a 'memcpy on bus addresses which may sleep'.
Extending the request_dma() - free_dma() API looks like the wrong way to go
on this issue. It is afaics designed for a compleatly diffrent kind of DMA
controller.
Any thoughts? Am I completely missing something?
yours,
- clifford
--
For extra security, this message has been encrypted with double-ROT13.
Hello, Clifford!
Clifford Wolf schrieb:
> I'm curently working on an embedded project using the Freescale MPC8349E
> microcontroller (PPC e300 core + almost everything one needs for
> communicating with the rest of the world on one ~100$ chip).
Yes. These embedded CPU's are discussed more in detail in the
linux-ppc-embedded mailing list. See:
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Let's please move the implementation details to that list.
> I doubt that the MPC8349E is the only device out there with such a DMA
> controller and so I was looking for a generalized kernel API for working
> with such DMA controllers to add MPC8349E support to it (since grepping
> the kernel for the register addresses didn't show up any usefull results
> I assume that there is no existing implementaion).
I am using the MPC8540 and (re-)wrote a DMA driver to copy bulk image data
from a local bus FPGA to the dram memory. So, it's a proprietary driver
which can be published, but I think it doesn't make sense to have that
code in the kernel because it's only useful with exaxtly this one hardware
environment.
> Has anyone thought already about an API fur such a generic kernel
> framework? I was thinking about a 'copy using DMA if possible' function
> which is first sleeping until a DMA channel gets free, then reprograms
> this channel and again sleeps until the DMA transfer has been finished.
Please checkout the linux/Documentation/DMA* documents.
I don't know if it makes sense to do a *generic* implementation without
limitations in functionality and safety.
> The MPC8349E has scatter-gather features for source and destination and can
> eighter increment the source/destination addresses during the transfer or
> run in (8, 16 or 32 bit) fifo mode. So it is a bit more complicated than
> a 'memcpy on bus addresses which may sleep'.
> Extending the request_dma() - free_dma() API looks like the wrong way to go
> on this issue. It is afaics designed for a compleatly diffrent kind of DMA
> controller.
The scatter-gather setup implementation is working fine on my platform.
After setup/start of the DMA engine, I can poll some progress information
during the transfer to start processing of the data while the DMA machine still
sucks some more data in. At the end of the sg list, I get an interrupt and
the DMA channel is free again. Several (4) concurrent transfers should be
possible with this setup. However, some DMA-channel scheduling needs to be
implemented and made available in a generic kernel (or even userspace)
interface.
Regards,
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm-technology.com
Phone: +49-89-741518-50
Fax: +49-89-741518-19