From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2] MTD:NAND: ADD new ECC mode NAND_ECC_HW_OOB_FIRST
Date: Tue, 01 Sep 2009 14:19:09 -0500 [thread overview]
Message-ID: <4A9D73AD.6060506@freescale.com> (raw)
In-Reply-To: <0554BEF07D437848AF01B9C9B5F0BC5D9217B2F9@dlee01.ent.ti.com>
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
next prev parent reply other threads:[~2009-09-01 19:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <7081825318460577925@unknownmsgid>
2009-09-01 15:22 ` [U-Boot] [PATCH 2/2] MTD:NAND: ADD new ECC mode NAND_ECC_HW_OOB_FIRST John Rigby
2009-09-01 15:36 ` Scott Wood
2009-09-01 16:03 ` Paulraj, Sandeep
2009-09-01 16:31 ` John Rigby
[not found] ` <0554BEF07D437848AF01B9C9B5F0BC5D9217B3B7@dlee01.ent.ti.com>
2009-09-01 16:55 ` John Rigby
2009-09-01 19:19 ` Scott Wood [this message]
2009-09-01 19:59 ` Matt Waddel
2009-09-01 20:06 ` Scott Wood
2009-08-18 16:00 Scott Wood
-- strict thread matches above, loose matches on Subject: below --
2009-08-11 22:34 Scott Wood
2009-08-12 11:48 ` Paulraj, Sandeep
2009-08-12 16:11 ` Scott Wood
[not found] ` <0554BEF07D437848AF01B9C9B5F0BC5D7C628A5C@dlee01.ent.ti.com>
2009-08-12 17:11 ` Scott Wood
2009-08-14 14:03 ` Paulraj, Sandeep
2009-08-11 22:17 Scott Wood
2009-08-10 17:27 s-paulraj at dal.design.ti.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A9D73AD.6060506@freescale.com \
--to=scottwood@freescale.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox