[PATCH] mtd: cqspi: Wait for transfer completion

[Jagan Teki]

On Wed, Sep 15, 2021 at 2:05 PM Marek Vasut <marex at 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 <marex at denx.de>
> >>>> Cc: Jagan Teki <jagan at amarulasolutions.com>
> >>>> Cc: Vignesh R <vigneshr at ti.com>
> >>>> Cc: Pratyush Yadav <p.yadav at 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?

Jagan.