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

[Scott Wood]

On Fri, 2015-04-03 at 22:28 +0200, Stefan Agner wrote:
> On 2015-04-03 22:15, Scott Wood wrote:
> > On Fri, 2015-04-03 at 20:09 +0200, Stefan Agner wrote:
> >> On 2015-04-03 01:48, Scott Wood wrote:
> >> > On Tue, 2015-03-31 at 11:02 -0400, Bill Pringlemeir wrote:
> >> >> On 2015-03-31 00:15, Scott Wood wrote:
> >> >>
> >> >> > Especially since you'd be doing one write rather than four full-page
> >> >> > "partial" writes.  Surely the bottleneck here is the NAND chip itself,
> >> >> > not copying data to the buffer?
> >> >>
> >> >> The AHB bus that the NFC controller is on is relatively slow.  Here are
> >> >> some numbers from 'AN4947-vybrid-bus-architechure',
> >> >>
> >> >> Vybrid Cortex A5 to DDR (in CPU clocks 400/500MHz),
> >> >>
> >> >>    First read     Subsequent
> >> >>    285            8              all caches on
> >> >>    345            269            no cache, mmu
> >> >>    437            371            no cache, no mmu
> >> >>
> >> >> The NFC is on an AHB bus 32bit, 66MHz (not AXI 64bit, 133-166MHz like
> >> >> DDR).  The AHB will be about four times slower.  Also the reads and
> >> >> writes to the physical NAND must take place serially.  Here are the
> >> >> program page steps.
> >> >>
> >> >>   1. Issue controller Read full page to NFC buffer.
> >> >>   2. Copy update partial page from DDR to NFC buffer.
> >> >>   3. Issue write NAND page.
> >> >
> >> > Why is any sort of read part of the write process?
> >>
> >> To recalculate the correct ECC, which is done in the controller, the
> >> controller has to have the page in the SRAM. I will send out a patch
> >> which implements vf610_nfc_write_subpage. And the read part is done when
> >> the MTD subsystem calls NAND_CMD_SEQIN.
> > 
> > Again, if this is the only way you can do subpage accesses then you
> > should not do them.
> 
> 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.

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.

> Also, I guess all NAND controller which do HW ECC need to read at least
> ECC step size back to the controller... Maybe we can move the discussion
> to the actual code (see "mtd: vf610_nfc: support subpage write").

No, most controller drivers do not read from the NAND chip during the
programming process.

-Scott