ECC and multi page read write support

["Miguel Freitas" <miguel@cetuc.puc-rio.br>]

    Hi,

    I'd like to discuss some points on ECC and multi page before 
applying Rogelio's patch to the new driver. I think we need to better 
define the API conforming to this. obs: I prefer the word "sector" for 
a 512 bytes unit because some devices have only 256-byte page.
    First (dumb) question, why is the multi page read needed? 
Excuse for not being an expert in character devices, I think it's great 
to have a driver which do not have such restrictions. But I don't 
know exactly what for.

    There are some problems with multi page x ECC:

    1) The read / write routines can work on subsector data, ie, they 
can read/write less than a sector. This of course implies in no ECC 
generation at all, cause the ECC has to be calculated from all 512 
bytes sectors (there is a warning on this in the new code). By 
allowing multi sector access, it may not be possible to 
check/generate ECC for all sectors being accessed, unless we 
access an integral multiple of sectors.
    2) I particularly like the write_ecc API, as mtd_info.html says: 
"the write_ecc function places the generated ECC data into eccbuf". 
So it's up to user module to decide what to do with ECC data, ie, 
where in OOB it will be placed. Unfortunately, writing to multiple 
sectors will generate multiple ECC data, so the user must know how 
many sectors are being written and record ECC data for the 
respective sectors.
    3) The read_ecc do have the same eccbuf parameter. IMHO, this 
doesn't make much sense, as the ECC data written to the OOB is of 
no use to the user module. We should decide if the correction of 
data is to be made inside the read_ecc or if the _ECC syndrom_ 
(generated by after reading data + ECC data, not ECC data itself) 
should be returned. If we decide to return the syndrom, we will have 
the same problem as (2). David may give us a insight on this based 
on his experience with other drivers.

   The read_ecc is more "atomic" than write_ecc because the ECC 
data must be read just after the sector data itself, or the syndrom 
could be wrong if another process accesses the DoC in the mean 
time. Unlike the writing sequence, which can be  
write_ecc(buf,eccbuf) followed by write_oob(eccbuf), we cannot do 
read_ecc(buf) followed by read_oob(eccbuf) expecting that 
syndrom registers will be correct. The read_oob operation must be 
executed inside the read_ecc. So, the flexibility added from 
write_ecc returning the ECC data is limited by the fact that it must 
be placed somewhere in OOB.

   I have 2 ideas for the API:

   1) we maintain the eccbuf in write_ecc and provide read_ecc with 
a offset into OOB where it will find the ECC data.
   2) we hardcode the position of ECC data in offset zero of OOB as 
M-Systems do. This way, write_ecc can automatically write the ECC 
in OOB. read_ecc can read, check and return corrected data. We 
will not need any other parameter in read_ecc/write_ecc. Someone 
must point that user modules may want to write additional OOB data, 
but remember that it still possible by writing less than 16 bytes to a 
particular OOB offset.

    Anyway, we can always implement subsector read with ECC by 
reading an entire sector, correcting the data and returning only the 
information asked by the user. A subsector read without ECC 
doesn't need to read a full sector, so no performance degradation 
will occur in this case. This solution cannot be done when writting 
subsector, as we can only record ECC in OOB one time (we would 
need to erase a block to do it again).


    Comments?? :)

Regards,

Miguel Freitas
Center for Telecommunications Studies
CATHOLIC UNIVERSITY - BRASIL
e-mail: miguel@cetuc.puc-rio.br
phone/fax#:+55-21-540-8854


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org