Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   =?UTF-8?q?=E5=91=A8=E7=90=B0=E6=9D=B0=20=28Zhou=20Yanjie=29?= 
        <zhouyanjie@wanyeetech.com>
To:     tudor.ambarus@microchip.com, p.yadav@ti.com, michael@walle.cc,
        miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com,
        broonie@kernel.org, robh+dt@kernel.org,
        krzysztof.kozlowski+dt@linaro.org
Cc:     linux-mtd@lists.infradead.org, linux-spi@vger.kernel.org,
        linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
        devicetree@vger.kernel.org, aidanmacdonald.0x0@gmail.com,
        tmn505@gmail.com, paul@crapouillou.net, dongsheng.qiu@ingenic.com,
        aric.pzqi@ingenic.com, rick.tyliu@ingenic.com,
        jinghui.liu@ingenic.com, sernia.zhou@foxmail.com,
        reimu@sudomaker.com
Subject: [PATCH 1/3] mtd: spi-nor: Use the spi-mem poll status APIs.
Date:   Sat, 23 Jul 2022 00:48:28 +0800
Message-Id: <1658508510-15400-2-git-send-email-zhouyanjie@wanyeetech.com>
In-Reply-To: <1658508510-15400-1-git-send-email-zhouyanjie@wanyeetech.com>
References: <1658508510-15400-1-git-send-email-zhouyanjie@wanyeetech.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

With advanced controllers (such as Ingenic SFC), it is possible to poll
the status register of the device. This could be done to offload the CPU
during a erase or write operation. Make use of spi-mem poll status APIs
to handle this feature.

Previously, when erasing large area (e.g. 32MiB), in non-offload case,
CPU load could reach ~90% and would generate ~3.92 million interrupts,
now it decrease to ~15% CPU load and 0.15 million interrupts.

This should also fix the high CPU usage for system which don't have a
dedicated poll status block logic (decrease to ~80% CPU load and ~1.61
million interrupts.).

Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
---
 drivers/mtd/spi-nor/core.c | 42 ++++++++++++++++++++++++++++++++----------
 1 file changed, 32 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 502967c..6a31132 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -617,19 +617,41 @@ static int spi_nor_wait_till_ready_with_timeout(struct spi_nor *nor,
 	unsigned long deadline;
 	int timeout = 0, ret;
 
-	deadline = jiffies + timeout_jiffies;
+	if (nor->spimem && !nor->params->ready) {
+		struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RDSR, 0),
+						       SPI_MEM_OP_NO_ADDR,
+						       SPI_MEM_OP_NO_DUMMY,
+						       SPI_MEM_OP_DATA_IN(1, nor->bouncebuf, 0));
 
-	while (!timeout) {
-		if (time_after_eq(jiffies, deadline))
-			timeout = 1;
+		if (nor->reg_proto == SNOR_PROTO_8_8_8_DTR) {
+			op.addr.nbytes = nor->params->rdsr_addr_nbytes;
+			op.dummy.nbytes = nor->params->rdsr_dummy;
+			/*
+			 * We don't want to read only one byte in DTR mode. So,
+			 * read 2 and then discard the second byte.
+			 */
+			op.data.nbytes = 2;
+		}
 
-		ret = spi_nor_ready(nor);
-		if (ret < 0)
-			return ret;
-		if (ret)
-			return 0;
+		spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
+		return spi_mem_poll_status(nor->spimem, &op, SR_WIP, 0, 0, 10,
+						       jiffies_to_msecs(timeout_jiffies));
+	} else {
+		deadline = jiffies + timeout_jiffies;
 
-		cond_resched();
+		while (!timeout) {
+			if (time_after_eq(jiffies, deadline))
+				timeout = 1;
+
+			ret = spi_nor_ready(nor);
+			if (ret < 0)
+				return ret;
+			if (ret)
+				return 0;
+
+			cond_resched();
+		}
 	}
 
 	dev_dbg(nor->dev, "flash operation timed out\n");
-- 
2.7.4