From 596d74c80fe83ab78230cb5b48dc64b3caf58195 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 8 Nov 2022 13:21:27 +0100 Subject: [PATCH] 5.4-stable patches added patches: mtd-rawnand-gpmi-set-wait_for_ready-timeout-based-on-program-erase-times.patch --- ...timeout-based-on-program-erase-times.patch | 71 +++++++++++++++++++ queue-5.4/series | 1 + 2 files changed, 72 insertions(+) create mode 100644 queue-5.4/mtd-rawnand-gpmi-set-wait_for_ready-timeout-based-on-program-erase-times.patch diff --git a/queue-5.4/mtd-rawnand-gpmi-set-wait_for_ready-timeout-based-on-program-erase-times.patch b/queue-5.4/mtd-rawnand-gpmi-set-wait_for_ready-timeout-based-on-program-erase-times.patch new file mode 100644 index 00000000000..670d469d0e8 --- /dev/null +++ b/queue-5.4/mtd-rawnand-gpmi-set-wait_for_ready-timeout-based-on-program-erase-times.patch @@ -0,0 +1,71 @@ +From 0fddf9ad06fd9f439f137139861556671673e31c Mon Sep 17 00:00:00 2001 +From: Sascha Hauer +Date: Fri, 1 Jul 2022 13:03:41 +0200 +Subject: mtd: rawnand: gpmi: Set WAIT_FOR_READY timeout based on program/erase times +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Sascha Hauer + +commit 0fddf9ad06fd9f439f137139861556671673e31c upstream. + +06781a5026350 Fixes the calculation of the DEVICE_BUSY_TIMEOUT register +value from busy_timeout_cycles. busy_timeout_cycles is calculated wrong +though: It is calculated based on the maximum page read time, but the +timeout is also used for page write and block erase operations which +require orders of magnitude bigger timeouts. + +Fix this by calculating busy_timeout_cycles from the maximum of +tBERS_max and tPROG_max. + +This is for now the easiest and most obvious way to fix the driver. +There's room for improvements though: The NAND_OP_WAITRDY_INSTR tells us +the desired timeout for the current operation, so we could program the +timeout dynamically for each operation instead of setting a fixed +timeout. Also we could wire up the interrupt handler to actually detect +and forward timeouts occurred when waiting for the chip being ready. + +As a sidenote I verified that the change in 06781a5026350 is really +correct. I wired up the interrupt handler in my tree and measured the +time between starting the operation and the timeout interrupt handler +coming in. The time increases 41us with each step in the timeout +register which corresponds to 4096 clock cycles with the 99MHz clock +that I have. + +Fixes: 06781a5026350 ("mtd: rawnand: gpmi: Fix setting busy timeout setting") +Fixes: b1206122069aa ("mtd: rawniand: gpmi: use core timings instead of an empirical derivation") +Cc: stable@vger.kernel.org +Signed-off-by: Sascha Hauer +Acked-by: Han Xu +Tested-by: Tomasz Moń +Signed-off-by: Richard Weinberger +Signed-off-by: Tim Harvey +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c ++++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c +@@ -652,8 +652,9 @@ static void gpmi_nfc_compute_timings(str + unsigned int tRP_ps; + bool use_half_period; + int sample_delay_ps, sample_delay_factor; +- u16 busy_timeout_cycles; ++ unsigned int busy_timeout_cycles; + u8 wrn_dly_sel; ++ u64 busy_timeout_ps; + + if (sdr->tRC_min >= 30000) { + /* ONFI non-EDO modes [0-3] */ +@@ -677,7 +678,8 @@ static void gpmi_nfc_compute_timings(str + addr_setup_cycles = TO_CYCLES(sdr->tALS_min, period_ps); + data_setup_cycles = TO_CYCLES(sdr->tDS_min, period_ps); + data_hold_cycles = TO_CYCLES(sdr->tDH_min, period_ps); +- busy_timeout_cycles = TO_CYCLES(sdr->tWB_max + sdr->tR_max, period_ps); ++ busy_timeout_ps = max(sdr->tBERS_max, sdr->tPROG_max); ++ busy_timeout_cycles = TO_CYCLES(busy_timeout_ps, period_ps); + + hw->timing0 = BF_GPMI_TIMING0_ADDRESS_SETUP(addr_setup_cycles) | + BF_GPMI_TIMING0_DATA_HOLD(data_hold_cycles) | diff --git a/queue-5.4/series b/queue-5.4/series index b8df3f4b1d7..de6907412dd 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -66,3 +66,4 @@ kvm-x86-mask-off-reserved-bits-in-cpuid.80000008h.patch kvm-x86-emulator-em_sysexit-should-update-ctxt-mode.patch kvm-x86-emulator-introduce-emulator_recalc_and_set_mode.patch kvm-x86-emulator-update-the-emulation-mode-after-cr0-write.patch +mtd-rawnand-gpmi-set-wait_for_ready-timeout-based-on-program-erase-times.patch -- 2.47.3