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

[Stefan Agner]

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.

Actually, the Linux NAND driver supports subpage writes already by using
the generic nand_write_subpage_hwecc function. However, in U-Boot I
added driver specific page_read/page_write due to performance reasons:
http://lists.denx.de/pipermail/u-boot/2014-August/186293.html

However, I tried driver specific page_read/page_write functions for
Linux too, but I couldn't measure noticeable performance improvements. I
think the reason why it lead to noticeable improvements for U-Boot was
because U-Boot does not use caches so far. We could also switch to the
framework functions again, but those are more complex than necessary.
Given that U-Boot uses device specific binaries anyway, there is no size
advantage by using the (shared) MTD subsystems functions.

--
Stefan