PM / Runtime: Kconfig: move ia64 dependency to arch/ia64/Kconfig
Subsystems (2)
PATCH 1/1 PM / Runtime: Kconfig: move ia64 dependency to arch/ia64/Kconfig
From: Kevin Hilman <[email protected]>
The IA64_HP_SIM dependency on PM_RUNTIME should be done in the arch Kconfig instead of in the PM core. Move it accordingly.
NOTE: arch/ia64/Kconfig currently does a 'select PM', which since commit 1eb208aea317 (PM: Make CONFIG_PM depend on (CONFIG_PM_SLEEP || CONFIG_PM_RUNTIME)) is effectively a noop unless PM_SLEEP or PM_RUNTIME are set elsewhere.
--- arch/ia64/Kconfig | 1 + kernel/power/Kconfig | 1 - 2 files changed, 1 insertion(+), 1 deletion(-)
arch/ia64/Kconfig +1 -0
@@ -233,6 +233,7 @@ config IA64_SGI_UV config IA64_HP_SIM bool "Ski-simulator" select SWIOTLB + depends on !PM_RUNTIME endchoice
kernel/power/Kconfig +0 -1
@@ -131,7 +131,6 @@ config PM_WAKELOCKS_GC config PM_RUNTIME bool "Run-time PM core functionality" - depends on !IA64_HP_SIM ---help--- Enable functionality allowing I/O devices to be put into energy-saving (low power) states at run time (or autosuspended) after a specified
Signature · 1 line
2.1.3
PATCH 1/1 PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled
From: Kevin Hilman <[email protected]>
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.
--- kernel/power/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/power/Kconfig +1 -1
@@ -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"
Signature · 1 line
2.1.3
Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled
Quoted 6 lines · Kevin Hilman
From: Kevin Hilman <[email protected]>
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?
Quoted 14 lines
Cc Ulf Hansson <[email protected]>Cc Geert Uytterhoeven <[email protected]>Cc Grygorii Strashko <[email protected]>Signed-off-by Kevin Hilman <[email protected]>--- kernel/power/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)kernel/power/Kconfig +0
-0
kernel/power/Kconfig config PM_CLK · line 274
Quoted 5 lines
kernel/power/Kconfig +1
-1@@ -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?
Quoted 6 lines
kernel/power/Kconfig +0
-1config WQ_POWER_EFFICIENT_DEFAULT bool "Enable workqueue power-efficient mode by default" --2.1.3
Kind regards
Uffe
Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled
Quoted 11 lines · Ulf Hansson
Quoted 6 lines · Kevin Hilman
From: Kevin Hilman <[email protected]>
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.
Quoted 7 lines
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_SLEEPandCONFIG_PM_SLEEP. So theoretically, why shouldn't genpd be able to do
/s /CONFIG_PM_SLEEP /CONFIG_PM_RUNTIME
Quoted 33 lines
that as well?
Quoted 14 lines
Cc Ulf Hansson <[email protected]>Cc Geert Uytterhoeven <[email protected]>Cc Grygorii Strashko <[email protected]>Signed-off-by Kevin Hilman <[email protected]>--- kernel/power/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)kernel/power/Kconfig +0
-0kernel/power/Kconfig config PM_CLK · line 274
Quoted 5 lines
kernel/power/Kconfig +1
-1@@ -271,7 +271,7 @@ config PM_CLK config PM_GENERIC_DOMAINS bool - depends on PM + select PM_RUNTIMEShouldn't we actually depend on
PM_RUNTIMEinstead?Quoted 6 lines
kernel/power/Kconfig +0
-1config WQ_POWER_EFFICIENT_DEFAULT bool "Enable workqueue power-efficient mode by default" --2.1.3
Kind regards
Uffe
Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled
In reply to Ulf HanssonHi Ulf,
Quoted 10 lines · Ulf Hansson
Quoted 6 lines · Kevin Hilman
From: Kevin Hilman <[email protected]>
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?
Quoted 8 lines
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_SLEEPandCONFIG_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
Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled
Quoted 46 lines · Kevin Hilman
Hi Ulf,
Quoted 10 lines · Ulf Hansson
Quoted 6 lines · Kevin Hilman
From: Kevin Hilman <[email protected]>
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?
Quoted 8 lines
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_SLEEPandCONFIG_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_SLEEPandPM_RUNTIME, but I'm not seeing why we should need to support genpd withoutPM_RUNTIMEenabled.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.
Quoted 7 lines
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
Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled
In reply to Kevin HilmanHi Kevin,
Quoted 1 line · Kevin Hilman
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 ;-)
Quoted 3 lines
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 -- [email protected]
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
Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled
Quoted 8 lines · Geert Uytterhoeven
Hi Kevin,
Quoted 1 line · Kevin Hilman
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?
Quoted 5 lines
Quoted 3 lines
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
Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled
Quoted 5 lines · Kevin Hilman
Quoted 3 lines · Geert Uytterhoeven
Hi Kevin,
On Thu, Nov 13, 2014 at 11:28 PM, Kevin Hilman <[email protected]> wrote:
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
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").
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
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
Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled
Quoted 12 lines · Rafael J. Wysocki
Quoted 11 lines · Kevin Hilman
Quoted 8 lines · Geert Uytterhoeven
Hi Kevin,
Quoted 1 line · Kevin Hilman
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 ;-)
Quoted 5 lines
Quoted 2 lines
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_RUNTIMEfor 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
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled
In reply to Kevin HilmanHi Kevin,
Quoted 9 lines · Kevin Hilman
Quoted 6 lines · Kevin Hilman
Quoted 1 line
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 -- [email protected]
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
Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled
Quoted 10 lines · Geert Uytterhoeven
Hi Kevin,
Quoted 7 lines · Kevin Hilman
Quoted 6 lines · Kevin Hilman
Quoted 1 line
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 ;-)
Quoted 6 lines
Quoted 2 lines
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_RUNTIMEturned 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.
Signature · 2 lines
I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.
Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled
Quoted 12 lines · Rafael J. Wysocki
Quoted 11 lines · Geert Uytterhoeven
Quoted 9 lines · Kevin Hilman
Quoted 6 lines · Kevin Hilman
Quoted 1 line
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?
Quoted 6 lines
Quoted 3 lines
I do mean with
CONFIG_PM_RUNTIMEturned off.If PM domain support is disabled, s2ram will not power down the PM domains.
But if
PM_RUNTIMEis enabled along with it, I don't think it will make much of a different, will it?
That's true.
Quoted 6 lines
Building the kernel with genpd and without
PM_RUNTIMEis possible today, but is it really useful? To me, it only seems to make people try to reinvent the wheel "becausePM_RUNTIMEmay be unset".I have to say I'm seriously considering to make
PM_SLEEPselectPM_RUNTIMEtoo 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 -- [email protected]
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
Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled
In reply to Rafael J. WysockiQuoted 21 lines · Rafael J. Wysocki
Quoted 10 lines · Geert Uytterhoeven
Hi Kevin,
Quoted 7 lines · Kevin Hilman
Quoted 6 lines · Kevin Hilman
Quoted 1 line
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 ;-)Quoted 6 lines
Quoted 2 lines
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_RUNTIMEturned off.If PM domain support is disabled, s2ram will not power down the PM domains.
But if
PM_RUNTIMEis enabled along with it, I don't think it will make much of a different, will it?
Quoted 6 lines
Building the kernel with genpd and without
PM_RUNTIMEis possible today, but is it really useful? To me, it only seems to make people try to reinvent the wheel "becausePM_RUNTIMEmay be unset".I have to say I'm seriously considering to make
PM_SLEEPselectPM_RUNTIMEtoo 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
PATCH 1/1 PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected (was: Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled)
From: Rafael J. Wysocki <[email protected]>
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.
---
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?
Rafael
--- kernel/power/Kconfig | 1 + 1 file changed, 1 insertion(+)
kernel/power/Kconfig +1 -0
@@ -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
Re: [PATCH] PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected
Quoted 17 lines · Rafael J. Wysocki
From: Rafael J. Wysocki <[email protected]>
The number of and dependencies between high-level power management
Kconfigoptions 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 independentKconfigoptions for runtime PM and system suspend is a serious obscacle for integration between the two frameworks.To overcome these difficulties, always select
PM_RUNTIMEifPM_SLEEPis 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 <[email protected]>
Quoted 8 lines
---
As a follow up.
Note that we won't need the patch making genpd select
PM_RUNTIMEwith this, because genpd already depends on PM.Thoughts, comments?
...with dancing and singing in the streets (or more my speed: a celebratory beer.)
Kevin
Geert Uytterhoeven
Tested-byRe: [PATCH] PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected
Quoted 21 lines · Kevin Hilman
Quoted 19 lines · Rafael J. Wysocki
From: Rafael J. Wysocki <[email protected]>
The number of and dependencies between high-level power management
Kconfigoptions 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 independentKconfigoptions for runtime PM and system suspend is a serious obscacle for integration between the two frameworks.To overcome these difficulties, always select
PM_RUNTIMEifPM_SLEEPis 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 <[email protected]>---
Quoted 8 lines
Quoted 6 lines
As a follow up.
Note that we won't need the patch making genpd select
PM_RUNTIMEwith this, because genpd already depends on PM.Thoughts, comments?
Acked-by Kevin Hilman <[email protected]>
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
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Re: [PATCH] PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected (was: Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled)
In reply to Rafael J. WysockiQuoted 11 lines · Rafael J. Wysocki
From: Rafael J. Wysocki <[email protected]>
The number of and dependencies between high-level power management
Kconfigoptions 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 independentKconfigoptions for runtime PM and system suspend is a serious obscacle for integration between the two frameworks.
Quoted 4 lines
To overcome these difficulties, always select
PM_RUNTIMEifPM_SLEEPis 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?
Quoted 7 lines
Signed-off-by Rafael J. Wysocki <[email protected]>---
As a follow up.
Note that we won't need the patch making genpd select
PM_RUNTIMEwith 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?
kernel/power/Kconfig config PM_STD_PARTITION · line 100
Quoted 11 lines
===================================================================
kernel/power/Kconfig +1
-0@@ -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
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH] PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected (was: Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled)
Quoted 19 lines · Pavel Machek
Quoted 11 lines · Rafael J. Wysocki
From: Rafael J. Wysocki <[email protected]>
The number of and dependencies between high-level power management
Kconfigoptions 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 independentKconfigoptions for runtime PM and system suspend is a serious obscacle for integration between the two frameworks.Quoted 4 lines
To overcome these difficulties, always select
PM_RUNTIMEifPM_SLEEPis 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:
Quoted 7 lines
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_RUNTIMEdoes not depend on anything?
Yes.
Quoted 8 lines
Quoted 7 lines
Signed-off-by Rafael J. Wysocki <[email protected]>---
As a follow up.
Note that we won't need the patch making genpd select
PM_RUNTIMEwith this, because genpd already depends on PM.
Quoted 6 lines
Looking through the config file, there are more config options that should be stripped.
config
SUSPEND_FREEZERbool "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. :-)
Quoted 4 lines
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
Quoted 11 lines · Kevin Hilman
From: Kevin Hilman <[email protected]>
The
IA64_HP_SIMdependency onPM_RUNTIMEshould be done in the archKconfiginstead of in the PM core. Move it accordingly.NOTE:
arch/ia64/Kconfigcurrently does a 'select PM', which since commit1eb208aea317(PM: MakeCONFIG_PMdepend on (CONFIG_PM_SLEEP||CONFIG_PM_RUNTIME)) is effectively a noop unlessPM_SLEEPorPM_RUNTIMEare set elsewhere.Signed-off-by Kevin Hilman <[email protected]>
Quoted 32 lines
--- arch/ia64/Kconfig | 1 + kernel/power/Kconfig | 1 - 2 files changed, 1 insertion(+), 1 deletion(-)arch/ia64/Kconfig +1
-0@@ -233,6 +233,7 @@ config IA64_SGI_UV config IA64_HP_SIM bool "Ski-simulator" select SWIOTLB + depends on !PM_RUNTIME endchoicekernel/power/Kconfig +0
-2@@ -131,7 +131,6 @@ config PM_WAKELOCKS_GC config PM_RUNTIME bool "Run-time PM core functionality" - depends on !IA64_HP_SIM ---help--- Enable functionality allowing I/O devices to be put into energy-saving (low power) states at run time (or autosuspended) after a specified --2.1.3