[PATCH] spi: cadence: Correct initialisation of runtime PM again

[PATCH] spi: cadence: Correct initialisation of runtime PM again

[Marek Vasut]

The original implementation of RPM handling in probe() was mostly
correct, except it failed to call pm_runtime_get_*() to activate the
hardware. The subsequent fix, 734882a8bf98 ("spi: cadence: Correct
initialisation of runtime PM"), breaks the implementation further,
to the point where the system using this hard IP on ZynqMP hangs on
boot, because it accesses hardware which is gated off.

Undo 734882a8bf98 ("spi: cadence: Correct initialisation of runtime
PM") and instead add missing pm_runtime_get_noresume() and move the
RPM disabling all the way to the end of probe(). That makes ZynqMP
not hang on boot yet again.

Fixes: 734882a8bf98 ("spi: cadence: Correct initialisation of runtime PM")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Charles Keepax <ckeepax@opensource.cirrus.com>
Cc: Mark Brown <broonie@kernel.org>
---
 drivers/spi/spi-cadence.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/spi-cadence.c b/drivers/spi/spi-cadence.c
index a3afd1b9ac56..ceb16e70d235 100644
--- a/drivers/spi/spi-cadence.c
+++ b/drivers/spi/spi-cadence.c
@@ -517,6 +517,12 @@ static int cdns_spi_probe(struct platform_device *pdev)
 		goto clk_dis_apb;
 	}
 
+	pm_runtime_use_autosuspend(&pdev->dev);
+	pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT);
+	pm_runtime_get_noresume(&pdev->dev);
+	pm_runtime_set_active(&pdev->dev);
+	pm_runtime_enable(&pdev->dev);
+
 	ret = of_property_read_u32(pdev->dev.of_node, "num-cs", &num_cs);
 	if (ret < 0)
 		master->num_chipselect = CDNS_SPI_DEFAULT_NUM_CS;
@@ -531,11 +537,6 @@ static int cdns_spi_probe(struct platform_device *pdev)
 	/* SPI controller initializations */
 	cdns_spi_init_hw(xspi);
 
-	pm_runtime_set_active(&pdev->dev);
-	pm_runtime_enable(&pdev->dev);
-	pm_runtime_use_autosuspend(&pdev->dev);
-	pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT);
-
 	irq = platform_get_irq(pdev, 0);
 	if (irq <= 0) {
 		ret = -ENXIO;
@@ -566,6 +567,9 @@ static int cdns_spi_probe(struct platform_device *pdev)
 
 	master->bits_per_word_mask = SPI_BPW_MASK(8);
 
+	pm_runtime_mark_last_busy(&pdev->dev);
+	pm_runtime_put_autosuspend(&pdev->dev);
+
 	ret = spi_register_master(master);
 	if (ret) {
 		dev_err(&pdev->dev, "spi_register_master failed\n");
-- 
2.30.2

Re: [PATCH] spi: cadence: Correct initialisation of runtime PM again

[Charles Keepax]

On Fri, Jul 16, 2021 at 08:21:33PM +0200, Marek Vasut wrote:
> The original implementation of RPM handling in probe() was mostly
> correct, except it failed to call pm_runtime_get_*() to activate the
> hardware. The subsequent fix, 734882a8bf98 ("spi: cadence: Correct
> initialisation of runtime PM"), breaks the implementation further,
> to the point where the system using this hard IP on ZynqMP hangs on
> boot, because it accesses hardware which is gated off.
> 
> Undo 734882a8bf98 ("spi: cadence: Correct initialisation of runtime
> PM") and instead add missing pm_runtime_get_noresume() and move the
> RPM disabling all the way to the end of probe(). That makes ZynqMP
> not hang on boot yet again.
> 
> Fixes: 734882a8bf98 ("spi: cadence: Correct initialisation of runtime PM")
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Charles Keepax <ckeepax@opensource.cirrus.com>
> Cc: Mark Brown <broonie@kernel.org>
> ---

For my own edification do you know exactly what the problem was
on your system here? I am assuming my mistake was that without the
pm_runtime reference being taken, some required parent doesn't get
enabled, which is convienently fine on my Zynq but not your ZynqMP?

The inclusion of the IRQ stuff in the pm_runtime block makes me a
little nervous as if the problem is that your hardware generates
a spurious IRQ on boot and that is where the bad access comes from
this code feels racy. The original code did the put before the IRQ
registers as well.

All that said, works on my Zynq:

Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com>

Thanks,
Charles

Re: [PATCH] spi: cadence: Correct initialisation of runtime PM again

[Marek Vasut]

On 7/19/21 11:01 AM, Charles Keepax wrote:
> On Fri, Jul 16, 2021 at 08:21:33PM +0200, Marek Vasut wrote:
>> The original implementation of RPM handling in probe() was mostly
>> correct, except it failed to call pm_runtime_get_*() to activate the
>> hardware. The subsequent fix, 734882a8bf98 ("spi: cadence: Correct
>> initialisation of runtime PM"), breaks the implementation further,
>> to the point where the system using this hard IP on ZynqMP hangs on
>> boot, because it accesses hardware which is gated off.
>>
>> Undo 734882a8bf98 ("spi: cadence: Correct initialisation of runtime
>> PM") and instead add missing pm_runtime_get_noresume() and move the
>> RPM disabling all the way to the end of probe(). That makes ZynqMP
>> not hang on boot yet again.
>>
>> Fixes: 734882a8bf98 ("spi: cadence: Correct initialisation of runtime PM")
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> Cc: Charles Keepax <ckeepax@opensource.cirrus.com>
>> Cc: Mark Brown <broonie@kernel.org>
>> ---
> 
> For my own edification do you know exactly what the problem was
> on your system here? I am assuming my mistake was that without the
> pm_runtime reference being taken, some required parent doesn't get
> enabled, which is convienently fine on my Zynq but not your ZynqMP?

Yes, the hardware got suspended a bit too early.

> The inclusion of the IRQ stuff in the pm_runtime block makes me a
> little nervous as if the problem is that your hardware generates
> a spurious IRQ on boot and that is where the bad access comes from
> this code feels racy. The original code did the put before the IRQ
> registers as well.

You could get an interrupt indeed, but that's not the case here.

> All that said, works on my Zynq:
> 
> Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com>

Thanks !

Re: [PATCH] spi: cadence: Correct initialisation of runtime PM again

[Mark Brown]

On Fri, 16 Jul 2021 20:21:33 +0200, Marek Vasut wrote:
> The original implementation of RPM handling in probe() was mostly
> correct, except it failed to call pm_runtime_get_*() to activate the
> hardware. The subsequent fix, 734882a8bf98 ("spi: cadence: Correct
> initialisation of runtime PM"), breaks the implementation further,
> to the point where the system using this hard IP on ZynqMP hangs on
> boot, because it accesses hardware which is gated off.
> 
> [...]

Applied to

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

Thanks!

[1/1] spi: cadence: Correct initialisation of runtime PM again
      commit: 56912da7a68c8356df6a6740476237441b0b792a

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