[U-Boot] [PATCH 1/2] mtd: vf610_nfc: mark page as dirty on block erase
Bill Pringlemeir
bpringlemeir at nbsps.com
Mon Mar 30 23:35:27 CEST 2015
On 30 Mar 2015, scottwood at freescale.com wrote:
> On Mon, 2015-03-30 at 22:40 +0200, Stefan Agner wrote:
>> However, if removing the caching in the driver would lead to a
>> performance drop, I would rather prefer to keep it...
> What is special about this controller, that caching makes sense here
> but not on other controllers? If it makes sense everywhere, then the
> upper layer is the place to do it.
While I observed some performance differences, but that is an aside. I
think the mxc driver is similar in sub-page (or partial page) support.
Before doing a sub-page write, it reads a full page and then copies the
sub-page update to the buffer to be reprogrammed. This works fine if
each and every sub-page has separate OOB data for software ECC. The
hardware ECC of this vf610_nfc controller doesn't support this.
At least that is my understanding of this [mxc_nand] code,
case NAND_CMD_SEQIN:
if (column >= mtd->writesize) {
/*
* before sending SEQIN command for partial write,
* we need read one page out. FSL NFC does not support
* partial write. It always sends out 512+ecc+512+ecc
* for large page nand flash. But for small page nand
* flash, it does support SPARE ONLY operation.
*/
if (host->pagesize_2k) {
/* call ourself to read a page */
mxc_nand_command(mtd, NAND_CMD_READ0, 0,
page_addr);
}
in 'drivers/mtd/nand/mxc_nand.c'. So, originally this was mainly for
sub-pages (an optimization but also functionality).
So the 'caching' is just to preserve read data before a partial write as
the vf610 requires a full page (like the mxc). The same 'caching' was
keep for 'write followed by read' when the ECC is successful.
I realize that the upper layers may not like this so I mentioned it; I
guess that is proof that the patch is getting a good review and I am not
causing problems for Stefan ;)
I also agree with Stefan that setting the SECSZ in the 2nd patch will
result in less data transfer (and maybe less current/power and system
noise). However, this will be inside the NFC controller. Talking over
the AHB to the NFC controller is quite slow on the Vybrid. Certainly it
seems a little more elegant to tell the controller to transfer nothing
(and that we [programmers] expect nothing as a sort of documentation)?
I think it would be worthwhile to benchmark without the cache. Or maybe
Stefan already has some numbers? Upper layers doing partial pages will
definitely benefit with the 'cache'; we would also need more DDR memory
as the NFC controller memory is being used as a scratch buffer.
Fwiw,
Bill Pringlemeir.
More information about the U-Boot
mailing list