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

[Scott Wood]

On Tue, 2015-04-07 at 10:06 -0400, Bill Pringlemeir wrote:
> 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.

Possibly.  Again, I recommend benchmarking before committing to it.

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

If that's the case, then that's even more reason to leave subpages
disabled until you're sure you want them.

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

That limitation sounds similar to the Freescale NAND controllers that
I'm familiar with (eLBC and IFC).  For eLBC we do subpages by just
writing 0xff, because on that controller the ECC of all 0xff is all 0xff
so it doesn't disturb anything.  IFC has different ECC algorithms where
that isn't the case, so we disabled subpage write on IFC.

What is the virtual buffer feature?

> I am pretty sure that all controllers that support hw-ecc will need to do this.

Not if they can handle doing ECC on a single subpage.

-Scott