| Message ID | 20210716182133.218640-1-marex@denx.de (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 56912da7a68c8356df6a6740476237441b0b792a |
| Headers | show |
| Series | spi: cadence: Correct initialisation of runtime PM again | expand |
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
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 !
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
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");
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(-)