[PATCH v2 3/3] mtd: rawnand: Support for sequential cache reads

[Miquel Raynal]

Hi Bean,

mans at mansr.com wrote on Fri, 23 Jun 2023 12:27:54 +0100:

> Miquel Raynal <miquel.raynal at bootlin.com> writes:
> 
> > Hi Måns,
> >
> > mans at mansr.com wrote on Thu, 22 Jun 2023 15:59:25 +0100:
> >  
> >> Miquel Raynal <miquel.raynal at bootlin.com> writes:
> >>   
> >> > From: JaimeLiao <jaimeliao.tw at gmail.com>
> >> >
> >> > Add support for sequential cache reads for controllers using the generic
> >> > core helpers for their fast read/write helpers.
> >> >
> >> > Sequential reads may reduce the overhead when accessing physically
> >> > continuous data by loading in cache the next page while the previous
> >> > page gets sent out on the NAND bus.
> >> >
> >> > The ONFI specification provides the following additional commands to
> >> > handle sequential cached reads:
> >> >
> >> > * 0x31 - READ CACHE SEQUENTIAL:
> >> >   Requires the NAND chip to load the next page into cache while keeping
> >> >   the current cache available for host reads.
> >> > * 0x3F - READ CACHE END:
> >> >   Tells the NAND chip this is the end of the sequential cache read, the
> >> >   current cache shall remain accessible for the host but no more
> >> >   internal cache loading operation is required.
> >> >
> >> > On the bus, a multi page read operation is currently handled like this:
> >> >
> >> > 	00 -- ADDR1 -- 30 -- WAIT_RDY (tR+tRR) -- DATA1_IN
> >> > 	00 -- ADDR2 -- 30 -- WAIT_RDY (tR+tRR) -- DATA2_IN
> >> > 	00 -- ADDR3 -- 30 -- WAIT_RDY (tR+tRR) -- DATA3_IN
> >> >
> >> > Sequential cached reads may instead be achieved with:
> >> >
> >> > 	00 -- ADDR1 -- 30 -- WAIT_RDY (tR) -- \
> >> > 		       31 -- WAIT_RDY (tRCBSY+tRR) -- DATA1_IN \
> >> > 		       31 -- WAIT_RDY (tRCBSY+tRR) -- DATA2_IN \
> >> > 		       3F -- WAIT_RDY (tRCBSY+tRR) -- DATA3_IN
> >> >
> >> > Below are the read speed test results with regular reads and
> >> > sequential cached reads, on NXP i.MX6 VAR-SOM-SOLO in mapping mode with
> >> > a NAND chip characterized with the following timings:
> >> > * tR: 20 µs
> >> > * tRCBSY: 5 µs
> >> > * tRR: 20 ns
> >> > and the following geometry:
> >> > * device size: 2 MiB
> >> > * eraseblock size: 128 kiB
> >> > * page size: 2 kiB
> >> >
> >> > ============= Normal read @ 33MHz =================
> >> > mtd_speedtest: eraseblock read speed is 15633 KiB/s
> >> > mtd_speedtest: page read speed is 15515 KiB/s
> >> > mtd_speedtest: 2 page read speed is 15398 KiB/s
> >> > ===================================================
> >> >
> >> > ========= Sequential cache read @ 33MHz ===========
> >> > mtd_speedtest: eraseblock read speed is 18285 KiB/s
> >> > mtd_speedtest: page read speed is 15875 KiB/s
> >> > mtd_speedtest: 2 page read speed is 16253 KiB/s
> >> > ===================================================
> >> >
> >> > We observe an overall speed improvement of about 5% when reading
> >> > 2 pages, up to 15% when reading an entire block. This is due to the
> >> > ~14us gain on each additional page read (tR - (tRCBSY + tRR)).
> >> >
> >> > Co-developed-by: Miquel Raynal <miquel.raynal at bootlin.com>
> >> > Signed-off-by: Miquel Raynal <miquel.raynal at bootlin.com>
> >> > Signed-off-by: JaimeLiao <jaimeliao.tw at gmail.com>
> >> > ---
> >> >  drivers/mtd/nand/raw/nand_base.c | 119 +++++++++++++++++++++++++++++--
> >> >  include/linux/mtd/rawnand.h      |   9 +++
> >> >  2 files changed, 124 insertions(+), 4 deletions(-)    
> >> 
> >> This change broke something on a TI AM3517 based system.  What I'm
> >> noticing is that the u-boot fw_setenv tool is failing due to the
> >> MEMGETBADBLOCK ioctl reporting some blocks as bad when they are not.
> >> Everything else is, somehow, working fine.  Reverting this commit fixes
> >> it, though I don't know why.  I'm seeing the same behaviour on multiple
> >> devices, so I doubt there is a problem with the flash memory.
> >> 
> >> Is there anything I can test to get more information?
> >>   
> >
> > May I know what NAND chip you are using?  
> 
> It's a Micron MT29F4G16ABBDAH4-IT:D.  From the kernel logs:
> 
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> nand: Micron MT29F4G16ABBDAH4
> nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64

There is definitely something wrong with Micron's handling of the
sequential reads. Can you make a setup on your side with one of these
chips and try to reproduce?

I will have to discard Micron's chips if we don't find a solution very
soon, too bad, it is a nice performance improvement -when it works-.

Thanks,
Miquèl