[PATCH v4] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI

[PATCH v4] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI

[Geert Uytterhoeven]

If the kernel is built to support multi-ARM configuration with shmobile
support built in, then drivers/sh is not built. This contains the PM
runtime code in drivers/sh/pm_runtime.c, which implicitly enables the
module clocks for all devices, and thus is quite essential.
Without this, the state of clocks depends on implicit reset state, or on
the bootloader.

If ARCH_SHMOBILE_MULTI then build the drivers/sh directory, but ensure that
bits that may conflict (drivers/sh/clk if the common clock framework is
enabled) or are not used (drivers/sh/intc), are not built.
Also, only enable the PM runtime code when actually running on a shmobile
SoCs that needs it.

ARCH_SHMOBILE_MULTI was added a while ago by commit
efacfce5f8a523457e9419a25d52fe39db00b26a ("ARM: shmobile: Introduce
ARCH_SHMOBILE_MULTI"), but drivers/sh was compiled for both
ARCH_SHMOBILE_LEGACY and ARCH_SHMOBILE_MULTI until commit
bf98c1eac1d4a6bcf00532e4fa41d8126cd6c187 ("ARM: Rename ARCH_SHMOBILE to
ARCH_SHMOBILE_LEGACY").

Inspired by a patch from Ben Dooks <ben.dooks@codethink.co.uk>.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
This is a minimal solution to fix the issue for multi-platform shmobile
kernels in a multi-platform-friendly way.
As it touches drivers/sh-specific code only, Simom should still be able to
get it in v3.15, and backported to v3.14-stable.

Tested on Koelsch (legacy, reference, shmobile, and shmobile+bbb kernels)
and BeagleBone Black (shmobile+bbb). Will test on more hardware tomorrow.
Without this patch, (1) removing the clk_enables[] causes the thermal
sensor to fail, and (2) disabling all MSTP clocks on bootup causes the
thermal sensor, RSPI, MSIOF, and SH_ETH to fail.

v4:
  - Re-add lost "static" to sh_pm_runtime_init,
  - Use IS_ENABLED() instead of #ifdef, to increase compile coverage
    (as suggested by Ben Dooks),
v3:
  - Add of_machine_is_compatible() checks for multi-platform
  - Remove Reviewed-by, Tested-by, as too much has changed,
  - Assumed authorship, as not much is left from the original patch from
    Ben (Ben: is that OK?),
v2:
  - Add Reviewed-by, Tested-by.
---
 drivers/Makefile        |    2 +-
 drivers/sh/Makefile     |   14 ++++++++------
 drivers/sh/pm_runtime.c |   20 +++++++++++++++++++-
 3 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index d05d81b19b50..7183b6af5dac 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -119,7 +119,7 @@ obj-$(CONFIG_SGI_SN)		+= sn/
 obj-y				+= firmware/
 obj-$(CONFIG_CRYPTO)		+= crypto/
 obj-$(CONFIG_SUPERH)		+= sh/
-obj-$(CONFIG_ARCH_SHMOBILE_LEGACY)	+= sh/
+obj-$(CONFIG_ARCH_SHMOBILE)	+= sh/
 ifndef CONFIG_ARCH_USES_GETTIMEOFFSET
 obj-y				+= clocksource/
 endif
diff --git a/drivers/sh/Makefile b/drivers/sh/Makefile
index fc67f564f02c..788ed9b59b4e 100644
--- a/drivers/sh/Makefile
+++ b/drivers/sh/Makefile
@@ -1,10 +1,12 @@
 #
 # Makefile for the SuperH specific drivers.
 #
-obj-y	:= intc/
+obj-$(CONFIG_SUPERH)			+= intc/
+obj-$(CONFIG_ARCH_SHMOBILE_LEGACY)	+= intc/
+ifneq ($(CONFIG_COMMON_CLK),y)
+obj-$(CONFIG_HAVE_CLK)			+= clk/
+endif
+obj-$(CONFIG_MAPLE)			+= maple/
+obj-$(CONFIG_SUPERHYWAY)		+= superhyway/
 
-obj-$(CONFIG_HAVE_CLK)		+= clk/
-obj-$(CONFIG_MAPLE)		+= maple/
-obj-$(CONFIG_SUPERHYWAY)	+= superhyway/
-
-obj-y				+= pm_runtime.o
+obj-y					+= pm_runtime.o
diff --git a/drivers/sh/pm_runtime.c b/drivers/sh/pm_runtime.c
index 8afa5a4589f2..10c65eb51f85 100644
--- a/drivers/sh/pm_runtime.c
+++ b/drivers/sh/pm_runtime.c
@@ -50,8 +50,25 @@ static struct pm_clk_notifier_block platform_bus_notifier = {
 	.con_ids = { NULL, },
 };
 
+static bool default_pm_on;
+
 static int __init sh_pm_runtime_init(void)
 {
+	if (IS_ENABLED(CONFIG_ARCH_SHMOBILE_MULTI)) {
+		if (!of_machine_is_compatible("renesas,emev2") &&
+		    !of_machine_is_compatible("renesas,r7s72100") &&
+		    !of_machine_is_compatible("renesas,r8a73a4") &&
+		    !of_machine_is_compatible("renesas,r8a7740") &&
+		    !of_machine_is_compatible("renesas,r8a7778") &&
+		    !of_machine_is_compatible("renesas,r8a7779") &&
+		    !of_machine_is_compatible("renesas,r8a7790") &&
+		    !of_machine_is_compatible("renesas,r8a7791") &&
+		    !of_machine_is_compatible("renesas,sh7372") &&
+		    !of_machine_is_compatible("renesas,sh73a0"))
+			return 0;
+	}
+
+	default_pm_on = true;
 	pm_clk_add_notifier(&platform_bus_type, &platform_bus_notifier);
 	return 0;
 }
@@ -59,7 +76,8 @@ core_initcall(sh_pm_runtime_init);
 
 static int __init sh_pm_runtime_late_init(void)
 {
-	pm_genpd_poweroff_unused();
+	if (default_pm_on)
+		pm_genpd_poweroff_unused();
 	return 0;
 }
 late_initcall(sh_pm_runtime_late_init);
-- 
1.7.9.5

[PATCH v4] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI

[Geert Uytterhoeven]

On Tue, May 6, 2014 at 11:26 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Tested on Koelsch (legacy, reference, shmobile, and shmobile+bbb kernels)
> and BeagleBone Black (shmobile+bbb). Will test on more hardware tomorrow.

Tested on genmai with Wolfram's CCF support.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[PATCH v4] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI

[Simon Horman]

On Thu, May 08, 2014 at 12:12:29PM +0200, Geert Uytterhoeven wrote:
> On Tue, May 6, 2014 at 11:26 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
> > Tested on Koelsch (legacy, reference, shmobile, and shmobile+bbb kernels)
> > and BeagleBone Black (shmobile+bbb). Will test on more hardware tomorrow.
> 
> Tested on genmai with Wolfram's CCF support.

Thanks, shall I go ahead and queue this up?

[PATCH v4] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI

[Magnus Damm]

On Sun, May 11, 2014 at 9:46 AM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, May 08, 2014 at 12:12:29PM +0200, Geert Uytterhoeven wrote:
>> On Tue, May 6, 2014 at 11:26 PM, Geert Uytterhoeven
>> <geert+renesas@glider.be> wrote:
>> > Tested on Koelsch (legacy, reference, shmobile, and shmobile+bbb kernels)
>> > and BeagleBone Black (shmobile+bbb). Will test on more hardware tomorrow.
>>
>> Tested on genmai with Wolfram's CCF support.
>
> Thanks, shall I go ahead and queue this up?

Yes please, at least from my side everything looks perfect.

Cheers,

/ magnus

[PATCH v4] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI

[Simon Horman]

On Mon, May 12, 2014 at 08:24:03AM +0900, Magnus Damm wrote:
> On Sun, May 11, 2014 at 9:46 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Thu, May 08, 2014 at 12:12:29PM +0200, Geert Uytterhoeven wrote:
> >> On Tue, May 6, 2014 at 11:26 PM, Geert Uytterhoeven
> >> <geert+renesas@glider.be> wrote:
> >> > Tested on Koelsch (legacy, reference, shmobile, and shmobile+bbb kernels)
> >> > and BeagleBone Black (shmobile+bbb). Will test on more hardware tomorrow.
> >>
> >> Tested on genmai with Wolfram's CCF support.
> >
> > Thanks, shall I go ahead and queue this up?
> 
> Yes please, at least from my side everything looks perfect.

Thanks, will do.

I currently plan to send this on to Linus when the merge window
opens for v3.16.

This differs from other patches I have queued up (until now) which
I have or intend to send via the ARM SoC tree.

[PATCH v4] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI

[Geert Uytterhoeven]

Hi Simon,

On Mon, May 12, 2014 at 9:07 AM, Simon Horman <horms@verge.net.au> wrote:
> On Mon, May 12, 2014 at 08:24:03AM +0900, Magnus Damm wrote:
>> On Sun, May 11, 2014 at 9:46 AM, Simon Horman <horms@verge.net.au> wrote:
>> > On Thu, May 08, 2014 at 12:12:29PM +0200, Geert Uytterhoeven wrote:
>> >> On Tue, May 6, 2014 at 11:26 PM, Geert Uytterhoeven
>> >> <geert+renesas@glider.be> wrote:
>> >> > Tested on Koelsch (legacy, reference, shmobile, and shmobile+bbb kernels)
>> >> > and BeagleBone Black (shmobile+bbb). Will test on more hardware tomorrow.
>> >>
>> >> Tested on genmai with Wolfram's CCF support.
>> >
>> > Thanks, shall I go ahead and queue this up?
>>
>> Yes please, at least from my side everything looks perfect.
>
> Thanks, will do.
>
> I currently plan to send this on to Linus when the merge window
> opens for v3.16.

Actually we had hoped this could land in v3.15, so we can fix the regression
introduced in v3.14 by bf98c1eac1d4a6bcf00532e4fa41d8126cd6c187 as
soon as possible.

> This differs from other patches I have queued up (until now) which
> I have or intend to send via the ARM SoC tree.

Yep ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[PATCH v4] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI

[Simon Horman]

On Mon, May 12, 2014 at 09:25:21AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Mon, May 12, 2014 at 9:07 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Mon, May 12, 2014 at 08:24:03AM +0900, Magnus Damm wrote:
> >> On Sun, May 11, 2014 at 9:46 AM, Simon Horman <horms@verge.net.au> wrote:
> >> > On Thu, May 08, 2014 at 12:12:29PM +0200, Geert Uytterhoeven wrote:
> >> >> On Tue, May 6, 2014 at 11:26 PM, Geert Uytterhoeven
> >> >> <geert+renesas@glider.be> wrote:
> >> >> > Tested on Koelsch (legacy, reference, shmobile, and shmobile+bbb kernels)
> >> >> > and BeagleBone Black (shmobile+bbb). Will test on more hardware tomorrow.
> >> >>
> >> >> Tested on genmai with Wolfram's CCF support.
> >> >
> >> > Thanks, shall I go ahead and queue this up?
> >>
> >> Yes please, at least from my side everything looks perfect.
> >
> > Thanks, will do.
> >
> > I currently plan to send this on to Linus when the merge window
> > opens for v3.16.
> 
> Actually we had hoped this could land in v3.15, so we can fix the regression
> introduced in v3.14 by bf98c1eac1d4a6bcf00532e4fa41d8126cd6c187 as
> soon as possible.

Ok, so I should/can treat this as a fix?

> > This differs from other patches I have queued up (until now) which
> > I have or intend to send via the ARM SoC tree.
> 
> Yep ;-)
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH v4] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI

[Geert Uytterhoeven]

Hi Simon,

On Tue, May 13, 2014 at 2:04 AM, Simon Horman <horms@verge.net.au> wrote:
> On Mon, May 12, 2014 at 09:25:21AM +0200, Geert Uytterhoeven wrote:
>> On Mon, May 12, 2014 at 9:07 AM, Simon Horman <horms@verge.net.au> wrote:
>> > On Mon, May 12, 2014 at 08:24:03AM +0900, Magnus Damm wrote:
>> >> On Sun, May 11, 2014 at 9:46 AM, Simon Horman <horms@verge.net.au> wrote:
>> >> > On Thu, May 08, 2014 at 12:12:29PM +0200, Geert Uytterhoeven wrote:
>> >> >> On Tue, May 6, 2014 at 11:26 PM, Geert Uytterhoeven
>> >> >> <geert+renesas@glider.be> wrote:
>> >> >> > Tested on Koelsch (legacy, reference, shmobile, and shmobile+bbb kernels)
>> >> >> > and BeagleBone Black (shmobile+bbb). Will test on more hardware tomorrow.
>> >> >>
>> >> >> Tested on genmai with Wolfram's CCF support.
>> >> >
>> >> > Thanks, shall I go ahead and queue this up?
>> >>
>> >> Yes please, at least from my side everything looks perfect.
>> >
>> > Thanks, will do.
>> >
>> > I currently plan to send this on to Linus when the merge window
>> > opens for v3.16.
>>
>> Actually we had hoped this could land in v3.15, so we can fix the regression
>> introduced in v3.14 by bf98c1eac1d4a6bcf00532e4fa41d8126cd6c187 as
>> soon as possible.
>
> Ok, so I should/can treat this as a fix?

Yes, definitely.

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[PATCH v4] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI

[Simon Horman]

On Tue, May 13, 2014 at 08:43:49AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Tue, May 13, 2014 at 2:04 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Mon, May 12, 2014 at 09:25:21AM +0200, Geert Uytterhoeven wrote:
> >> On Mon, May 12, 2014 at 9:07 AM, Simon Horman <horms@verge.net.au> wrote:
> >> > On Mon, May 12, 2014 at 08:24:03AM +0900, Magnus Damm wrote:
> >> >> On Sun, May 11, 2014 at 9:46 AM, Simon Horman <horms@verge.net.au> wrote:
> >> >> > On Thu, May 08, 2014 at 12:12:29PM +0200, Geert Uytterhoeven wrote:
> >> >> >> On Tue, May 6, 2014 at 11:26 PM, Geert Uytterhoeven
> >> >> >> <geert+renesas@glider.be> wrote:
> >> >> >> > Tested on Koelsch (legacy, reference, shmobile, and shmobile+bbb kernels)
> >> >> >> > and BeagleBone Black (shmobile+bbb). Will test on more hardware tomorrow.
> >> >> >>
> >> >> >> Tested on genmai with Wolfram's CCF support.
> >> >> >
> >> >> > Thanks, shall I go ahead and queue this up?
> >> >>
> >> >> Yes please, at least from my side everything looks perfect.
> >> >
> >> > Thanks, will do.
> >> >
> >> > I currently plan to send this on to Linus when the merge window
> >> > opens for v3.16.
> >>
> >> Actually we had hoped this could land in v3.15, so we can fix the regression
> >> introduced in v3.14 by bf98c1eac1d4a6bcf00532e4fa41d8126cd6c187 as
> >> soon as possible.
> >
> > Ok, so I should/can treat this as a fix?
> 
> Yes, definitely.

Thanks, will do.