MPC8540 DMA routines (channel 0 broken?)

[Clemens Koller]

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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: u-boot_mpc85xx_dma_cleanup.patch
Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050719/582ec8d1/attachment.txt