PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled

Message ID 1415917702-6742-2-git-send-email-khilman@kernel.org
State New
Headers show

Commit Message

Kevin Hilman Nov. 13, 2014, 10:28 p.m.
From: Kevin Hilman <khilman@linaro.org>

It makes little sense to use generic power domains without runtime PM.
Also, since the complexities of handling the !PM_RUNTIME case are
causing more trouble and confusion than they're worth, let's simplify
the world by making genpd always enable runtime PM.

Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
---
 kernel/power/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Ulf Hansson Nov. 14, 2014, 7:26 a.m. | #1
On 13 November 2014 23:28, Kevin Hilman <khilman@kernel.org> wrote:
> From: Kevin Hilman <khilman@linaro.org>
>
> It makes little sense to use generic power domains without runtime PM.
> Also, since the complexities of handling the !PM_RUNTIME case are
> causing more trouble and confusion than they're worth, let's simplify
> the world by making genpd always enable runtime PM.

I do agree that your above statement seems reasonable, even if can't
really tell if that would break some SOCs use-cases.

My concern is though, that I fear we will be taking short-cuts in
genpd that might bite us later on, but I might be wrong.

The reason for my concern is that on every other place, like in the
subsystem level, driver core, PM core and of course in drivers -  we
need to cope with all the combinations of CONFIG_PM_SLEEP and
CONFIG_PM_SLEEP.  So theoretically, why shouldn't genpd be able to do
that as well?

>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Grygorii Strashko <grygorii.strashko@ti.com>
> Signed-off-by: Kevin Hilman <khilman@linaro.org>
> ---
>  kernel/power/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 3d39cc0228e9..2a8c64d0a43c 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -271,7 +271,7 @@ config PM_CLK
>
>  config PM_GENERIC_DOMAINS
>         bool
> -       depends on PM
> +       select PM_RUNTIME

Shouldn't we actually depend on PM_RUNTIME instead?

>
>  config WQ_POWER_EFFICIENT_DEFAULT
>         bool "Enable workqueue power-efficient mode by default"
> --
> 2.1.3
>

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ulf Hansson Nov. 14, 2014, 7:28 a.m. | #2
On 14 November 2014 08:26, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 13 November 2014 23:28, Kevin Hilman <khilman@kernel.org> wrote:
>> From: Kevin Hilman <khilman@linaro.org>
>>
>> It makes little sense to use generic power domains without runtime PM.
>> Also, since the complexities of handling the !PM_RUNTIME case are
>> causing more trouble and confusion than they're worth, let's simplify
>> the world by making genpd always enable runtime PM.
>
> I do agree that your above statement seems reasonable, even if can't
> really tell if that would break some SOCs use-cases.
>
> My concern is though, that I fear we will be taking short-cuts in
> genpd that might bite us later on, but I might be wrong.
>
> The reason for my concern is that on every other place, like in the
> subsystem level, driver core, PM core and of course in drivers -  we
> need to cope with all the combinations of CONFIG_PM_SLEEP and
> CONFIG_PM_SLEEP.  So theoretically, why shouldn't genpd be able to do

/s /CONFIG_PM_SLEEP /CONFIG_PM_RUNTIME

> that as well?
>
>>
>> Cc: Ulf Hansson <ulf.hansson@linaro.org>
>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>> Cc: Grygorii Strashko <grygorii.strashko@ti.com>
>> Signed-off-by: Kevin Hilman <khilman@linaro.org>
>> ---
>>  kernel/power/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
>> index 3d39cc0228e9..2a8c64d0a43c 100644
>> --- a/kernel/power/Kconfig
>> +++ b/kernel/power/Kconfig
>> @@ -271,7 +271,7 @@ config PM_CLK
>>
>>  config PM_GENERIC_DOMAINS
>>         bool
>> -       depends on PM
>> +       select PM_RUNTIME
>
> Shouldn't we actually depend on PM_RUNTIME instead?
>
>>
>>  config WQ_POWER_EFFICIENT_DEFAULT
>>         bool "Enable workqueue power-efficient mode by default"
>> --
>> 2.1.3
>>
>
> Kind regards
> Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Geert Uytterhoeven Nov. 14, 2014, 7:29 a.m. | #3
Hi Kevin,

On Thu, Nov 13, 2014 at 11:28 PM, Kevin Hilman <khilman@kernel.org> wrote:
> It makes little sense to use generic power domains without runtime PM.

Does it?
It still powers down the PM domains on system suspend (at least on my
boards ;-)

> Also, since the complexities of handling the !PM_RUNTIME case are
> causing more trouble and confusion than they're worth, let's simplify
> the world by making genpd always enable runtime PM.

What do other people think?

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-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kevin Hilman Nov. 14, 2014, 5:27 p.m. | #4
Hi Ulf,

Ulf Hansson <ulf.hansson@linaro.org> writes:

> On 13 November 2014 23:28, Kevin Hilman <khilman@kernel.org> wrote:
>> From: Kevin Hilman <khilman@linaro.org>
>>
>> It makes little sense to use generic power domains without runtime PM.
>> Also, since the complexities of handling the !PM_RUNTIME case are
>> causing more trouble and confusion than they're worth, let's simplify
>> the world by making genpd always enable runtime PM.
>
> I do agree that your above statement seems reasonable, even if can't
> really tell if that would break some SOCs use-cases.

Break in what way?

> My concern is though, that I fear we will be taking short-cuts in
> genpd that might bite us later on, but I might be wrong.
>
> The reason for my concern is that on every other place, like in the
> subsystem level, driver core, PM core and of course in drivers -  we
> need to cope with all the combinations of CONFIG_PM_SLEEP and
> CONFIG_PM_SLEEP.  So theoretically, why shouldn't genpd be able to do
> that as well?

Good question, and one we need to figure out.  (I meant to mark this
patch as RFC for that reason.)

I think the primary question is: why would one want to use genpd without
runtime PM?

I understand why one might want to use/test drivers with various
combinations of PM_SLEEP and PM_RUNTIME, but I'm not seeing why we
should need to support genpd without PM_RUNTIME enabled.

In fact, on all the SoCs I've worked closely with, power domains,
suspend/resume and runtime PM are all so closely intertwined that I
can't imagine a useful scenario where they they are not all used
together.  If you care about PM, you turn them all on.  If you don't,
you turn them all off and ensure everything is enabled at boot.

IMO, we're spending a lot of cycles supporting these various
combinations and permutations and as a result are not really able to
solve the real problems people are raising.

Seems like most of the time a new feature/fixup/cleanup is proposed, the
discussion always ends up around how to support things when this or that
option is disabled, or some combination of kconfig options that weren't
considered.

I think we should simplify the config space permuations so we can focus
on improving the frameworks.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kevin Hilman Nov. 14, 2014, 5:36 p.m. | #5
Geert Uytterhoeven <geert@linux-m68k.org> writes:

> Hi Kevin,
>
> On Thu, Nov 13, 2014 at 11:28 PM, Kevin Hilman <khilman@kernel.org> wrote:
>> It makes little sense to use generic power domains without runtime PM.
>
> Does it?
> It still powers down the PM domains on system suspend (at least on my
> boards ;-)

Sure, but your devices are also using runtime PM, so I'm not sure how
does that change my statement above?

>> Also, since the complexities of handling the !PM_RUNTIME case are
>> causing more trouble and confusion than they're worth, let's simplify
>> the world by making genpd always enable runtime PM.
>
> What do other people think?

Yes, I'm curious also.  This patch was supposed to be marked RFC.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Rafael J. Wysocki Nov. 14, 2014, 10:35 p.m. | #6
On Friday, November 14, 2014 09:27:41 AM Kevin Hilman wrote:
> Hi Ulf,
> 
> Ulf Hansson <ulf.hansson@linaro.org> writes:
> 
> > On 13 November 2014 23:28, Kevin Hilman <khilman@kernel.org> wrote:
> >> From: Kevin Hilman <khilman@linaro.org>
> >>
> >> It makes little sense to use generic power domains without runtime PM.
> >> Also, since the complexities of handling the !PM_RUNTIME case are
> >> causing more trouble and confusion than they're worth, let's simplify
> >> the world by making genpd always enable runtime PM.
> >
> > I do agree that your above statement seems reasonable, even if can't
> > really tell if that would break some SOCs use-cases.
> 
> Break in what way?
> 
> > My concern is though, that I fear we will be taking short-cuts in
> > genpd that might bite us later on, but I might be wrong.
> >
> > The reason for my concern is that on every other place, like in the
> > subsystem level, driver core, PM core and of course in drivers -  we
> > need to cope with all the combinations of CONFIG_PM_SLEEP and
> > CONFIG_PM_SLEEP.  So theoretically, why shouldn't genpd be able to do
> > that as well?
> 
> Good question, and one we need to figure out.  (I meant to mark this
> patch as RFC for that reason.)
> 
> I think the primary question is: why would one want to use genpd without
> runtime PM?
> 
> I understand why one might want to use/test drivers with various
> combinations of PM_SLEEP and PM_RUNTIME, but I'm not seeing why we
> should need to support genpd without PM_RUNTIME enabled.
> 
> In fact, on all the SoCs I've worked closely with, power domains,
> suspend/resume and runtime PM are all so closely intertwined that I
> can't imagine a useful scenario where they they are not all used
> together.  If you care about PM, you turn them all on.  If you don't,
> you turn them all off and ensure everything is enabled at boot.
> 
> IMO, we're spending a lot of cycles supporting these various
> combinations and permutations and as a result are not really able to
> solve the real problems people are raising.
> 
> Seems like most of the time a new feature/fixup/cleanup is proposed, the
> discussion always ends up around how to support things when this or that
> option is disabled, or some combination of kconfig options that weren't
> considered.
> 
> I think we should simplify the config space permuations so we can focus
> on improving the frameworks.

Moreover, recently we've spend quite some time on discussing pretty much
how to do runtime PM for CONFIG_PM_RUNTIME unset and really the conclusion
to me is "Don't do that".

There evidently are systems that require runtime PM (in some form) for basic
functionality and it looks like all systems using genpd will fall into that
category, more or less.  Now, the runtime PM framework is what we have for
handling this kind of stuff and I don't see a reason to pretend that it may
be unnecessary.

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rafael J. Wysocki Nov. 14, 2014, 10:41 p.m. | #7
On Friday, November 14, 2014 09:36:17 AM Kevin Hilman wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
> 
> > Hi Kevin,
> >
> > On Thu, Nov 13, 2014 at 11:28 PM, Kevin Hilman <khilman@kernel.org> wrote:
> >> It makes little sense to use generic power domains without runtime PM.
> >
> > Does it?
> > It still powers down the PM domains on system suspend (at least on my
> > boards ;-)
> 
> Sure, but your devices are also using runtime PM, so I'm not sure how
> does that change my statement above?

Questions here are (1) how many users will actually want to disable PM_RUNTIME
for systems using genpd (my sort of educated guess is "none") and (2) whether
or not we need to power up stuff dynamically during initialization on systems
using genpd (and several recent discussions indicate that the answer here is
"yes, we need to do that").

> >> Also, since the complexities of handling the !PM_RUNTIME case are
> >> causing more trouble and confusion than they're worth, let's simplify
> >> the world by making genpd always enable runtime PM.
> >
> > What do other people think?
> 
> Yes, I'm curious also.  This patch was supposed to be marked RFC.

I'm totally for making this change and I'm going to queue up this patch for
3.19, so if anyone sees a really good reason for not doing this, please let
me know what that reason is as soon as you can.

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Geert Uytterhoeven Nov. 15, 2014, 12:32 p.m. | #8
Hi Kevin,

On Fri, Nov 14, 2014 at 6:36 PM, Kevin Hilman <khilman@kernel.org> wrote:
>> On Thu, Nov 13, 2014 at 11:28 PM, Kevin Hilman <khilman@kernel.org> wrote:
>>> It makes little sense to use generic power domains without runtime PM.
>>
>> Does it?
>> It still powers down the PM domains on system suspend (at least on my
>> boards ;-)
>
> Sure, but your devices are also using runtime PM, so I'm not sure how
> does that change my statement above?

I do mean with CONFIG_PM_RUNTIME turned off.

If PM domain support is disabled, s2ram will not power down the PM domains.

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-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pavel Machek Nov. 15, 2014, 8:54 p.m. | #9
On Fri 2014-11-14 23:41:15, Rafael J. Wysocki wrote:
> On Friday, November 14, 2014 09:36:17 AM Kevin Hilman wrote:
> > Geert Uytterhoeven <geert@linux-m68k.org> writes:
> > 
> > > Hi Kevin,
> > >
> > > On Thu, Nov 13, 2014 at 11:28 PM, Kevin Hilman <khilman@kernel.org> wrote:
> > >> It makes little sense to use generic power domains without runtime PM.
> > >
> > > Does it?
> > > It still powers down the PM domains on system suspend (at least on my
> > > boards ;-)
> > 
> > Sure, but your devices are also using runtime PM, so I'm not sure how
> > does that change my statement above?
> 
> Questions here are (1) how many users will actually want to disable PM_RUNTIME
> for systems using genpd (my sort of educated guess is "none") and

Well. Developers sometimes want to disable power management so that
they don't have to debug it just now... disabling PM_RUNTIME is a way
to do that.

OTOH making code more complex to make new board bring-up easier may
not be good idea..
									Pavel
Rafael J. Wysocki Nov. 17, 2014, 1:22 a.m. | #10
On Saturday, November 15, 2014 01:32:01 PM Geert Uytterhoeven wrote:
> Hi Kevin,
> 
> On Fri, Nov 14, 2014 at 6:36 PM, Kevin Hilman <khilman@kernel.org> wrote:
> >> On Thu, Nov 13, 2014 at 11:28 PM, Kevin Hilman <khilman@kernel.org> wrote:
> >>> It makes little sense to use generic power domains without runtime PM.
> >>
> >> Does it?
> >> It still powers down the PM domains on system suspend (at least on my
> >> boards ;-)
> >
> > Sure, but your devices are also using runtime PM, so I'm not sure how
> > does that change my statement above?
> 
> I do mean with CONFIG_PM_RUNTIME turned off.
> 
> If PM domain support is disabled, s2ram will not power down the PM domains.

But if PM_RUNTIME is enabled along with it, I don't think it will make much
of a different, will it?

Building the kernel with genpd and without PM_RUNTIME is possible today,
but is it really useful?  To me, it only seems to make people try to
reinvent the wheel "because PM_RUNTIME may be unset".

I have to say I'm seriously considering to make PM_SLEEP select
PM_RUNTIME too as that would make quite a few things a *lot* simpler.
Geert Uytterhoeven Nov. 17, 2014, 8:01 a.m. | #11
On Mon, Nov 17, 2014 at 2:22 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Saturday, November 15, 2014 01:32:01 PM Geert Uytterhoeven wrote:
>> On Fri, Nov 14, 2014 at 6:36 PM, Kevin Hilman <khilman@kernel.org> wrote:
>> >> On Thu, Nov 13, 2014 at 11:28 PM, Kevin Hilman <khilman@kernel.org> wrote:
>> >>> It makes little sense to use generic power domains without runtime PM.
>> >>
>> >> Does it?
>> >> It still powers down the PM domains on system suspend (at least on my
>> >> boards ;-)
>> >
>> > Sure, but your devices are also using runtime PM, so I'm not sure how
>> > does that change my statement above?
>>
>> I do mean with CONFIG_PM_RUNTIME turned off.
>>
>> If PM domain support is disabled, s2ram will not power down the PM domains.
>
> But if PM_RUNTIME is enabled along with it, I don't think it will make much
> of a different, will it?

That's true.

> Building the kernel with genpd and without PM_RUNTIME is possible today,
> but is it really useful?  To me, it only seems to make people try to
> reinvent the wheel "because PM_RUNTIME may be unset".
>
> I have to say I'm seriously considering to make PM_SLEEP select
> PM_RUNTIME too as that would make quite a few things a *lot* simpler.

I agree that it would simplify things, a reduce testing efforts.

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-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kevin Hilman Nov. 17, 2014, 6:25 p.m. | #12
"Rafael J. Wysocki" <rjw@rjwysocki.net> writes:

> On Saturday, November 15, 2014 01:32:01 PM Geert Uytterhoeven wrote:
>> Hi Kevin,
>> 
>> On Fri, Nov 14, 2014 at 6:36 PM, Kevin Hilman <khilman@kernel.org> wrote:
>> >> On Thu, Nov 13, 2014 at 11:28 PM, Kevin Hilman <khilman@kernel.org> wrote:
>> >>> It makes little sense to use generic power domains without runtime PM.
>> >>
>> >> Does it?
>> >> It still powers down the PM domains on system suspend (at least on my
>> >> boards ;-)
>> >
>> > Sure, but your devices are also using runtime PM, so I'm not sure how
>> > does that change my statement above?
>> 
>> I do mean with CONFIG_PM_RUNTIME turned off.
>> 
>> If PM domain support is disabled, s2ram will not power down the PM domains.
>
> But if PM_RUNTIME is enabled along with it, I don't think it will make much
> of a different, will it?
>
> Building the kernel with genpd and without PM_RUNTIME is possible today,
> but is it really useful?  To me, it only seems to make people try to
> reinvent the wheel "because PM_RUNTIME may be unset".
>
> I have to say I'm seriously considering to make PM_SLEEP select
> PM_RUNTIME too as that would make quite a few things a *lot* simpler.

Yes.  

If that were the case, we woudn't need the pm_runtime_force_* calls
either.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kevin Hilman Nov. 18, 2014, 3:52 a.m. | #13
"Rafael J. Wysocki" <rjw@rjwysocki.net> writes:

> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> The number of and dependencies between high-level power management
> Kconfig options make life much harder than necessary.  Several
> conbinations of them have to be tested and supported, even though
> some of those combinations are very rarely used in practice (it
> they are used in practice at all).  Moreover, the fact that we
> have separate independent Kconfig options for runtime PM and
> system suspend is a serious obscacle for integration between
> the two frameworks.
>
> To overcome these difficulties, always select PM_RUNTIME if PM_SLEEP
> is set.  Among other things, this will allow system suspend callbacks
> provided by bus types and device drivers to rely on the runtime PM
> framework regardless of the kernel configuration.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>
> As a follow up.
>
> Note that we won't need the patch making genpd select PM_RUNTIME with this,
> because genpd already depends on PM.
>
> Thoughts, comments?

Acked-by: Kevin Hilman <khilman@linaro.org>

...with dancing and singing in the streets (or more my speed: a
celebratory beer.) 

Kevin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Geert Uytterhoeven Nov. 18, 2014, 8:32 a.m. | #14
On Tue, Nov 18, 2014 at 4:52 AM, Kevin Hilman <khilman@kernel.org> wrote:
> "Rafael J. Wysocki" <rjw@rjwysocki.net> writes:
>
>> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>
>> The number of and dependencies between high-level power management
>> Kconfig options make life much harder than necessary.  Several
>> conbinations of them have to be tested and supported, even though
>> some of those combinations are very rarely used in practice (it
>> they are used in practice at all).  Moreover, the fact that we
>> have separate independent Kconfig options for runtime PM and
>> system suspend is a serious obscacle for integration between
>> the two frameworks.
>>
>> To overcome these difficulties, always select PM_RUNTIME if PM_SLEEP
>> is set.  Among other things, this will allow system suspend callbacks
>> provided by bus types and device drivers to rely on the runtime PM
>> framework regardless of the kernel configuration.
>>
>> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> ---
>>
>> As a follow up.
>>
>> Note that we won't need the patch making genpd select PM_RUNTIME with this,
>> because genpd already depends on PM.
>>
>> Thoughts, comments?
>
> Acked-by: Kevin Hilman <khilman@linaro.org>

This gets rid of

kernel/power/Kconfig:132:error: recursive dependency detected!
kernel/power/Kconfig:132: symbol PM_RUNTIME is selected by PM_GENERIC_DOMAINS
kernel/power/Kconfig:272: symbol PM_GENERIC_DOMAINS is selected by PM_RUNTIME

Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Pavel Machek Nov. 18, 2014, 8:34 a.m. | #15
On Tue 2014-11-18 01:39:06, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> The number of and dependencies between high-level power management
> Kconfig options make life much harder than necessary.  Several
> conbinations of them have to be tested and supported, even though
> some of those combinations are very rarely used in practice (it
> they are used in practice at all).  Moreover, the fact that we
> have separate independent Kconfig options for runtime PM and
> system suspend is a serious obscacle for integration between
> the two frameworks.
> 
> To overcome these difficulties, always select PM_RUNTIME if PM_SLEEP
> is set.  Among other things, this will allow system suspend callbacks
> provided by bus types and device drivers to rely on the runtime PM
> framework regardless of the kernel configuration.

3.18-rc5 still has:

config PM_RUNTIME
        bool "Run-time PM core functionality"
        depends on !IA64_HP_SIM
        ---help---

So I assume this patch is against tree where PM_RUNTIME does not
depend on anything?

> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> 
> As a follow up.
> 
> Note that we won't need the patch making genpd select PM_RUNTIME with this,
> because genpd already depends on PM.

Looking through the config file, there are more config options that
should be stripped.

config SUSPEND_FREEZER
        bool "Enable freezer for suspend to RAM/standby" \
"Turning OFF this setting is NOT recommended! If in doubt, say Y."

config HIBERNATE_CALLBACKS
       bool

...can we just use CONFIG_HIBERNATE, instead?

> ===================================================================
> --- linux-pm.orig/kernel/power/Kconfig
> +++ linux-pm/kernel/power/Kconfig
> @@ -94,6 +94,7 @@ config PM_STD_PARTITION
>  config PM_SLEEP
>  	def_bool y
>  	depends on SUSPEND || HIBERNATE_CALLBACKS
> +	select PM_RUNTIME
>  
>  config PM_SLEEP_SMP
>  	def_bool y

								Pavel
Rafael J. Wysocki Nov. 18, 2014, 8:40 p.m. | #16
On Tuesday, November 18, 2014 09:34:11 AM Pavel Machek wrote:
> On Tue 2014-11-18 01:39:06, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > 
> > The number of and dependencies between high-level power management
> > Kconfig options make life much harder than necessary.  Several
> > conbinations of them have to be tested and supported, even though
> > some of those combinations are very rarely used in practice (it
> > they are used in practice at all).  Moreover, the fact that we
> > have separate independent Kconfig options for runtime PM and
> > system suspend is a serious obscacle for integration between
> > the two frameworks.
> > 
> > To overcome these difficulties, always select PM_RUNTIME if PM_SLEEP
> > is set.  Among other things, this will allow system suspend callbacks
> > provided by bus types and device drivers to rely on the runtime PM
> > framework regardless of the kernel configuration.
> 
> 3.18-rc5 still has:
> 
> config PM_RUNTIME
>         bool "Run-time PM core functionality"
>         depends on !IA64_HP_SIM
>         ---help---
> 
> So I assume this patch is against tree where PM_RUNTIME does not
> depend on anything?

Yes.

> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > ---
> > 
> > As a follow up.
> > 
> > Note that we won't need the patch making genpd select PM_RUNTIME with this,
> > because genpd already depends on PM.
> 
> Looking through the config file, there are more config options that
> should be stripped.
> 
> config SUSPEND_FREEZER
>         bool "Enable freezer for suspend to RAM/standby" \
> "Turning OFF this setting is NOT recommended! If in doubt, say Y."

Yeah, I'll gladly apply a patch removing this one. :-)

> config HIBERNATE_CALLBACKS
>        bool
> 
> ...can we just use CONFIG_HIBERNATE, instead?

We do, but in addition.

HIBERNATE_CALLBACKS is used by Xen IIRC and they don't want to build in the
whole hibernation image creation etc code (which they never use anyway).

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 3d39cc0228e9..2a8c64d0a43c 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -271,7 +271,7 @@  config PM_CLK
 
 config PM_GENERIC_DOMAINS
 	bool
-	depends on PM
+	select PM_RUNTIME
 
 config WQ_POWER_EFFICIENT_DEFAULT
 	bool "Enable workqueue power-efficient mode by default"