| Message ID | 1389190924-26226-2-git-send-email-b.brezillon@overkiz.com |
|---|---|
| State | Superseded |
| Headers | show |
+ Huang Hi Boris, On Wed, Jan 08, 2014 at 03:21:56PM +0100, Boris BREZILLON wrote: > The Hynix nand flashes store their ECC requirements in byte 4 of its id > (returned on READ ID command). > > Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com> I haven't verified yet (perhaps Huang can confirm?), but this may be similar to a patch Huang submitted recently. In his case, we found that this table is actually quite unreliable and is likely hard to maintain. Why do you need this ECC information, for my reference? Brian
Hello Brian, On 23/01/2014 02:49, Brian Norris wrote: > + Huang > > Hi Boris, > > On Wed, Jan 08, 2014 at 03:21:56PM +0100, Boris BREZILLON wrote: >> The Hynix nand flashes store their ECC requirements in byte 4 of its id >> (returned on READ ID command). >> >> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com> > I haven't verified yet (perhaps Huang can confirm?), but this may be > similar to a patch Huang submitted recently. In his case, we found that > this table is actually quite unreliable and is likely hard to maintain. You mean these bytes are not reliable within the whole Hynix LP (Large Page) NAND product line ? > > Why do you need this ECC information, for my reference? Because the NAND flash available on the cubietruck board does not support the ONFI standard, and I thought this could be a option to retrieve the ECC strength requirements. Anyway, I added a new helper function to retrieve ecc informations from device tree (I'll post it in the 2nd version of this series). We'll see if this approach is accepted... > > Brian
Hello Brian, On 23/01/2014 02:49, Brian Norris wrote: > + Huang > > Hi Boris, > > On Wed, Jan 08, 2014 at 03:21:56PM +0100, Boris BREZILLON wrote: >> The Hynix nand flashes store their ECC requirements in byte 4 of its id >> (returned on READ ID command). >> >> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com> > I haven't verified yet (perhaps Huang can confirm?), but this may be > similar to a patch Huang submitted recently. In his case, we found that > this table is actually quite unreliable and is likely hard to maintain. Indeed (as stated in this thread http://comments.gmane.org/gmane.linux.drivers.mtd/50252). I'll remove this patch from the next version of this series and make use of the nand-ecc-strength /nand-ecc-size DT properties instead. Thanks. Best Regards, Boris > > Why do you need this ECC information, for my reference? > > Brian
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index bd39f7b..15069ec 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -3202,6 +3202,43 @@ static void nand_decode_ext_id(struct mtd_info *mtd, struct nand_chip *chip, else mtd->erasesize = (64 * 1024) << tmp; *busw = 0; + + /* Retrieve ECC infos */ + switch ((id_data[4] >> 4) & 0x7) { + case 1: + chip->ecc_step_ds = 512; + chip->ecc_strength_ds = 1; + break; + case 2: + chip->ecc_step_ds = 512; + chip->ecc_strength_ds = 2; + break; + case 3: + chip->ecc_step_ds = 512; + chip->ecc_strength_ds = 4; + break; + case 4: + chip->ecc_step_ds = 512; + chip->ecc_strength_ds = 8; + break; + case 5: + chip->ecc_step_ds = 1024; + chip->ecc_strength_ds = 24; + break; + case 6: + chip->ecc_step_ds = 1024; + chip->ecc_strength_ds = 32; + break; + case 7: + chip->ecc_step_ds = 1024; + chip->ecc_strength_ds = 40; + break; + case 0: + default: + chip->ecc_step_ds = 0; + chip->ecc_strength_ds = 0; + break; + } } else { /* Calc pagesize */ mtd->writesize = 1024 << (extid & 0x03);
The Hynix nand flashes store their ECC requirements in byte 4 of its id (returned on READ ID command). Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com> --- drivers/mtd/nand/nand_base.c | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+)