If one leaves the CQSPI_REG_CMDCTRL in an unclean state this may cause
issues in future command reads. This issue came to light when some flash
reads in STIG mode were coming back dirty.
Signed-off-by: Dhruva Gole <[email protected]>
---
drivers/spi/spi-cadence-quadspi.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index 676313e1bdad..6030da942c6e 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -549,6 +549,9 @@ static int cqspi_command_read(struct cqspi_flash_pdata *f_pdata,
memcpy(rxbuf, ®, read_len);
}
+ /* Reset CMD_CTRL Reg once command read completes */
+ writel(0, reg_base + CQSPI_REG_CMDCTRL);
+
return 0;
}
@@ -613,7 +616,12 @@ static int cqspi_command_write(struct cqspi_flash_pdata *f_pdata,
}
}
- return cqspi_exec_flash_cmd(cqspi, reg);
+ ret = cqspi_exec_flash_cmd(cqspi, reg);
+
+ /* Reset CMD_CTRL Reg once command write completes */
+ writel(0, reg_base + CQSPI_REG_CMDCTRL);
+
+ return ret;
}
static int cqspi_read_setup(struct cqspi_flash_pdata *f_pdata,
--
2.25.1
Hi,
On Wed, Jan 25 2023, Dhruva Gole wrote:
> If one leaves the CQSPI_REG_CMDCTRL in an unclean state this may cause
> issues in future command reads. This issue came to light when some flash
> reads in STIG mode were coming back dirty.
Can you explain in more detail what you mean by "reads coming back
dirty"? Because I don't see any clear reason why not resetting the
register would break anything. We re-create the register value from the
scratch on the next read anyway, and as soon as you writel() that, the
old fields get thrown away anyway.
>
> Signed-off-by: Dhruva Gole <[email protected]>
> ---
> drivers/spi/spi-cadence-quadspi.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
> index 676313e1bdad..6030da942c6e 100644
> --- a/drivers/spi/spi-cadence-quadspi.c
> +++ b/drivers/spi/spi-cadence-quadspi.c
> @@ -549,6 +549,9 @@ static int cqspi_command_read(struct cqspi_flash_pdata *f_pdata,
> memcpy(rxbuf, ®, read_len);
> }
>
> + /* Reset CMD_CTRL Reg once command read completes */
> + writel(0, reg_base + CQSPI_REG_CMDCTRL);
> +
> return 0;
> }
>
> @@ -613,7 +616,12 @@ static int cqspi_command_write(struct cqspi_flash_pdata *f_pdata,
> }
> }
>
> - return cqspi_exec_flash_cmd(cqspi, reg);
> + ret = cqspi_exec_flash_cmd(cqspi, reg);
> +
> + /* Reset CMD_CTRL Reg once command write completes */
> + writel(0, reg_base + CQSPI_REG_CMDCTRL);
> +
> + return ret;
> }
>
> static int cqspi_read_setup(struct cqspi_flash_pdata *f_pdata,
> --
> 2.25.1
>
--
Regards,
Pratyush Yadav
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
Thanks for taking a look Pratyush!
On 1/27/2023 8:46 PM, Pratyush Yadav wrote:
> Hi,
>
> On Wed, Jan 25 2023, Dhruva Gole wrote:
>
>> If one leaves the CQSPI_REG_CMDCTRL in an unclean state this may cause
>> issues in future command reads. This issue came to light when some flash
>> reads in STIG mode were coming back dirty.
> Can you explain in more detail what you mean by "reads coming back
> dirty"? Because I don't see any clear reason why not resetting the
> register would break anything. We re-create the register value from the
> scratch on the next read anyway, and as soon as you writel() that, the
> old fields get thrown away anyway.
There's a hardware bug due to which clearing of this register is necessary.
> [...]
--
Regards,
Dhruva Gole <[email protected]>