From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ira W. Snyder <iws@ovro.caltech.edu>
Date: Wed, 8 Jul 2009 16:13:06 -0700
Subject: [U-Boot] [PATCH 0/3] DMA ECC update
In-Reply-To: <1247093973.11207.229.camel@localhost.localdomain>
References: <1247081322-22392-1-git-send-email-ptyser@xes-inc.com>
	<20090708223129.GF2827@ovro.caltech.edu>
	<1247093973.11207.229.camel@localhost.localdomain>
Message-ID: <20090708231306.GH2827@ovro.caltech.edu>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Wed, Jul 08, 2009 at 05:59:33PM -0500, Peter Tyser wrote:
> On Wed, 2009-07-08 at 15:31 -0700, Ira W. Snyder wrote:
> > On Wed, Jul 08, 2009 at 02:28:39PM -0500, Peter Tyser wrote:
> > > These changes bring the 83xx SDRAM ECC initialization in line
> > > with the 85xx/86xx boards and also fixes a minor bug in fsl_dma.c.
> > > 
> > > I don't have any 83xx boards to test on, so it would be appreciated
> > > if someone with 83xx hardware that uses ECC could give the patches
> > > a shot.
> > > 
> > > It'd be nice if SDRAM could be initialized via the DDR controller
> > > with CONFIG_ECC_INIT_VIA_DDRCONTROLLER on the 83xx platform too,
> > > but I'm not going to tackle it:)
> > > 
> > > The patches also resolve the compile error Stefan brought up with
> > > non-freescale boards with CONFIG_ECC.
> > > 
> > > Peter Tyser (3):
> > >   83xx: Default to using DMA to initialize SDRAM
> > >   83xx: Added CONFIG_MEM_INIT_VALUE for boards with ECC
> > >   fsl_dma: Fix SDRAM initial value
> > > 
> > 
> > Something in this patch makes the ECC DDR initialization VERY slow. It
> > used to take <5 seconds, now it takes ~20 seconds for the memory to
> > initialize.
> > 
> > I wonder why the CPU method would be so much faster?
> > 
> > Other than the speed, I can confirm that it works as expected on my
> > 8349emds-based board. I see no reason why there would be a problem on
> > the mpc8349emds, though I cannot test on the eval board itself. I do not
> > have an ECC SDRAM module.
> 
> Thanks for testing Ira.  The original code had the instruction cache
> enabled during SDRAM init, but it'd be pretty amazing if it gave that
> much performance boost.  I would have guessed that the DMA init would
> have been faster even without the icache enabled.
> 
> If you have a second, could you try adding this patch on top of the
> previous ones?  It'd be interesting to see where the bottleneck is with
> and without the icache...
> 

It didn't apply cleanly (I'm not sure why), but I applied it (fixed the
missing semicolon).

It makes the DMA initialization normal speed again. The DMA in the for
loop takes the longest (as expected).

So yes, strangely it makes a HUGE difference. The total time is <3
seconds now. It is now faster than the previous CPU method.

Ira

> Thanks,
> Peter
> 
> 
> diff --git a/drivers/dma/fsl_dma.c b/drivers/dma/fsl_dma.c
> index f07b25c..24b31c7 100644
> --- a/drivers/dma/fsl_dma.c
> +++ b/drivers/dma/fsl_dma.c
> @@ -148,6 +148,8 @@ void dma_meminit(uint val, uint size)
>         uint *p = 0;
>         uint i = 0;
>  
> +icache_enable()
> +printf("%d\n", __LINE__);
>         for (*p = 0; p < (uint *)(8 * 1024); p++) {
>                 if (((uint)p & 0x1f) == 0)
>                         ppcDcbz((ulong)p);
> @@ -157,6 +159,7 @@ void dma_meminit(uint val, uint size)
>                 if (((uint)p & 0x1c) == 0x1c)
>                         ppcDcbf((ulong)p);
>         }
> +printf("%d\n", __LINE__);
>  
>         dmacpy(0x002000, 0, 0x002000); /* 8K */
>         dmacpy(0x004000, 0, 0x004000); /* 16K */
> @@ -169,7 +172,10 @@ void dma_meminit(uint val, uint size)
>         dmacpy(0x200000, 0, 0x200000); /* 2M */
>         dmacpy(0x400000, 0, 0x400000); /* 4M */
>  
> +printf("%d\n", __LINE__);
>         for (i = 1; i < size / 0x800000; i++)
>                 dmacpy((0x800000 * i), 0, 0x800000);
> +printf("%d\n", __LINE__);
> +icache_disable();
>  }
>  #endif
> 
>