On 10/25/21 9:53 PM, Pratyush Yadav wrote:
On 08/10/21 06:06PM, Jagan Teki wrote:
On Wed, Sep 15, 2021 at 2:05 PM Marek Vasut <ma...@denx.de> wrote:

On 9/15/21 10:28 AM, Pratyush Yadav wrote:
On 14/09/21 08:22PM, Marek Vasut wrote:
On 9/14/21 7:42 PM, Pratyush Yadav wrote:
On 14/09/21 05:22AM, Marek Vasut wrote:
Wait for the read/write transfer finish bit get actually cleared,
this does not happen immediately on at least SoCFPGA Gen5.

Signed-off-by: Marek Vasut <ma...@denx.de>
Cc: Jagan Teki <ja...@amarulasolutions.com>
Cc: Vignesh R <vigne...@ti.com>
Cc: Pratyush Yadav <p.ya...@ti.com>
---
    drivers/spi/cadence_qspi_apb.c | 17 +++++++++++++++++
    1 file changed, 17 insertions(+)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 429ee335db6..2cdf4c9c9f8 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -858,6 +858,14 @@ cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_plat *plat,
            writel(CQSPI_REG_INDIRECTRD_DONE,
                   plat->regbase + CQSPI_REG_INDIRECTRD);
+  /* Check indirect done status */
+  ret = wait_for_bit_le32(plat->regbase + CQSPI_REG_INDIRECTRD,
+                          CQSPI_REG_INDIRECTRD_DONE, 0, 10, 0);
+  if (ret) {
+          printf("Indirect read clear completion error (%i)\n", ret);
+          goto failrd;
+  }
+

Huh, this is strange. I would expect the bit to clear immediately since
it doesn't really do any operation on the flash. How long does it
usually take to clear? If you don't wait for it to clear does anything
break?

Often it does clear immediately, but there were a few odd cases where it did
not happen right away, in which case I had transfer corruption.

By "transfer corruption" do you mean the current transfer gets corrupted
or the next one?

We get here _after_ the transfer is completed and this bit should have
little to do with the data received. If the current transfer fails then
I suspect something else might be going wrong the this is just a symptom
of the problem.

As far as I recall, the problem was triggered when using UBI on the SPI
NOR, so that could very well be the next transfer.

Any further decisions here? shall I take it or v2?

I think we need more information here. I don't see why checking this bit
would interfere with the current transfer since that is already finished
by the time we get here. If it is the next transfer then this might just
be a symptom and the real problem might be somewhere else.

What additional information do you need ?

Reply via email to