From mboxrd@z Thu Jan  1 00:00:00 1970
From: Matt Waddel <mwaddel@control4.com>
Date: Tue, 1 Sep 2009 13:59:51 -0600
Subject: [U-Boot]
 =?iso-8859-1?q?=5BPATCH_2/2=5D_MTD=3ANAND=3A_ADD_new_ECC?=
 =?iso-8859-1?q?_mode=09NAND=5FECC=5FHW=5FOOB=5FFIRST?=
In-Reply-To: <4A9D73AD.6060506@freescale.com>
References: <7081825318460577925@unknownmsgid>
	<0554BEF07D437848AF01B9C9B5F0BC5D9217B2F9@dlee01.ent.ti.com>
	<4A9D73AD.6060506@freescale.com>
Message-ID: <200909011359.52037.mwaddel@control4.com>
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

Hi Scott and Sandeep,

As long as we're looking at these patches again I had a question about 
patch 1 of 2 in this series.  

The following part of the patch added a definition for: 

chip->ecc.read_page = nand_read_page_hwecc_oob_first

but since there aren't any "break" statements until "case NAND_ECC_SOFT:" 
it looks like the chip->ecc.read_page definition ends up being set to:

chip->ecc.read_page = nand_read_page_swecc.

Maybe this is explains why things seem to be working???

Best regards,
Matt

+   case NAND_ECC_HW_OOB_FIRST:
+           /* Similar to NAND_ECC_HW, but a separate read_page handle */
+           if (!chip->ecc.calculate || !chip->ecc.correct ||
+                !chip->ecc.hwctl) {
+                   printk(KERN_WARNING "No ECC functions supplied, "
+                          "Hardware ECC not possible\n");
+                   BUG();
+           }
+           if (!chip->ecc.read_page)
+                   chip->ecc.read_page = nand_read_page_hwecc_oob_first;
+


On Tuesday 01 September 2009 01:19:09 pm Scott Wood wrote:
> Paulraj, Sandeep wrote:
> >> John Rigby wrote:
> >>> Sorry for the late comments.  We have been trying to use this code with
> >>> the associated davinci 4-bit ecc patches and have some questions
> > We use this internally and it works. Are you having any issues because we don't see any!!
> 
> Calm down, just because it works doesn't mean nobody should ask 
> questions about the code.
> 
> >>> Here you calculate ecc then never use the result?
> >> Hmm, that looks wrong, both here and in the davinci driver.  Are the two
> >> calls to nand_davinci_4bit_readecc reading different things?  Does the
> >> calculate function have any side effects beyond producing data that is
> >> never used?
> > Have you reads the patch description. Maybe that might help a bit
> > 
> > This patch adds the new mode NAND_ECC_HW_OOB_FIRST in the nand code to
> > support 4-bit ECC on TI DaVinci devices with large page (up to 2K) NAND
> > chips.  This ECC mode is similar to NAND_ECC_HW, with the exception of
> > read_page API that first reads the OOB area, reads the data in chunks,
> > feeds the ECC from OOB area to the ECC hw engine and perform any
> > correction on the data as per the ECC status reported by the engine.
> 
> Yes, I've read that.  That doesn't explain why calculate_ecc is 
> producing data, *after* everything has been read, that is never consumed 
> by anything (hardware or software) AFAICT.  It doesn't explain why the 
> "generic" code is passing NULL to ecc.correct.
> 
> -Scott
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>