On Tuesday, September 01, 2015 at 11:13:38 AM, Chin Liang See wrote:
On Tue, 2015-09-01 at 11:01 +0200, marex@denx.de wrote:
On Tuesday, September 01, 2015 at 10:46:47 AM, Chin Liang See wrote:
Ensuring spi_calibration is run when there is a change of sclk frequency. This will ensure the qspi flash access works for high sclk frequency
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de Cc: Vikas Manocha vikas.manocha@st.com Cc: Jagannadh Teki jteki@openedev.com Cc: Pavel Machek pavel@denx.de
drivers/spi/cadence_qspi.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c index 34a0f46..512bf2d 100644 --- a/drivers/spi/cadence_qspi.c +++ b/drivers/spi/cadence_qspi.c @@ -128,6 +128,9 @@ static int cadence_spi_set_speed(struct udevice *bus, uint hz)
cadence_spi_write_speed(bus, hz);
- /* to ensure spi_calibration is run when SCLK frequency change */
- plat->max_hz = hz;
This looks like a hack, doesn't this change just subvert the condition below to enforce the calibration ?
Nope. I checked through debugger where plat->max_hz is initialized once with the value from device tree. When you use sf probe to change frequency, the value is not reflected to plat->max_hz. Hence the calibration is not run when frequency change. That lead to the sf probe fail when running at 80MHz or higher. Note the priv->qspi_calibrated_hz is updated after calibration succeed.
Isn't the purpose of ->max_hz to reflect the maximum frequency of the bus? I don't think this should thus ever be updated, in particular not by the user. I also think that setting ->max_hz once from DT is the correct behavior.
Best regards, Marek Vasut