[PATCH 2/4] Fine split S3C arch dependencies from generic code

[Alexey Galakhov]

On 04.05.2012 17:13, Juergen Beisert wrote:
> AFAIR the MLC ECC generator is different in its handling. At least it is much 
> slower than the 1 bit ECC generator and so the routines must wait the result 
> to continue on the block data.

Correct.

This is achieved by adding register polling loop at the beginning of
corresponding calculate() function. The rest of function is almost the
same, just the number of ECC bytes is larger.

The S3C2440 has a hardware ECC corrector which we do not use yet.

>> I suggest to support both new and old hardware in the same code. Why
>> not? It is 95% the same.
> 
> Instead of making the S3c2440 NAND driver more and more complicated (what is 
> the benefit of all in one driver?) I would vote for fading it out (as its 
> hardware do not change anymore). And creating a new driver for all more 
> recent CPUs with MLC support.
> 
> My idea was also to not support simple ECC on these newer CPUs anymore. Using 
> the 8 bit reed-solomon checksum would be an improvement for SLCs as well (and 
> also their OOB sizes are large enough to store the 8 bit checksums). And at 
> least if we want to boot from NAND we cannot continue to use simple ECC 
> checksums anymore.

Maybe that's right. But simple ECC support is very simple anyway,
harmless to keep. And looks like some low-cost Chinese boards still have
SLC even with newer CPUs.

I think that the new driver with MLC support with MLC support off will
be able to support older CPUs too. Probably with one exception for
S3C2410 which has no NFCONT. If so, there's no reason to keep the old
driver at all. Am I right?

BTW, do we want software ECC support too? I added sw ecc to my working
copy of NAND driver just for debugging, and now I think about keeping it.