[PATCH] mtd: nand: gpmi: Fix ecc strength calculation

[Sascha Hauer]

On Tue, Jun 21, 2016 at 10:52:09AM -0500, Han Xu wrote:
> On Tue, Jun 21, 2016 at 9:46 AM, Boris Brezillon
> <boris.brezillon at free-electrons.com> wrote:
> > On Tue, 21 Jun 2016 16:35:49 +0200
> > Sascha Hauer <s.hauer at pengutronix.de> wrote:
> >
> >> BCH ECC correction works in chunks of 512 bytes, so a 2k page size nand
> >> is divided into 4 chunks. Hardware requires that each chunk has a full
> >> number of bytes, so when we need 9 bits per chunk we must round up to
> >> two bytes. The current code misses that and calculates a ECC strength
> >> of 18 for a 2048+128 byte page size NAND. ECC strength of 18 requires
> >> 30 bytes per chunk, so a total of 4 * (512 + 30) + 10 = 2178 bytes when
> >> the device only has a page size of 2176 bytes.
> >
> > AFAIR, the GPMI/ECC engine operates at the bit level (which is a pain
> > to deal with BTW), and is only requiring a byte alignment on the total
> > number of ECC bits. So here, DIV_ROUND_UP(18 * 13 * 4, 8) = 117, which
> > fits in the 118 bytes (128 bytes - 10 bytes of 'metadata').
> >
> > Han, can you confirm that?
> 
> Correct, BCH module works at bit level, 18bit ECC won't exceed the oob size.

I see, only subpage reads fail here in my case. The driver does only subpage
reads when the ECC size is byte aligned. This completely disables the subpage
read feature on certain Nand types. Is that really what we want?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |