ECC and multi page read write support
Miguel Freitas
miguel at cetuc.puc-rio.br
Fri Aug 18 11:58:39 EDT 2000
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 at cetuc.puc-rio.br
phone/fax#:+55-21-540-8854
To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org
More information about the linux-mtd
mailing list