| Message ID | 1394531952-3905-3-git-send-email-geert@linux-m68k.org (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 490c97747d5dc77dfb5826e2823b41d8b2ef7ecc |
| Headers | show |
On Tue, Mar 11, 2014 at 10:59:12AM +0100, Geert Uytterhoeven wrote: > From: Geert Uytterhoeven <geert+renesas@linux-m68k.org> Applied, thanks, though... > - ret = clk_prepare_enable(rspi->clk); > - if (ret < 0) { > - dev_err(&pdev->dev, "unable to prepare/enable clock\n"); > - goto error1; > - } > + pm_runtime_enable(&pdev->dev); ...due to the runtime PM API being configurable you're supposed to start off with the device runtime enabled (this applies to some of the other patches too). I'm not sure that's terribly realistic for these drivers though.
Hi Mark, On Tue, Mar 11, 2014 at 11:47 AM, Mark Brown <broonie@kernel.org> wrote: > On Tue, Mar 11, 2014 at 10:59:12AM +0100, Geert Uytterhoeven wrote: >> From: Geert Uytterhoeven <geert+renesas@linux-m68k.org> > > Applied, thanks, though... > >> - ret = clk_prepare_enable(rspi->clk); >> - if (ret < 0) { >> - dev_err(&pdev->dev, "unable to prepare/enable clock\n"); >> - goto error1; >> - } >> + pm_runtime_enable(&pdev->dev); > > ...due to the runtime PM API being configurable you're supposed to start > off with the device runtime enabled (this applies to some of the other > patches too). I'm not sure that's terribly realistic for these drivers > though. Can you please elaborate what should be fixed? If I disable CONFIG_PM_RUNTIME, the kernel prints: Runtime PM disabled, clock forced on. and the clock is enabled all the time (verified by looking at the clock registers)? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 11, 2014 at 02:10:31PM +0100, Geert Uytterhoeven wrote: > Can you please elaborate what should be fixed? > If I disable CONFIG_PM_RUNTIME, the kernel prints: > Runtime PM disabled, clock forced on. > and the clock is enabled all the time (verified by looking at the clock > registers)? That's very SH specific and doesn't apply in the general case (I would not be surprised if future SH updates broke it...).
Hi Mark, On Tue, Mar 11, 2014 at 2:26 PM, Mark Brown <broonie@kernel.org> wrote: > On Tue, Mar 11, 2014 at 02:10:31PM +0100, Geert Uytterhoeven wrote: > >> Can you please elaborate what should be fixed? > >> If I disable CONFIG_PM_RUNTIME, the kernel prints: > >> Runtime PM disabled, clock forced on. > >> and the clock is enabled all the time (verified by looking at the clock >> registers)? > > That's very SH specific and doesn't apply in the general case (I would > not be surprised if future SH updates broke it...). Note that this is from drivers/base/power/clock_ops.c So what should I do instead? Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 11, 2014 at 02:35:15PM +0100, Geert Uytterhoeven wrote: > On Tue, Mar 11, 2014 at 2:26 PM, Mark Brown <broonie@kernel.org> wrote: > > On Tue, Mar 11, 2014 at 02:10:31PM +0100, Geert Uytterhoeven wrote: > >> Can you please elaborate what should be fixed? > >> If I disable CONFIG_PM_RUNTIME, the kernel prints: > >> Runtime PM disabled, clock forced on. > >> and the clock is enabled all the time (verified by looking at the clock > >> registers)? > > That's very SH specific and doesn't apply in the general case (I would > > not be surprised if future SH updates broke it...). > Note that this is from drivers/base/power/clock_ops.c > So what should I do instead? Oh, is this manipulating the clock managed by the power domains? If that's the case don't worry about it, it's fine. I'd thought it was another clock.
diff --git a/drivers/spi/spi-rspi.c b/drivers/spi/spi-rspi.c index 92bec7e91046..1fb0ad213324 100644 --- a/drivers/spi/spi-rspi.c +++ b/drivers/spi/spi-rspi.c @@ -33,6 +33,7 @@ #include <linux/dmaengine.h> #include <linux/dma-mapping.h> #include <linux/of_device.h> +#include <linux/pm_runtime.h> #include <linux/sh_dma.h> #include <linux/spi/spi.h> #include <linux/spi/rspi.h> @@ -1111,7 +1112,7 @@ static int rspi_remove(struct platform_device *pdev) struct rspi_data *rspi = platform_get_drvdata(pdev); rspi_release_dma(rspi); - clk_disable_unprepare(rspi->clk); + pm_runtime_disable(&pdev->dev); return 0; } @@ -1242,16 +1243,13 @@ static int rspi_probe(struct platform_device *pdev) goto error1; } - ret = clk_prepare_enable(rspi->clk); - if (ret < 0) { - dev_err(&pdev->dev, "unable to prepare/enable clock\n"); - goto error1; - } + pm_runtime_enable(&pdev->dev); init_waitqueue_head(&rspi->wait); master->bus_num = pdev->id; master->setup = rspi_setup; + master->auto_runtime_pm = true; master->transfer_one = ops->transfer_one; master->prepare_message = rspi_prepare_message; master->unprepare_message = rspi_unprepare_message; @@ -1312,7 +1310,7 @@ static int rspi_probe(struct platform_device *pdev) error3: rspi_release_dma(rspi); error2: - clk_disable_unprepare(rspi->clk); + pm_runtime_disable(&pdev->dev); error1: spi_master_put(master);