On Wed, Mar 12, 2014 at 1:32 AM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > On Tuesday 11 March 2014 17:23:37 Geert Uytterhoeven wrote: >> Hi Laurent, >> >> On Tue, Mar 11, 2014 at 4:55 PM, Laurent Pinchart wrote: >> > Does this require drivers/sh/pm_runtime.c to be compiled in ? >> >> Let's check... >> >> My koelsch-legacy kernel has drivers/sh/pm_runtime.c compiled in. >> My koelsch-reference kernel hasn't. >> >> However, under the -reference kernel many MSTP clocks (incl. MSIOF) >> seem to be enabled all the time, while under -legacy they are enabled and >> disabled on demand. > > Is PM_RUNTIME enabled in both cases ? > > > There's something fishy in there that we should try to fix without too further > much delay. Ben Dooks has pointed out the problem a couple of months ago, but > the discussion on the mailing list just died. Yes, Runtime PM is not working as expected in the multiplatform case, that is true. I propose that we keep Runtime PM disabled in the Kconfig for R-Car Gen2 for now to keep things simple. >From my side I see it as two separate solutions. The short term fix is to temporarily work around drivers that depend on Runtime PM for clock control, I propose enabling selected clocks statically using the function introduced by this series: [PATCH 00/03] ARM: shmobile: Break out and extend clock workaround http://www.spinics.net/lists/arm-kernel/msg310278.html The long term fix I'm not sure sure about, but I trust Geert to figure it out. =) Regardless, rushing to fix this "correctly" seems as useful to me as dead line driven DT development.... Thanks, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html