From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bill Pringlemeir Date: Tue, 07 Apr 2015 10:06:46 -0400 Subject: [U-Boot] [PATCH 1/2] mtd: vf610_nfc: mark page as dirty on block erase In-Reply-To: <1428094996.22867.364.camel@freescale.com> (Scott Wood's message of "Fri, 3 Apr 2015 16:03:16 -0500") References: <1427216060-29120-1-git-send-email-stefan@agner.ch> <87mw2uo1va.fsf@nbsps.com> <1427747668.22867.174.camel@freescale.com> <1427748489.22867.187.camel@freescale.com> <38e4a435ee5080566042c6021efe7e83@agner.ch> <1427753707.22867.198.camel@freescale.com> <1d8481267a40fed73b4aff1a50ae0774@agner.ch> <1427776476.22867.220.camel@freescale.com> <877ftxnrak.fsf@nbsps.com> <1428018499.22867.304.camel@freescale.com> <1428092157.22867.337.camel@freescale.com> <84c8882234cc8a453a89a1808c7802fd@agner.ch> <1428094996.22867.364.camel@freescale.com> Message-ID: <877ftokp6x.fsf@nbsps.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.