[U-Boot] [PATCH 1/2] mtd: vf610_nfc: mark page as dirty on block erase

[Bill Pringlemeir <bpringlemeir@nbsps.com>]

On  3 Apr 2015, scottwood at freescale.com wrote:

> On Fri, 2015-04-03 at 22:28 +0200, Stefan Agner wrote:

>> Why not? IMHO, there are valid reason to do it, since we save coping
>> data over the bus (we save copying page size - write len of bytes)...

> According to http://www.linux-mtd.infradead.org/doc/ubi.html#L_subpage
> the motivation for subpages is saving space, not time, and it's only
> used for headers (specifically because using subpages may be slower).
> So it may not make a huge performance difference either way, even if
> subpages are less efficient on this controller -- though it does have
> a complexity cost that is higher than with most controllers.  It looks
> like the space savings is around one page per block.

I think that Artem wrote this.  I don't believe the document is
completely correct; I think he meant that sub-pages is not architected
as a speed improvement.  For instance, UBI will read both a VID (volume
ID) and EB (erase block).  As the are combined into one, then if a
driver needs to read a full page (like it is the only thing it supports)
then it is simple to read a full page with a VID/EB sub-pages.
Certainly for mounts with out 'fastmap', this will result in much faster
scans and initial UBI/UbiFS mounts?

It also saves one page overhead per erase block.  So in all cases,
sub-pages will optimize flash usage.  Probably performance depends on
the MTD driver and CPU.

> It'd be good to benchmark up front to be sure you're happy with the
> speed/space/complexity tradeoff, though, since enabling/disabling
> subpage writes breaks UBI compatibility.

I think that if you format the UbiFs without sub-pages and then update
code to handle sub-pages, you are fine.  If you have flash/UBI formatted
with sub-pages and then you disable it in the code, the disk is no
longer mountable.

In any case the document has,

  If the NAND flash supports sub-pages, then what can be done is ECC
  codes can be calculated on per-sub-page basis, instead of per-NAND
  page basis. In this case it becomes possible to read and write
  sub-pages independently.

Probably if we want sub-pages with this controller and hw-ecc, we need
to use the virtual buffer features of the chip.  The controller needs an
entire current buffer in the SRAM to calculate the hw-ecc to write.  So
even if it writes less than a full page, the entire page must be read to
calculate the hw-ecc to be written.  I am pretty sure that all
controllers that support hw-ecc will need to do this.

Fwiw,
Bill Pringlemeir.