perf-sched-fix-record-failure-when-config_schedstats.patch
asoc-wm_adsp-correct-wm_coeff_tlv_get-handling.patch
spi-imx-add-a-check-for-speed_hz-before-calculating-.patch
-spi-imx-mx51-ecspi-reinstate-low-speed-configreg-del.patch
spi-stm32-fixes-pm_runtime-calls-in-probe-remove.patch
regulator-hi6421-use-correct-variable-type-for-regma.patch
regulator-hi6421-fix-getting-wrong-drvdata.patch
+++ /dev/null
-From c86c9a2ccae44fc1873f351e77a6a91124d4b3d5 Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Sat, 3 Jul 2021 04:23:00 +0200
-Subject: spi: imx: mx51-ecspi: Reinstate low-speed CONFIGREG delay
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-From: Marek Vasut <marex@denx.de>
-
-[ Upstream commit 135cbd378eab336da15de9c84bbb22bf743b38a5 ]
-
-Since 00b80ac935539 ("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 in 6fd8b8503a0dc ("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: 00b80ac935539 ("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>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- drivers/spi/spi-imx.c | 38 +++++++++++++++++++-------------------
- 1 file changed, 19 insertions(+), 19 deletions(-)
-
-diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
-index c8b750d8ac35..8c0a6ea941ad 100644
---- a/drivers/spi/spi-imx.c
-+++ b/drivers/spi/spi-imx.c
-@@ -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;
- }
-
---
-2.30.2
-
perf-sched-fix-record-failure-when-config_schedstats.patch
kbuild-lto-fix-module-versionings-mismatch-in-gnu-ma.patch
asoc-wm_adsp-correct-wm_coeff_tlv_get-handling.patch
-spi-imx-mx51-ecspi-reinstate-low-speed-configreg-del.patch
spi-stm32-fixes-pm_runtime-calls-in-probe-remove.patch
regulator-hi6421-use-correct-variable-type-for-regma.patch
regulator-hi6421-fix-getting-wrong-drvdata.patch
+++ /dev/null
-From fb8623bcde96db8aed19abf7d473beba70b30c8d Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Sat, 3 Jul 2021 04:23:00 +0200
-Subject: spi: imx: mx51-ecspi: Reinstate low-speed CONFIGREG delay
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-From: Marek Vasut <marex@denx.de>
-
-[ Upstream commit 135cbd378eab336da15de9c84bbb22bf743b38a5 ]
-
-Since 00b80ac935539 ("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 in 6fd8b8503a0dc ("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: 00b80ac935539 ("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>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- drivers/spi/spi-imx.c | 38 +++++++++++++++++++-------------------
- 1 file changed, 19 insertions(+), 19 deletions(-)
-
-diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
-index 39dc02e366f4..4aee3db6d6df 100644
---- a/drivers/spi/spi-imx.c
-+++ b/drivers/spi/spi-imx.c
-@@ -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;
- }
-
---
-2.30.2
-
perf-probe-file-delete-namelist-in-del_events-on-the.patch
perf-data-close-all-files-in-close_dir.patch
spi-imx-add-a-check-for-speed_hz-before-calculating-.patch
-spi-imx-mx51-ecspi-reinstate-low-speed-configreg-del.patch
spi-stm32-use-dma_request_chan-instead-dma_request_s.patch
spi-stm32-fixes-pm_runtime-calls-in-probe-remove.patch
regulator-hi6421-use-correct-variable-type-for-regma.patch
+++ /dev/null
-From c715400ead6cd65dacd39ce130619f02cfbb262d Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Sat, 3 Jul 2021 04:23:00 +0200
-Subject: spi: imx: mx51-ecspi: Reinstate low-speed CONFIGREG delay
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-From: Marek Vasut <marex@denx.de>
-
-[ Upstream commit 135cbd378eab336da15de9c84bbb22bf743b38a5 ]
-
-Since 00b80ac935539 ("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 in 6fd8b8503a0dc ("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: 00b80ac935539 ("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>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- drivers/spi/spi-imx.c | 38 +++++++++++++++++++-------------------
- 1 file changed, 19 insertions(+), 19 deletions(-)
-
-diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
-index e237481dbbbb..14cebcda0ccc 100644
---- a/drivers/spi/spi-imx.c
-+++ b/drivers/spi/spi-imx.c
-@@ -498,7 +498,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 */
-@@ -559,6 +559,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;
- }
-
-@@ -566,7 +583,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;
-@@ -588,23 +605,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;
- }
-
---
-2.30.2
-
projects / thirdparty / kernel / stable-queue.git / commitdiff
