Re: [RFC PATCH 01/10] spi: spi-mem: Introduce support for tuning controller

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hello Santhosh,

>>>     - On tuning failure, retry by re-running spi_mem_needs_tuning() with
>>> the second best set of ops (max throughput - 1)
>> I would like to challenge this need. Can the same calibration fail if
>> attempted multiple times (eg. because of the heat?) If yes, then we need
>> a fallback indeed. Otherwise, I'd be in favor of just failing the
>> probe. Calibration is an opt-in -> users must allow a higher frequency
>> than they use to in order to enable the feature?
>
> It's possible the same calibration will fail intermittently for
> different reasons (temperature changes, as you mentioned). If tuning
> fails, the driver should fallback to the non-PHY frequency so the flash
> continues operating with slower reads/writes rather than failing the
> probe (availability should be prioritized, right?).

Agreed, if the tuning may fail we must fallback in this case. However
there is another situation that must be handled in this case: once
tuning is done and we want to use PHY-optimized paths, we must fallback
to more basic/slower reads if for some external reason, they start
failing, right?

The obvious choice in this case would be to let this error handling to
the controller driver. Re-using the same operation at a lower speed
would be suboptimal, because the fastest operation at a high speed might
not be the most efficient at slower speeds due to the number of dummy
cycles needed,. But I believe this is negligible based on the fact that
we already are in degraded mode at that stage.

However, this may conflict with:
- read retries
- continuous reads (?)

So in practice the fallback might be needed on the SPI NAND/NOR side
(this can be further discussed).

But once we solve this, comes a similar problem on the write side. How
do we know if a write will or did fail because of a temperature change?
What may be the heuristics to fallback in this case?

Thanks,
Miquèl