Re: [RFC][patch] NAND partial page read functionality

[Artem Bityutskiy <dedekind@infradead.org>]

On Tue, 2007-12-18 at 12:42 +0100, Jörn Engel wrote:
> On Tue, 18 December 2007 10:48:51 +0200, Artem Bityutskiy wrote:
> > 
> > Well, this depends. If an MTD user wants to write 4KiB, and issues 4KiB
> > write request, then it is of course faster to write 2x2048, then 8x512,
> > and it is even faster to do some kind of multi-page write (some old
> > flashes had this AFAIK).
> 
> Not necessarily.  The alauda chip has a "page program" and a "block
> program" command.  With a naive implementation the block program is
> faster.  But when doing asynchronous transfers on the usb bus, page
> program becomes just as fast.  In this particular case, block program
> can only reduce the number of synchronous bus latencies for a
> non-optimized implementation.

Well, in the context of discussion this example is not really relevant,
since aluda have its own write_page, and we are talking about the
nand_base.c's implementation.

> If writesize is 256 and pagesize is 2048, every wbuf flush will write
> exactly 256.  Any remaining clean multiple of 256 is written directly,
> but this will rarely be an aligned clean multiple of 2048.  Every wbuf
> flush ensures that either the previous or the following writes is not.

Indeed, you are right.

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