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
