MPC8540 DMA routines (channel 0 broken?)

MPC8540 DMA routines (channel 0 broken?)

[Clemens Koller]

Hello,

I am about to bring Jason McMullan's DMA routines up to linux-2.6
Currently I am in the process of getting the things started step
by step.

Until today I had a pretty hard time for some basic direct dma
transfers because it seems that dma channel 0 doesn't work at all
on my hardware (PPC8540PX833LB 2L71V MSIA QEAD0412).
The status register always stays 0x0 (means everything is happy and
okay) but it doesn't copy any data. I cannot even trigger a
programming error by a wrong configuration!
But when I let ch 1,2,3 do the work, everything
seems to work fine!
I havent found anything in the errata sheets or in the web.
Can a DMA machine crash that it stays completely unusable?
Have anybody seen similar things like that?

Some other questions:
I would also suggest to put my revised and almost
complete immap_85xx.h and the mpc85xx_dma module into the
current linux tree (Kumar?) to get things like that
started more easily.
Why is Jason's work not in the Kernel?

If you are fine with that, I can offer some patches.
But I first need to strip tons of the debug stuff from
the last two weeks. :-/

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

Re: MPC8540 DMA routines (channel 0 broken?)

[Clemens Koller]

Hello again...

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.

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

Clemens Koller wrote:
> Hello,
> 
> I am about to bring Jason McMullan's DMA routines up to linux-2.6
> Currently I am in the process of getting the things started step
> by step.
> 
> Until today I had a pretty hard time for some basic direct dma
> transfers because it seems that dma channel 0 doesn't work at all
> on my hardware (PPC8540PX833LB 2L71V MSIA QEAD0412).
> The status register always stays 0x0 (means everything is happy and
> okay) but it doesn't copy any data. I cannot even trigger a
> programming error by a wrong configuration!
> But when I let ch 1,2,3 do the work, everything
> seems to work fine!
> I havent found anything in the errata sheets or in the web.
> Can a DMA machine crash that it stays completely unusable?
> Have anybody seen similar things like that?
> 
> Some other questions:
> I would also suggest to put my revised and almost
> complete immap_85xx.h and the mpc85xx_dma module into the
> current linux tree (Kumar?) to get things like that
> started more easily.
> Why is Jason's work not in the Kernel?
> 
> If you are fine with that, I can offer some patches.
> But I first need to strip tons of the debug stuff from
> the last two weeks. :-/
> 
> 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
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

RE: MPC8540 DMA routines (channel 0 broken?)

[Fillod Stephane]

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

Re: MPC8540 DMA routines (channel 0 broken?)

[Clemens Koller]

Hello, Stephane!

>>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

Re: MPC8540 DMA routines (channel 0 broken?)

[Kumar Gala]

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!
>
>
>>> 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
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>

Re: MPC8540 DMA routines (channel 0 broken?)

[Clemens Koller]

[-- 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);