RE: [PATCH] MTD-NAND: Changes to read_page APIs to supportNAND_ECC_HW_SYNDROME mode on TI DaVinci DM355

[Thomas Gleixner]

On Tue, 7 Apr 2009, Narnakaje, Snehaprabha wrote:
> > And that's exactly what these patches do:  enable just such choices.
> > The $SUBJECT patch would be needed to use NAND_ECC_HW with this 4-bit
> > ECC hardware, and not be forced to "choose" the infix-OOB policy.
>
> I had looked read_page/write_page APIs of the NAND_ECC_HW mode to
> see if we can use this mode for DaVinci DM355 device.
> 
> The read_page handler for NAND_ECC_HW mode reads the data and ECC
> from hardware for each chunk. It then reads the OOB and extracts ecc
> code from it, before using the ECC from hardware and ecc code from
> OOB for data correction.
>
> On DaVinci DM355 device, we need to pass the ecc code/syndrome
> extracted from OOB area, in order to read the HW ECC for each data
> chunk. This is where we differ from NAND_ECC_HW mode.

I have to admit that I'm slightly confused. Is the below description
correct?

On write you generate the ECC via hardware and store it in the OOB
area, right ?

On read you read the oob data first and extract the ECC. Then you feed
the extracted ECC into the HW generator and read the data. Is this
correct ?

> The read_page/write_page APIs for NAND_ECC_HW_SYNDROME have the
> other problem that David mentioned - overwriting NAND manufacturers
> bad block meta data, when used with large page NAND chips. These
> APIs do not handle the "eccsteps" properly. The OOB is read/written
> after every data chunk, thus you actually have overwritten the
> factory bad block information, when these APIs handle the last data
> chunk. OOB should be read/written after the entire data (a page) is
> read/written.

Again, that is _how_ the NAND_ECC_HW_SYNDROME functions work. And if
your hardware needs a completely different mode, then we need to
analyse what's the best solution for it.

Right now the provided information is way to diffuse to do that.

You provided a patch without explaining what your hardware needs and
showing how the actual user of the modified API looks like and how the
functionality is implemented.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/