Documentation: mtd: improve nand_ecc.txt for readability and correctness

    if (i & 0x01)

       rp1 = bit7 ^ bit6 ^ bit5 ^ bit4 ^ bit3 ^ bit2 ^ bit1 ^ bit0 ^ rp1;

    else

       rp0 = bit7 ^ bit6 ^ bit5 ^ bit4 ^ bit3 ^ bit2 ^ bit1 ^ bit0 ^ rp1;

       rp0 = bit7 ^ bit6 ^ bit5 ^ bit4 ^ bit3 ^ bit2 ^ bit1 ^ bit0 ^ rp0;

    if (i & 0x02)

       rp3 = bit7 ^ bit6 ^ bit5 ^ bit4 ^ bit3 ^ bit2 ^ bit1 ^ bit0 ^ rp3;

    else

individually, let us try to rearrange things.

For the column parity this is easy. We can just xor the bytes and in the

end filter out the relevant bits. This is pretty nice as it will bring

all cp calculation out of the if loop.

all cp calculation out of the for loop.

Similarly we can first xor the bytes for the various rows.

This leads to:

Of course this means some modification as the row parity is byte by

byte. A quick analysis:

for the column parity we use the par variable. When extending to 32 bits

we can in the end easily calculate p0 and p1 from it.

we can in the end easily calculate rp0 and rp1 from it.

(because par now consists of 4 bytes, contributing to rp1, rp0, rp1, rp0

respectively)

respectively, from MSB to LSB)

also rp2 and rp3 can be easily retrieved from par as rp3 covers the

first two bytes and rp2 the last two bytes.

first two MSBs and rp2 covers the last two LSBs.

Note that of course now the loop is executed only 64 times (256/4).

And note that care must taken wrt byte ordering. The way bytes are

The code (of course) works, and hurray: we are a little bit faster than

the linux driver code (about 15%). But wait, don't cheer too quickly.

THere is more to be gained.

There is more to be gained.

If we look at e.g. rp14 and rp15 we see that we either xor our data with

rp14 or with rp15. However we also have par which goes over all data.

This means there is no need to calculate rp14 as it can be calculated from

rp15 through rp14 = par ^ rp15;

rp15 through rp14 = par ^ rp15, because par = rp14 ^ rp15;

(or if desired we can avoid calculating rp15 and calculate it from

rp14).  That is why some places refer to inverse parity.

Of course the same thing holds for rp4/5, rp6/7, rp8/9, rp10/11 and rp12/13.

While making the changes I also found that I could exploit that tmppar

contains the running parity for this iteration. So instead of having:

rp4 ^= cur; rp6 = cur;

I removed the rp6 = cur; statement and did rp6 ^= tmppar; on next

rp4 ^= cur; rp6 ^= cur;

I removed the rp6 ^= cur; statement and did rp6 ^= tmppar; on next

statement. A similar change was done for rp8 and rp10