Clemens Koller wrote:
In the meanwhile, I got channel 0 working. It seems
that the DMA#0 machine got stuck in some configuration from any
previous (u-boot?) operation which didn't clean up things
properly. I had to explicitly abort a (continously running?)
transfer to be able to re-program it in the way I need.
Are you using a BDI2000?=20
Some init mode uses the DMA#0 for memory zeroing (see your .cfg file).
Also the DDR ECC U-boot code may use the DMA#0.
Isn't it possible to reset the DMA#0 from Linux?
Best regards,
--=20
Stephane
Hello, Stephane!
quoted
In the meanwhile, I got channel 0 working. It seems
that the DMA#0 machine got stuck in some configuration from any
previous (u-boot?) operation which didn't clean up things
properly. I had to explicitly abort a (continously running?)
transfer to be able to re-program it in the way I need.
Are you using a BDI2000?
Nope.
Some init mode uses the DMA#0 for memory zeroing (see your .cfg file).
Also the DDR ECC U-boot code may use the DMA#0.
Isn't it possible to reset the DMA#0 from Linux?
Thank you! Yes, that's true! <ACK>
I've checked the U-Boot code, today. The problem comes up when
U-Boot is built with CONFIG_DDR_ECC.
The DMA #0 is used to initialize the DDR prior enabling ECC.
Maybe the DMA doesn't get cleaned up properly.
(I'll have to re-check the registers).
But I can get my mpc85xx_dma "driver" working now.
However I cannot disable ECC when I am in Linux for testing
yet. :-]
I'll need to customize U-Boot without ECC because I don't want
to use it due to performance issues anyway.
But that's getting OT here.
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
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.
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.
- kumar
On Jul 18, 2005, at 10:44 AM, Clemens Koller wrote:
Hello, Stephane!
quoted
quoted
In the meanwhile, I got channel 0 working. It seems
that the DMA#0 machine got stuck in some configuration from any
previous (u-boot?) operation which didn't clean up things
properly. I had to explicitly abort a (continously running?)
transfer to be able to re-program it in the way I need.
Are you using a BDI2000?
Nope.
quoted
Some init mode uses the DMA#0 for memory zeroing (see your .cfg
file).
Also the DDR ECC U-boot code may use the DMA#0.
Isn't it possible to reset the DMA#0 from Linux?
Thank you! Yes, that's true! <ACK>
I've checked the U-Boot code, today. The problem comes up when
U-Boot is built with CONFIG_DDR_ECC.
The DMA #0 is used to initialize the DDR prior enabling ECC.
Maybe the DMA doesn't get cleaned up properly.
(I'll have to re-check the registers).
But I can get my mpc85xx_dma "driver" working now.
However I cannot disable ECC when I am in Linux for testing
yet. :-]
I'll need to customize U-Boot without ECC because I don't want
to use it due to performance issues anyway.
But that's getting OT here.
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
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
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