Re: Limited support of NAND features in MTD.

[Artem Bityutskiy <dedekind@infradead.org>]

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?

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
infrastructure.

> 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.

Sounds interesting.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)