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 <d-gole@ti.com>
---
 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, &reg, 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 <d-gole@ti.com>
> ---
>  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, &reg, 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 <d-gole@ti.com>