Hi Miquel,
On 8/8/19 2:05 am, Miquel Raynal wrote:
Greg Ungerer <gerg@xxxxxxxxxx> wrote on Mon, 5 Aug 2019 15:51:05 +1000:
On 2/8/19 10:51 pm, Boris Brezillon wrote:
On Fri, 2 Aug 2019 22:34:57 +1000
Greg Ungerer <gerg@xxxxxxxxxx> wrote:
On 31/7/19 4:28 pm, Boris Brezillon wrote:
On Wed, 31 Jul 2019 12:05:44 +1000
Greg Ungerer <gerg@xxxxxxxxxx> wrote:
On 30/7/19 6:38 pm, Miquel Raynal wrote:
Greg Ungerer <gerg@xxxxxxxxxx> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
On 30/7/19 10:41 am, Greg Ungerer wrote:
On 30/7/19 10:28 am, Greg Ungerer wrote:
On 29/7/19 10:47 pm, Miquel Raynal wrote:
Greg Ungerer <gerg@xxxxxxxxxx> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
On 29/7/19 6:36 pm, Miquel Raynal wrote:
Greg Ungerer <gerg@xxxxxxxxxx> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
[snip]
Note that this was generated on a normal boot up (not failure).
The values looks good. Can you try with the below diff applied?
--->8---
diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
index 334fe3130285..9771f6a82abe 100644
--- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
@@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>>> /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
- dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
- if (!dll_wait_time_us)
- dll_wait_time_us = 1;
+ dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>>> /* Wait for the DLL to settle. */
- udelay(dll_wait_time_us);
+ usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
}
>>> static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
Eventually it failed, in the same way with with same errors.
Took quite a while, over 600 boot cycles.
Note also that I had to hand merge the changes, since in 5.1.14 that
gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
Oh well. I guess the next thing to do would be to dump the timing regs
and clk rate that are set by the bootloader (before the driver override
them) or those applied by an older kernel (one that didn't have that
issue).
Is this useful?
With attached patch, I get the following dump of the timing
settings in use:
...
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
HW_GPMI_TIMING0=0x00010203 (calculated=0x00020101)
HW_GPMI_TIMING1=0x00000000 (calculated=0x60000000)
HW_GPMI_CTRL1_SET=0x01c4000c (calculated=0x00000000)
r->clock[0]=22000000 (calculated=22000000)
random: fast init done
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
HW_GPMI_TIMING0=0x00010203 (calculated=0x00020101)
HW_GPMI_TIMING1=0x00000000 (calculated=0xb0000000)
HW_GPMI_CTRL1_SET=0x01c4000c (calculated=0x00000000)
r->clock[0]=22000000 (calculated=22000000)
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
HW_GPMI_TIMING0=0x00010203 (calculated=0x00010101)
HW_GPMI_TIMING1=0x00000000 (calculated=0xe0000000)
HW_GPMI_CTRL1_SET=0x01c4000c (calculated=0x00c28000)
r->clock[0]=22000000 (calculated=100000000)
Why are the registers not updated? Is it the same situation when we
get all the failures?
As per the patch that was attached to that email. The setting of the
registers and clock was "#if 0" out so you could see what the
power-up/boot-loader settings are. Those settings work reliably
with no nand failures. In between running various tests I have
left my hardware boot cycle testing with those settings. I don't
have an exact number but it has probably run at least 100 hours
and tens of thousands of boots with no problem using those.
Or am I misunderstanding your question?
Regards
Greg
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
