diff options
author | Brandon Maier <brandon.maier@rockwellcollins.com> | 2021-01-20 23:28:30 +0300 |
---|---|---|
committer | Michal Simek <michal.simek@xilinx.com> | 2021-02-23 16:56:59 +0300 |
commit | d9aa19efa8a6c20d51b7884de0a7f8dae3f835d2 (patch) | |
tree | bc9a2aad017b6c45c3fcb0c852bd3dc7debc6c9b /drivers/i2c | |
parent | 3600d47b734129c9cb9772c587d0bf1fbc458cc6 (diff) | |
download | u-boot-d9aa19efa8a6c20d51b7884de0a7f8dae3f835d2.tar.xz |
spi: zynqmp_gqspi: fix set_speed bug on multiple runs
If zynqmp_qspi_set_speed() is called multiple times with the same speed,
then on the second call it will skip recalculating the baud_rate_val as
it assumes the speed is already configured correctly. But it will still
write the baud_rate_val to the configuration register and call
zynqmp_gqspi_set_tapdelay(). Because it skipped recalculating the
baud_rate_val, it will use the initial value of 0 . This causes the
driver to run at maximum speed which for many spi flashes is too fast and
causes data corruption.
Instead only write out a new baud_rate_val if we have calculated the
correct baud_rate_val.
This opens up another issue with the "if (speed == 0)", we don't save
off the new plat->speed_hz value when setting the baud rate on the
speed=0 path. Instead mimic what the Linux zynqmp gqspi driver does, and
have speed==0 just use the same calculation as a normal speed. That will
cause the baud_rate_val to use the slowest speed possible, which is the
safest option.
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
CC: jagan@amarulasolutions.com
CC: michal.simek@xilinx.com
CC: Ashok Reddy Soma <ashokred@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Diffstat (limited to 'drivers/i2c')
0 files changed, 0 insertions, 0 deletions