Hi Thomas,
On Wed, Jun 19, 2019 at 10:04 AM Thomas Schaefer Thomas.Schaefer@kontron.com wrote:
Hi all,
I've built current u-boot (v2019.07-rc4) with QSPI support for our i.MX7D Sabre eval system. I am using mx7dsabresd_qspi_defconfig.
The resulting u-boot fails to read from QSPI, i.e. the data read is not the same than that written before with a previous (v2018) version.
After some investigation I found that the 'is_controller_busy' function comes back with -ETIMEDOUT during read operation, because the retry count of 5 is too low.
To figure out how many retries are needed, I added some debug code as part of a while(1) loop to the is_controller_busy function:
diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index 1598c4f698..fa5b7a29f2 100644 --- a/drivers/spi/fsl_qspi.c +++ b/drivers/spi/fsl_qspi.c @@ -152,16 +152,20 @@ static inline int is_controller_busy(const struct fsl_qspi_priv *priv) u32 val; const u32 mask = QSPI_SR_BUSY_MASK | QSPI_SR_AHB_ACC_MASK | QSPI_SR_IP_ACC_MASK;
unsigned int retry = 5;
unsigned int retry = 0; do { val = qspi_read32(priv->flags, &priv->regs->sr);
if ((~val & mask) == mask)
if ((~val & mask) == mask) {if (retry > 5)printf("%s: timeout! retry = %d\n", __func__, retry); return 0;} udelay(1);
} while (--retry);
retry++;} while (1); return -ETIMEDOUT;}
On my MX7 eval system I found that a retry count between 73 and 147 is necessary to make sure that the controller will be ready before the next operation.
So from my point of view we have 2 options to fix this issue:
- increase retry from 5 to 200
- wait in an endless loop (while (1) ) and return only when the controller is ready (which means that the board will hang if the controller doesn't come back for some other reason.
What do you think?
I think that readl_poll_timeout() could be used here as it will timeout if the QSPI controller is not ready.
Also, could you check how this is handled in the fsl qspi driver in the kernel?