| Message ID | 1385976026-31606-1-git-send-email-b32955@freescale.com |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Dec 02, 2013 at 05:20:26PM +0800, Huang Shijie wrote: > Parse out the datasheet's required minimum ECC for Hynix nand chips which > use the >=26 technology and the id length is 6. > > Referencd to the H27UBG8T2B. > > Signed-off-by: Huang Shijie <b32955@freescale.com> > --- > drivers/mtd/nand/nand_base.c | 20 ++++++++++++++++++++ > 1 files changed, 20 insertions(+), 0 deletions(-) > > diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c > index 4dab696..5c1ffd0 100644 > --- a/drivers/mtd/nand/nand_base.c > +++ b/drivers/mtd/nand/nand_base.c > @@ -3201,6 +3201,26 @@ static void nand_decode_ext_id(struct mtd_info *mtd, struct nand_chip *chip, > mtd->erasesize = 768 * 1024; > else > mtd->erasesize = (64 * 1024) << tmp; > + > + /* ecc info */ s/ecc/ECC/ ECC is an acronym and should be capitalized. > + tmp = (id_data[4] >> 4) & 0x7; This calculation (and several others) are similar between >= and < 26nm. I think it could help to split out a separate Hynix MLC function for decoding these together, with the shared calculations pulled outside (i.e., for extracting the ECC and block size bitfields; and for setting the buswidth to x8). > + > + if (tmp <= 4) { > + if (tmp == 0) > + chip->ecc_strength_ds = 0; > + else > + chip->ecc_strength_ds = 1 << (tmp - 1); The above 4 lines could be simplified to: chip->ecc_strength_ds = (1 << tmp) >> 1; > + chip->ecc_step_ds = 512; > + } else { > + chip->ecc_step_ds = 1024; > + if (tmp == 5) > + chip->ecc_strength_ds = 24; > + else if (tmp == 6) > + chip->ecc_strength_ds = 32; > + else /* (tmp == 7) */ > + chip->ecc_strength_ds = 40; This ECC table looks incorrect. It matches my datasheet for H27UBG8T2B (26nm) but it is incorrect for my H27UBG8T2A (32nm). My datasheet says: 0 ==> 1-bit/512-bytes 1 ==> 2-bits/512-bytes 2 ==> 4-bits/512-bytes 3 ==> 8-bits/512-bytes 4 ==> 16-bits/512-bytes 5 ==> 24-bits/2048-bytes 6 ==> 24-bits/1024-bytes 7 ==> Reserved Not sure if that's a preliminary version that changed for production (the datasheet is Rev 0.6, from 2009; I don't have samples on hand for this one), but this demonstrates the larger problem I have with this patch series... ...that keeping track of minimum ECC requirements is not a scalable practice for all flash, especially those that avoid using any proper standards. It's difficult enough just getting OOB/page/block sizes correct without adding this to the mix. If we add one more thing to get wrong (ECC strength/step), we become increasingly fragile. Furthermore, it seems that GPMI is the only driver that needs this information in Linux. All other systems determine these things within their bootloader, or through some restriction on the devices they support (e.g., only support Hamming ECC). So it doesn't seem 100% clear that we *must* detect the minimum ECC properties in nand_base. In fact, you even agreed (in another thread) that gpmi-nand should probably define a more precise nand-ecc-strength and nand-ecc-step-size binding; such a binding could eliminate the need for runtime auto-detection. Now, I'm not against progressively adding ECC information that we are sure to get correct -- like we did with ONFI and with the full-ID table entries we add. But unless we can get better guarantees from vendors like Hynix [1], I don't want to commit to this approach, and I'd prefer not committing any drivers to relying on autodetecting this information. [1] For instance, can you (or Hynix) explain why my H27UBG8T2A conflicts with this table you provided? Do we have to generate a new ECC table for every generation?? (48nm, 41nm, 32nm, 26nm, ...) > + } > + > *busw = 0; > } else if (id_len == 6 && id_data[0] == NAND_MFR_HYNIX && > !nand_is_slc(chip) && (id_data[5] & 0x7) > 3) { Brian
On Thu, Dec 19, 2013 at 10:44:07PM -0800, Brian Norris wrote: > On Mon, Dec 02, 2013 at 05:20:26PM +0800, Huang Shijie wrote: > > Parse out the datasheet's required minimum ECC for Hynix nand chips which > > use the >=26 technology and the id length is 6. > > > > Referencd to the H27UBG8T2B. > > > > Signed-off-by: Huang Shijie <b32955@freescale.com> > > --- > > drivers/mtd/nand/nand_base.c | 20 ++++++++++++++++++++ > > 1 files changed, 20 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c > > index 4dab696..5c1ffd0 100644 > > --- a/drivers/mtd/nand/nand_base.c > > +++ b/drivers/mtd/nand/nand_base.c > > + chip->ecc_step_ds = 512; > > + } else { > > + chip->ecc_step_ds = 1024; > > + if (tmp == 5) > > + chip->ecc_strength_ds = 24; > > + else if (tmp == 6) > > + chip->ecc_strength_ds = 32; > > + else /* (tmp == 7) */ > > + chip->ecc_strength_ds = 40; > > This ECC table looks incorrect. It matches my datasheet for H27UBG8T2B > (26nm) but it is incorrect for my H27UBG8T2A (32nm). My datasheet says: I do not a H27UBG8T2A chip, it is a bad news to me. why Hynix can not keep the same syntax? I will abandon the ECC info in the next version. > > 0 ==> 1-bit/512-bytes > 1 ==> 2-bits/512-bytes > 2 ==> 4-bits/512-bytes > 3 ==> 8-bits/512-bytes > 4 ==> 16-bits/512-bytes > 5 ==> 24-bits/2048-bytes > 6 ==> 24-bits/1024-bytes > 7 ==> Reserved > > Not sure if that's a preliminary version that changed for production > (the datasheet is Rev 0.6, from 2009; I don't have samples on hand for > this one), but this demonstrates the larger problem I have with this > patch series... > > ...that keeping track of minimum ECC requirements is not a scalable > practice for all flash, especially those that avoid using any proper > standards. It's difficult enough just getting OOB/page/block sizes > correct without adding this to the mix. If we add one more thing to get > wrong (ECC strength/step), we become increasingly fragile. > > Furthermore, it seems that GPMI is the only driver that needs this not the only. The atmel-nand.c also uses it. > information in Linux. All other systems determine these things within > their bootloader, or through some restriction on the devices they > support (e.g., only support Hamming ECC). So it doesn't seem 100% clear > that we *must* detect the minimum ECC properties in nand_base. In fact, > you even agreed (in another thread) that gpmi-nand should probably > define a more precise nand-ecc-strength and nand-ecc-step-size binding; > such a binding could eliminate the need for runtime auto-detection. yes. you can add the new DTs when you are free. Or I add it when i finish my job in my hands. thanks Huang Shijie
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 4dab696..5c1ffd0 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -3201,6 +3201,26 @@ static void nand_decode_ext_id(struct mtd_info *mtd, struct nand_chip *chip, mtd->erasesize = 768 * 1024; else mtd->erasesize = (64 * 1024) << tmp; + + /* ecc info */ + tmp = (id_data[4] >> 4) & 0x7; + + if (tmp <= 4) { + if (tmp == 0) + chip->ecc_strength_ds = 0; + else + chip->ecc_strength_ds = 1 << (tmp - 1); + chip->ecc_step_ds = 512; + } else { + chip->ecc_step_ds = 1024; + if (tmp == 5) + chip->ecc_strength_ds = 24; + else if (tmp == 6) + chip->ecc_strength_ds = 32; + else /* (tmp == 7) */ + chip->ecc_strength_ds = 40; + } + *busw = 0; } else if (id_len == 6 && id_data[0] == NAND_MFR_HYNIX && !nand_is_slc(chip) && (id_data[5] & 0x7) > 3) {
Parse out the datasheet's required minimum ECC for Hynix nand chips which use the >=26 technology and the id length is 6. Referencd to the H27UBG8T2B. Signed-off-by: Huang Shijie <b32955@freescale.com> --- drivers/mtd/nand/nand_base.c | 20 ++++++++++++++++++++ 1 files changed, 20 insertions(+), 0 deletions(-)