[PATCH] mtd: cqspi: Wait for transfer completion

[Marek Vasut]

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.