[PATCH] mtd: cqspi: Wait for transfer completion

[Marek Vasut]

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