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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).