From: Clemens Koller <clemens.koller@anagramm.de>
To: Kumar Gala <kumar.gala@freescale.com>
Cc: linuxppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: Re: MPC8540 DMA routines (channel 0 broken?)
Date: Tue, 19 Jul 2005 15:27:21 +0200 [thread overview]
Message-ID: <42DCFFB9.3050109@anagramm.de> (raw)
In-Reply-To: <550C0481-4DD8-4AFC-AFA2-13AAEBD055E5@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]
Hello, Kumar!
> Glad to see that the issue was software. If there is something going
> on in u-boot during init that isn't leaving the DMA channel in a clean
> state let me know.
The MPC8540RM.pdf says: 15.4.1.1.1:
4. _Clear_and_then_set_ the mode register channel start bit, MRn[CS],
to start the DMA transfer
The exact problem was that Jason's original code cleared
the DMA.MR0 register to 0x00000000 in the interrupt service handler
_after_ each transaction.
Then the MR can get re-programmed along with the CS bit (Channel Start)
set at once and everything is fine.
But if MR0 didn't get cleared before that, the DMA won't start.
So, u-boot just didn't clear MR0[CS] _after_ a transaction, too.
The attached patch for u-boot would put in more safety to avoid
things like that in the future. It's optional, as my driver
explicitly clears the MRn[CS] now, _before_ it starts it's work.
> Also, it looks like there maybe some proposal for a general DMA engine
> API. If your interested take a look at the Linux Sympoisum 2005 papers
> (Accelerating Network Receive Processing). I'm hoping to talk to the
> guys doing this to see what their thoughts are. If you have some
> feedback on what they are proposing let me know.
I've had a look at the proposal. Thanks! I guess it shouldn't be too
difficult to implement an API like 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
[-- Attachment #2: u-boot_mpc85xx_dma_cleanup.patch --]
[-- Type: text/plain, Size: 442 bytes --]
diff -Nur u-boot/cpu/mpc85xx/cpu.c u-boot-local/cpu/mpc85xx/cpu.c
--- u-boot/cpu/mpc85xx/cpu.c 2005-07-19 14:48:37.000000000 +0200
+++ u-boot-local/cpu/mpc85xx/cpu.c 2005-07-19 14:50:46.000000000 +0200
@@ -191,6 +191,9 @@
while((status & 4) == 4) {
status = dma->sr0;
}
+ /* clear MR0[CS] channel start bit */
+ dma->mr0 &= ~0x00000001;
+ asm("sync;isync;msync");
if (status != 0) {
printf ("DMA Error: status = %x\n", status);
next prev parent reply other threads:[~2005-07-19 13:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-18 12:42 MPC8540 DMA routines (channel 0 broken?) Fillod Stephane
2005-07-18 15:44 ` Clemens Koller
2005-07-18 16:17 ` Kumar Gala
2005-07-19 13:27 ` Clemens Koller [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-07-15 15:01 Clemens Koller
2005-07-18 12:37 ` Clemens Koller
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=42DCFFB9.3050109@anagramm.de \
--to=clemens.koller@anagramm.de \
--cc=kumar.gala@freescale.com \
--cc=linuxppc-embedded@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.