* Re: [PATCH] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI
2014-05-01 1:09 [PATCH] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI Geert Uytterhoeven
@ 2014-05-01 4:27 ` Simon Horman
2014-05-01 4:42 ` Geert Uytterhoeven
` (5 subsequent siblings)
6 siblings, 0 replies; 9+ messages in thread
From: Simon Horman @ 2014-05-01 4:27 UTC (permalink / raw)
To: linux-sh
On Thu, May 01, 2014 at 03:09:42AM +0200, Geert Uytterhoeven wrote:
> 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.
>
> This is an RFC for several reasons:
> 1. I'm at ELC, and away from my hardware to test it properly (also on
> non-shmobile).
> 2. Can we already reduce the list of SoCs to check for?
> E.g. is this needed for emev2, which doesn't have MSTP clocks?
I will answer a related question: "Simon, can you test this?".
If its just a matter of testing that the board still boots to user-space
I can do so without too much effort for most shmobile boards including
the emev2 based kzm9g. The exceptions are:
* The r7s72100 based genmai
- I think you have access to that
* The r8a7791 based henniger board.
- I do have access to a koelsh board which is bsed on the same SoC
If the testing is a bit more involved then I don't have an automation
set up for it at this stage. That makes testing a bit more difficult
for me. Especially as I am going on holidays tomorrow.
Of course there is the caveat that a number of SoCs and their boards do
not support multiplatform yet.
> 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 | 23 +++++++++++++++++++++--
> 3 files changed, 30 insertions(+), 9 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..cb4cb9f26896 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 int __init sh_pm_runtime_init(void)
> +static bool default_pm_on;
> +
> +int __init sh_pm_runtime_init(void)
> {
> +#ifdef 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;
> +#endif
> +
> + default_pm_on = true;
> pm_clk_add_notifier(&platform_bus_type, &platform_bus_notifier);
> return 0;
> }
> @@ -59,7 +76,9 @@ 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
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI
2014-05-01 1:09 [PATCH] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI Geert Uytterhoeven
2014-05-01 4:27 ` Simon Horman
@ 2014-05-01 4:42 ` Geert Uytterhoeven
2014-05-01 4:58 ` Simon Horman
` (4 subsequent siblings)
6 siblings, 0 replies; 9+ messages in thread
From: Geert Uytterhoeven @ 2014-05-01 4:42 UTC (permalink / raw)
To: linux-sh
Hi Simon,
On Thu, May 1, 2014 at 6:27 AM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, May 01, 2014 at 03:09:42AM +0200, Geert Uytterhoeven wrote:
>> 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.
>>
>> This is an RFC for several reasons:
>> 1. I'm at ELC, and away from my hardware to test it properly (also on
>> non-shmobile).
>> 2. Can we already reduce the list of SoCs to check for?
>> E.g. is this needed for emev2, which doesn't have MSTP clocks?
According to Magnus, emev2 doesn't rely on Runtime PM, so it can be
removed from the list.
> I will answer a related question: "Simon, can you test this?".
;-)
> If its just a matter of testing that the board still boots to user-space
Preferably after removing the clk_enables[] workarounds, and with MSTP
disable patches ;-)
> I can do so without too much effort for most shmobile boards including
> the emev2 based kzm9g. The exceptions are:
>
> * The r7s72100 based genmai
> - I think you have access to that
> * The r8a7791 based henniger board.
> - I do have access to a koelsh board which is bsed on the same SoC
Well, we shouldn't rush to get it in. 3.15 is still a few weeks away...
I can test it on Koelsch, Genmai, BeagleBone Black, and Armadillo after
ELC.
> If the testing is a bit more involved then I don't have an automation
> set up for it at this stage. That makes testing a bit more difficult
> for me. Especially as I am going on holidays tomorrow.
Sure, I understand. Enjoy your holidays! After which rc will you return?
> Of course there is the caveat that a number of SoCs and their boards do
> not support multiplatform yet.
Yep. But as long as there are no typos in the compatible checks, testing
well on one shmobile board and one non-shmobile board should suffice,
right?
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI
2014-05-01 1:09 [PATCH] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI Geert Uytterhoeven
2014-05-01 4:27 ` Simon Horman
2014-05-01 4:42 ` Geert Uytterhoeven
@ 2014-05-01 4:58 ` Simon Horman
2014-05-03 19:29 ` Magnus Damm
` (3 subsequent siblings)
6 siblings, 0 replies; 9+ messages in thread
From: Simon Horman @ 2014-05-01 4:58 UTC (permalink / raw)
To: linux-sh
On Thu, May 01, 2014 at 06:42:18AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Thu, May 1, 2014 at 6:27 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Thu, May 01, 2014 at 03:09:42AM +0200, Geert Uytterhoeven wrote:
> >> 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.
> >>
> >> This is an RFC for several reasons:
> >> 1. I'm at ELC, and away from my hardware to test it properly (also on
> >> non-shmobile).
> >> 2. Can we already reduce the list of SoCs to check for?
> >> E.g. is this needed for emev2, which doesn't have MSTP clocks?
>
> According to Magnus, emev2 doesn't rely on Runtime PM, so it can be
> removed from the list.
>
> > I will answer a related question: "Simon, can you test this?".
>
> ;-)
>
> > If its just a matter of testing that the board still boots to user-space
>
> Preferably after removing the clk_enables[] workarounds, and with MSTP
> disable patches ;-)
Ok, assuming such patches exist :)
> > I can do so without too much effort for most shmobile boards including
> > the emev2 based kzm9g. The exceptions are:
> >
> > * The r7s72100 based genmai
> > - I think you have access to that
> > * The r8a7791 based henniger board.
> > - I do have access to a koelsh board which is bsed on the same SoC
>
> Well, we shouldn't rush to get it in. 3.15 is still a few weeks away...
Agreed.
> I can test it on Koelsch, Genmai, BeagleBone Black, and Armadillo after
> ELC.
>
> > If the testing is a bit more involved then I don't have an automation
> > set up for it at this stage. That makes testing a bit more difficult
> > for me. Especially as I am going on holidays tomorrow.
>
> Sure, I understand. Enjoy your holidays! After which rc will you return?
I expect to be back around rc5.
Or in more concrete terms, on the 13th.
> > Of course there is the caveat that a number of SoCs and their boards do
> > not support multiplatform yet.
>
> Yep. But as long as there are no typos in the compatible checks, testing
> well on one shmobile board and one non-shmobile board should suffice,
> right?
Most likely.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI
2014-05-01 1:09 [PATCH] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI Geert Uytterhoeven
` (2 preceding siblings ...)
2014-05-01 4:58 ` Simon Horman
@ 2014-05-03 19:29 ` Magnus Damm
2014-05-06 10:45 ` Ben Dooks
` (2 subsequent siblings)
6 siblings, 0 replies; 9+ messages in thread
From: Magnus Damm @ 2014-05-03 19:29 UTC (permalink / raw)
To: linux-sh
Hi Geert,
On Thu, May 1, 2014 at 4:42 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Simon,
>
> On Thu, May 1, 2014 at 6:27 AM, Simon Horman <horms@verge.net.au> wrote:
>> On Thu, May 01, 2014 at 03:09:42AM +0200, Geert Uytterhoeven wrote:
>>> 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.
>>>
>>> This is an RFC for several reasons:
>>> 1. I'm at ELC, and away from my hardware to test it properly (also on
>>> non-shmobile).
>>> 2. Can we already reduce the list of SoCs to check for?
>>> E.g. is this needed for emev2, which doesn't have MSTP clocks?
Thanks a lot for your efforts! I think this patch makes sense as next
step for Runtime PM since it will allow us to use DT-only for board
support together with Runtime PM.
> According to Magnus, emev2 doesn't rely on Runtime PM, so it can be
> removed from the list.
Correct, but let me clarify a bit. At this point we are not using
Runtime PM in any driver used by EMEV2. At some point it would however
be good to use Runtime PM, so I don't think it would hurt enabling it.
Actually, I think we should enable it for all our SoCs, so matching on
"renesas," may make even more sense.
Cheers,
/ magnus
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI
2014-05-01 1:09 [PATCH] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI Geert Uytterhoeven
` (3 preceding siblings ...)
2014-05-03 19:29 ` Magnus Damm
@ 2014-05-06 10:45 ` Ben Dooks
2014-05-06 21:15 ` Geert Uytterhoeven
2014-05-06 21:17 ` Geert Uytterhoeven
6 siblings, 0 replies; 9+ messages in thread
From: Ben Dooks @ 2014-05-06 10:45 UTC (permalink / raw)
To: linux-sh
On 01/05/14 02:09, Geert Uytterhoeven wrote:
> 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.
>
> This is an RFC for several reasons:
> 1. I'm at ELC, and away from my hardware to test it properly (also on
> non-shmobile).
> 2. Can we already reduce the list of SoCs to check for?
> E.g. is this needed for emev2, which doesn't have MSTP clocks?
From what I remember the EMEV2 does have hardware clock gates for
IP, just not the same way as the newer SoCs have. I have not tried
any newer kernels with this as the project I was on which used this
device is no-longer going.
> 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?),
Yes, that would fine. It looks like there is enough changes to
drop that. Thanks for sorting this out.
> -static int __init sh_pm_runtime_init(void)
> +static bool default_pm_on;
> +
> +int __init sh_pm_runtime_init(void)
> {
> +#ifdef 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;
> +#endif
Is there a more generic compatible that could be matched on?
Could we do an if (IS_ENABLED(CONFIG_ARCH_SHMOBILE_MULTI)) instead
of an #ifdef block?
> +
> + default_pm_on = true;
> pm_clk_add_notifier(&platform_bus_type, &platform_bus_notifier);
> return 0;
> }
> @@ -59,7 +76,9 @@ 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);
>
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI
2014-05-01 1:09 [PATCH] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI Geert Uytterhoeven
` (4 preceding siblings ...)
2014-05-06 10:45 ` Ben Dooks
@ 2014-05-06 21:15 ` Geert Uytterhoeven
2014-05-06 21:17 ` Geert Uytterhoeven
6 siblings, 0 replies; 9+ messages in thread
From: Geert Uytterhoeven @ 2014-05-06 21:15 UTC (permalink / raw)
To: linux-sh
Hi Magnus,
On Sat, May 3, 2014 at 9:29 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
>> According to Magnus, emev2 doesn't rely on Runtime PM, so it can be
>> removed from the list.
>
> Correct, but let me clarify a bit. At this point we are not using
> Runtime PM in any driver used by EMEV2. At some point it would however
> be good to use Runtime PM, so I don't think it would hurt enabling it.
OK, so let's keep it.
> Actually, I think we should enable it for all our SoCs, so matching on
> "renesas," may make even more sense.
Is there an easy way to match on "renesas,"? I haven't found one yet.
Anyway, I'm a bit reluctant to do that. The final fix may be SoC-dependent,
so having all SoCs listed explicitly allows to selectively remove lines when
needed.
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI
2014-05-01 1:09 [PATCH] drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI Geert Uytterhoeven
` (5 preceding siblings ...)
2014-05-06 21:15 ` Geert Uytterhoeven
@ 2014-05-06 21:17 ` Geert Uytterhoeven
6 siblings, 0 replies; 9+ messages in thread
From: Geert Uytterhoeven @ 2014-05-06 21:17 UTC (permalink / raw)
To: linux-sh
Hi Ben,
On Tue, May 6, 2014 at 12:45 PM, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>> 2. Can we already reduce the list of SoCs to check for?
>> E.g. is this needed for emev2, which doesn't have MSTP clocks?
>
> From what I remember the EMEV2 does have hardware clock gates for
> IP, just not the same way as the newer SoCs have. I have not tried
> any newer kernels with this as the project I was on which used this
> device is no-longer going.
OK, will keep.
>> 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?),
>
> Yes, that would fine. It looks like there is enough changes to
> drop that. Thanks for sorting this out.
Thanks!
>> -static int __init sh_pm_runtime_init(void)
>> +static bool default_pm_on;
>> +
>> +int __init sh_pm_runtime_init(void)
>> {
>> +#ifdef 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;
>> +#endif
>
> Is there a more generic compatible that could be matched on?
As I already replied to Magnus, I don't think so.
> Could we do an if (IS_ENABLED(CONFIG_ARCH_SHMOBILE_MULTI)) instead
> of an #ifdef block?
Good idea, that will increase compile coverage, while, the compiler will
still remove it when appropriate.
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
^ permalink raw reply [flat|nested] 9+ messages in thread