From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Fri, 3 Apr 2015 15:15:57 -0500 Subject: [U-Boot] [PATCH 1/2] mtd: vf610_nfc: mark page as dirty on block erase In-Reply-To: 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> Message-ID: <1428092157.22867.337.camel@freescale.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 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. > 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. If you care about U-Boot's performance at all, enabling cache would be the first thing I'd try... -Scott