mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-10-29 23:53:32 +00:00
spi: imx: mx51-ecspi: Reinstate low-speed CONFIGREG delay
Since00b80ac935
("spi: imx: mx51-ecspi: Move some initialisation to prepare_message hook."), the MX51_ECSPI_CONFIG write no longer happens in prepare_transfer hook, but rather in prepare_message hook, however the MX51_ECSPI_CONFIG delay is still left in prepare_transfer hook and thus has no effect. This leads to low bus frequency operation problems described in6fd8b8503a
("spi: spi-imx: Fix out-of-order CS/SCLK operation at low speeds") again. Move the MX51_ECSPI_CONFIG write delay into the prepare_message hook as well, thus reinstating the low bus frequency fix. Fixes:00b80ac935
("spi: imx: mx51-ecspi: Move some initialisation to prepare_message hook.") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210703022300.296114-1-marex@denx.de Signed-off-by: Mark Brown <broonie@kernel.org>
This commit is contained in:
parent
e4a5c19888
commit
135cbd378e
1 changed files with 19 additions and 19 deletions
|
@ -506,7 +506,7 @@ static int mx51_ecspi_prepare_message(struct spi_imx_data *spi_imx,
|
|||
{
|
||||
struct spi_device *spi = msg->spi;
|
||||
u32 ctrl = MX51_ECSPI_CTRL_ENABLE;
|
||||
u32 testreg;
|
||||
u32 testreg, delay;
|
||||
u32 cfg = readl(spi_imx->base + MX51_ECSPI_CONFIG);
|
||||
|
||||
/* set Master or Slave mode */
|
||||
|
@ -567,6 +567,23 @@ static int mx51_ecspi_prepare_message(struct spi_imx_data *spi_imx,
|
|||
|
||||
writel(cfg, spi_imx->base + MX51_ECSPI_CONFIG);
|
||||
|
||||
/*
|
||||
* Wait until the changes in the configuration register CONFIGREG
|
||||
* propagate into the hardware. It takes exactly one tick of the
|
||||
* SCLK clock, but we will wait two SCLK clock just to be sure. The
|
||||
* effect of the delay it takes for the hardware to apply changes
|
||||
* is noticable if the SCLK clock run very slow. In such a case, if
|
||||
* the polarity of SCLK should be inverted, the GPIO ChipSelect might
|
||||
* be asserted before the SCLK polarity changes, which would disrupt
|
||||
* the SPI communication as the device on the other end would consider
|
||||
* the change of SCLK polarity as a clock tick already.
|
||||
*/
|
||||
delay = (2 * 1000000) / spi_imx->spi_bus_clk;
|
||||
if (likely(delay < 10)) /* SCLK is faster than 100 kHz */
|
||||
udelay(delay);
|
||||
else /* SCLK is _very_ slow */
|
||||
usleep_range(delay, delay + 10);
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
@ -574,7 +591,7 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
|
|||
struct spi_device *spi)
|
||||
{
|
||||
u32 ctrl = readl(spi_imx->base + MX51_ECSPI_CTRL);
|
||||
u32 clk, delay;
|
||||
u32 clk;
|
||||
|
||||
/* Clear BL field and set the right value */
|
||||
ctrl &= ~MX51_ECSPI_CTRL_BL_MASK;
|
||||
|
@ -596,23 +613,6 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
|
|||
|
||||
writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
|
||||
|
||||
/*
|
||||
* Wait until the changes in the configuration register CONFIGREG
|
||||
* propagate into the hardware. It takes exactly one tick of the
|
||||
* SCLK clock, but we will wait two SCLK clock just to be sure. The
|
||||
* effect of the delay it takes for the hardware to apply changes
|
||||
* is noticable if the SCLK clock run very slow. In such a case, if
|
||||
* the polarity of SCLK should be inverted, the GPIO ChipSelect might
|
||||
* be asserted before the SCLK polarity changes, which would disrupt
|
||||
* the SPI communication as the device on the other end would consider
|
||||
* the change of SCLK polarity as a clock tick already.
|
||||
*/
|
||||
delay = (2 * 1000000) / clk;
|
||||
if (likely(delay < 10)) /* SCLK is faster than 100 kHz */
|
||||
udelay(delay);
|
||||
else /* SCLK is _very_ slow */
|
||||
usleep_range(delay, delay + 10);
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
|
Loading…
Reference in a new issue