Limited support of NAND features in MTD.
dedekind at infradead.org
Wed Dec 12 08:54:39 EST 2007
On Wed, 2007-12-12 at 11:51 +0000, Alexey Korolev wrote:
> It is not a secret that current MTD supports very limited set of NAND
> features. Some of missed features like partial page read or cached read
> are able to improve file system performance and its implementation do
> not require s/w redesign.
> I have a question is there any limitations/restrictions to support extended features?
I do not think so. And it depends on the feature.
For example, partial flash read should not be a problem. If the driver
is asked to read only the first half of the NAND page, and it is capable
of partial page read, it reads only half the page. But nand_base.c would
need to be improved for this.
> Does it make sense to implement these features and manage them
> through nand_chip->options flag, letting people to choose whether to use
> features or not? If it is not a good idea what is the best way to manage
It again depends on the feature. These partial reads should be
transparent I think.
In general, it is worth trying hard not to introduce new interfaces. And
I think nand_chip structure should be accessed only by NAND
> Currently my clooeague and I did prototypes of partial page read and cached read
> functionalities showing performance increase. For example partial page read showed about 20%
> of file open/stat time performance increase in JFFS2 on LP NAND. Cached
> read increases overall read performance but value strongly depends on
> platform IO latencies. Now we are thinking to create and sent patches.
Artem Bityutskiy (Битюцкий Артём)
More information about the linux-mtd