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?
Jagan.
