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 marex@denx.de Cc: Jagan Teki jagan@amarulasolutions.com Cc: Vignesh R vigneshr@ti.com Cc: Pratyush Yadav p.yadav@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.