From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 84C06EB64D7 for ; Fri, 23 Jun 2023 11:28:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:In-Reply-To: Date:References:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=f9+JuHyF9yMJLnMMd00YFVteWqOQP1hshPS8YC5y2CI=; b=tDcodz1EWf+Qdn nhg6XsNaIudyJMDxiGKdy1MWTpSf8cdluJctJFzA/74mht9u9ZNDR+QFguyg6UGhKVQdrvCKvMfM7 IP5dA6jUQ5VfKvELcxEYHsNQgydXGSn/XvJJ8MAyYHJr94OdueshAlYtcoe40xJ8yHjh5zQB58scd RoRe80HycDTjX5wqphIXnUkbxzGIOpWaf6LQ44V7vpPxL8m7QkXV1V0zbNgdOFTAu+0kTO4MnXne8 J/ecQ+hJQyy1TIuaOh/tH2c6JE+4NRmdBPlXqtms+Gr77JRPSMSWkvbotmcivBNVlQUappwwJnd6t eJ5jxYcUS7daO7KFrdTA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qCexM-003QKk-2a; Fri, 23 Jun 2023 11:28:00 +0000 Received: from unicorn.mansr.com ([2001:8b0:ca0d:1::2]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qCexK-003QKC-0t for linux-mtd@lists.infradead.org; Fri, 23 Jun 2023 11:27:59 +0000 Received: from raven.mansr.com (raven.mansr.com [IPv6:2001:8b0:ca0d:1::3]) by unicorn.mansr.com (Postfix) with ESMTPS id D0A8415360; Fri, 23 Jun 2023 12:27:54 +0100 (BST) Received: by raven.mansr.com (Postfix, from userid 51770) id C1FC921A4DD; Fri, 23 Jun 2023 12:27:54 +0100 (BST) From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= To: Miquel Raynal Cc: Richard Weinberger , Vignesh Raghavendra , Tudor Ambarus , Pratyush Yadav , Michael Walle , , Julien Su , Jaime Liao , Alvin Zhou , Thomas Petazzoni , JaimeLiao Subject: Re: [PATCH v2 3/3] mtd: rawnand: Support for sequential cache reads References: <20230112093637.987838-1-miquel.raynal@bootlin.com> <20230112093637.987838-4-miquel.raynal@bootlin.com> <20230622231202.42646e4c@xps-13> Date: Fri, 23 Jun 2023 12:27:54 +0100 In-Reply-To: <20230622231202.42646e4c@xps-13> (Miquel Raynal's message of "Thu, 22 Jun 2023 23:12:02 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230623_042758_468739_E83F1348 X-CRM114-Status: GOOD ( 26.28 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org Miquel Raynal writes: > Hi M=E5ns, > > mans@mansr.com wrote on Thu, 22 Jun 2023 15:59:25 +0100: > >> Miquel Raynal writes: >> = >> > From: JaimeLiao >> > >> > Add support for sequential cache reads for controllers using the gener= ic >> > 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 =B5s >> > * tRCBSY: 5 =B5s >> > * tRR: 20 ns >> > and the following geometry: >> > * device size: 2 MiB >> > * eraseblock size: 128 kiB >> > * page size: 2 kiB >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Normal read @ 33MHz =3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > 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 >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D Sequential cache read @ 33MHz =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >> > 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 >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> > >> > 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 >> > Signed-off-by: Miquel Raynal >> > Signed-off-by: JaimeLiao >> > --- >> > 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 -- = M=E5ns Rullg=E5rd ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/