2020-08-10 07:14:10

by Alain Volmat

[permalink] [raw]
Subject: [PATCH v2 0/5] spi: stm32: various driver fixes

This serie is a reduced version of the serie
[spi: stm32: various driver enhancements] previously sent.

Alain Volmat (1):
spi: stm32: always perform registers configuration prior to transfer

Amelie Delaunay (3):
spi: stm32: fix fifo threshold level in case of short transfer
spi: stm32: fix stm32_spi_prepare_mbr in case of odd clk_rate
spi: stm32: fixes suspend/resume management

Antonio Borneo (1):
spi: stm32h7: fix race condition at end of transfer

drivers/spi/spi-stm32.c | 98 ++++++++++++++++++++++++++++++-------------------
1 file changed, 61 insertions(+), 37 deletions(-)

--
v2: fix conditional statement within [spi: stm32: fix fifo threshold level in case of short transfer]


2020-08-10 07:14:28

by Alain Volmat

[permalink] [raw]
Subject: [PATCH v2 4/5] spi: stm32: fixes suspend/resume management

From: Amelie Delaunay <[email protected]>

This patch adds pinctrl power management, and reconfigure spi controller
in case of resume.

Fixes: 038ac869c9d2 ("spi: stm32: add runtime PM support")

Signed-off-by: Amelie Delaunay <[email protected]>
Signed-off-by: Alain Volmat <[email protected]>
---
v2: identical to v1

drivers/spi/spi-stm32.c | 27 ++++++++++++++++++++++++---
1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-stm32.c
index 571dea72bf7e..9b90a22543fd 100644
--- a/drivers/spi/spi-stm32.c
+++ b/drivers/spi/spi-stm32.c
@@ -13,6 +13,7 @@
#include <linux/iopoll.h>
#include <linux/module.h>
#include <linux/of_platform.h>
+#include <linux/pinctrl/consumer.h>
#include <linux/pm_runtime.h>
#include <linux/reset.h>
#include <linux/spi/spi.h>
@@ -2007,6 +2008,8 @@ static int stm32_spi_remove(struct platform_device *pdev)

pm_runtime_disable(&pdev->dev);

+ pinctrl_pm_select_sleep_state(&pdev->dev);
+
return 0;
}

@@ -2018,13 +2021,18 @@ static int stm32_spi_runtime_suspend(struct device *dev)

clk_disable_unprepare(spi->clk);

- return 0;
+ return pinctrl_pm_select_sleep_state(dev);
}

static int stm32_spi_runtime_resume(struct device *dev)
{
struct spi_master *master = dev_get_drvdata(dev);
struct stm32_spi *spi = spi_master_get_devdata(master);
+ int ret;
+
+ ret = pinctrl_pm_select_default_state(dev);
+ if (ret)
+ return ret;

return clk_prepare_enable(spi->clk);
}
@@ -2054,10 +2062,23 @@ static int stm32_spi_resume(struct device *dev)
return ret;

ret = spi_master_resume(master);
- if (ret)
+ if (ret) {
clk_disable_unprepare(spi->clk);
+ return ret;
+ }

- return ret;
+ ret = pm_runtime_get_sync(dev);
+ if (ret) {
+ dev_err(dev, "Unable to power device:%d\n", ret);
+ return ret;
+ }
+
+ spi->cfg->config(spi);
+
+ pm_runtime_mark_last_busy(dev);
+ pm_runtime_put_autosuspend(dev);
+
+ return 0;
}
#endif

--
2.7.4

2020-08-10 07:16:23

by Alain Volmat

[permalink] [raw]
Subject: [PATCH v2 1/5] spi: stm32h7: fix race condition at end of transfer

From: Antonio Borneo <[email protected]>

The caller of stm32_spi_transfer_one(), spi_transfer_one_message(),
is waiting for us to call spi_finalize_current_transfer() and will
eventually schedule a new transfer, if available.
We should guarantee that the spi controller is really available
before calling spi_finalize_current_transfer().

Move the call to spi_finalize_current_transfer() _after_ the call
to stm32_spi_disable().

Signed-off-by: Antonio Borneo <[email protected]>
Signed-off-by: Alain Volmat <[email protected]>
---
v2: identical to v1

drivers/spi/spi-stm32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-stm32.c
index 4a21feae0103..814a3ec3b8ad 100644
--- a/drivers/spi/spi-stm32.c
+++ b/drivers/spi/spi-stm32.c
@@ -971,8 +971,8 @@ static irqreturn_t stm32h7_spi_irq_thread(int irq, void *dev_id)
spin_unlock_irqrestore(&spi->lock, flags);

if (end) {
- spi_finalize_current_transfer(master);
stm32h7_spi_disable(spi);
+ spi_finalize_current_transfer(master);
}

return IRQ_HANDLED;
--
2.7.4

2020-08-10 07:16:51

by Alain Volmat

[permalink] [raw]
Subject: [PATCH v2 5/5] spi: stm32: always perform registers configuration prior to transfer

SPI registers content may have been lost upon suspend/resume sequence.
So, always compute and apply the necessary configuration in
stm32_spi_transfer_one_setup routine.

Signed-off-by: Alain Volmat <[email protected]>
---
v2: identical to v1

drivers/spi/spi-stm32.c | 42 +++++++++++++++++-------------------------
1 file changed, 17 insertions(+), 25 deletions(-)

diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-stm32.c
index 9b90a22543fd..d4b33b358a31 100644
--- a/drivers/spi/spi-stm32.c
+++ b/drivers/spi/spi-stm32.c
@@ -1597,41 +1597,33 @@ static int stm32_spi_transfer_one_setup(struct stm32_spi *spi,
unsigned long flags;
unsigned int comm_type;
int nb_words, ret = 0;
+ int mbr;

spin_lock_irqsave(&spi->lock, flags);

spi->cur_xferlen = transfer->len;

- if (spi->cur_bpw != transfer->bits_per_word) {
- spi->cur_bpw = transfer->bits_per_word;
- spi->cfg->set_bpw(spi);
- }
-
- if (spi->cur_speed != transfer->speed_hz) {
- int mbr;
-
- /* Update spi->cur_speed with real clock speed */
- mbr = stm32_spi_prepare_mbr(spi, transfer->speed_hz,
- spi->cfg->baud_rate_div_min,
- spi->cfg->baud_rate_div_max);
- if (mbr < 0) {
- ret = mbr;
- goto out;
- }
+ spi->cur_bpw = transfer->bits_per_word;
+ spi->cfg->set_bpw(spi);

- transfer->speed_hz = spi->cur_speed;
- stm32_spi_set_mbr(spi, mbr);
+ /* Update spi->cur_speed with real clock speed */
+ mbr = stm32_spi_prepare_mbr(spi, transfer->speed_hz,
+ spi->cfg->baud_rate_div_min,
+ spi->cfg->baud_rate_div_max);
+ if (mbr < 0) {
+ ret = mbr;
+ goto out;
}

- comm_type = stm32_spi_communication_type(spi_dev, transfer);
- if (spi->cur_comm != comm_type) {
- ret = spi->cfg->set_mode(spi, comm_type);
+ transfer->speed_hz = spi->cur_speed;
+ stm32_spi_set_mbr(spi, mbr);

- if (ret < 0)
- goto out;
+ comm_type = stm32_spi_communication_type(spi_dev, transfer);
+ ret = spi->cfg->set_mode(spi, comm_type);
+ if (ret < 0)
+ goto out;

- spi->cur_comm = comm_type;
- }
+ spi->cur_comm = comm_type;

if (spi->cfg->set_data_idleness)
spi->cfg->set_data_idleness(spi, transfer->len);
--
2.7.4

2020-08-10 19:00:34

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH v2 0/5] spi: stm32: various driver fixes

On Mon, 10 Aug 2020 09:12:33 +0200, Alain Volmat wrote:
> This serie is a reduced version of the serie
> [spi: stm32: various driver enhancements] previously sent.
>
> Alain Volmat (1):
> spi: stm32: always perform registers configuration prior to transfer
>
> Amelie Delaunay (3):
> spi: stm32: fix fifo threshold level in case of short transfer
> spi: stm32: fix stm32_spi_prepare_mbr in case of odd clk_rate
> spi: stm32: fixes suspend/resume management
>
> [...]

Applied to

https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/5] spi: stm32h7: fix race condition at end of transfer
commit: 135dd873d3c76d812ae64c668adef3f2c59ed27f
[2/5] spi: stm32: fix fifo threshold level in case of short transfer
commit: 3373e9004acc0603242622b4378c64bc01d21b5f
[3/5] spi: stm32: fix stm32_spi_prepare_mbr in case of odd clk_rate
commit: 9cc61973bf9385b19ff5dda4a2a7e265fcba85e4
[4/5] spi: stm32: fixes suspend/resume management
commit: db96bf976a4fc65439be0b4524c0d41427d98814
[5/5] spi: stm32: always perform registers configuration prior to transfer
commit: 60ccb3515fc61a0124c70aa37317f75b67560024

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark