For each NAND_OP_WAITRDY_INSTR operation, the NANDFSR register is
polled only once every 100 us to check for the EMA_WAIT pin. This
isn't frequent enough and causes delays in NAND accesses.

Set the polling interval to 0s. It increases the page read speed
reported by flash_speed by ~40% (~30% on page writes).

Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
---
Changes in v2:
- Fix SOB.
- Link to v1: https://lore.kernel.org/r/20241219-patch-nand-poll-v1-1-605e5f15f24a@bootlin.com
---
 drivers/mtd/nand/raw/davinci_nand.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/davinci_nand.c b/drivers/mtd/nand/raw/davinci_nand.c
index 1f8354acfb50b2f4d155cdfc03afcf2863539f66..b3fe6f62bb3bd6a51da891c604d38142055ab1d3 100644
--- a/drivers/mtd/nand/raw/davinci_nand.c
+++ b/drivers/mtd/nand/raw/davinci_nand.c
@@ -724,7 +724,7 @@ static int davinci_nand_exec_instr(struct davinci_nand_info *info,
 	case NAND_OP_WAITRDY_INSTR:
 		timeout_us = instr->ctx.waitrdy.timeout_ms * 1000;
 		ret = readl_relaxed_poll_timeout(info->base + NANDFSR_OFFSET,
-						 status, status & BIT(0), 100,
+						 status, status & BIT(0), 0,
 						 timeout_us);
 		if (ret)
 			return ret;

---
base-commit: 40384c840ea1944d7c5a392e8975ed088ecf0b37
change-id: 20241219-patch-nand-poll-b215766ea0a2

Best regards,
-- 
Bastien Curutchet <bastien.curutchet@bootlin.com>

Hello Bastien,

On 19/12/2024 at 15:58:10 +01, Bastien Curutchet <bastien.curutchet@bootlin.com> wrote:

> For each NAND_OP_WAITRDY_INSTR operation, the NANDFSR register is
> polled only once every 100 us to check for the EMA_WAIT pin. This
> isn't frequent enough and causes delays in NAND accesses.
>
> Set the polling interval to 0s. It increases the page read speed
> reported by flash_speed by ~40% (~30% on page writes).

...

>  	case NAND_OP_WAITRDY_INSTR:
>  		timeout_us = instr->ctx.waitrdy.timeout_ms * 1000;
>  		ret = readl_relaxed_poll_timeout(info->base + NANDFSR_OFFSET,
> -						 status, status & BIT(0), 100,
> +						 status, status & BIT(0), 0,

This kind of optimization is very tempting but has an impact on the
system. I am fine reducing this polling delay, but maybe not down to 0
which means you busy wait the entire time. For reads it might be fine
because tR is rather short, but for writes it is a bit more impacting
and for erases it will have a true system wide impact. So what you see
in the benchmark is specific to the NAND driver performances, but fails
to give you the system-wide big picture which I think is worth keeping
in mind.

As this value will be NAND specific we cannot fine tune it too much, but
I would suggest to try finding a lower value without reaching 0. Like 5
or 10 us maybe.

Thanks,
Miquèl