Re: [PATCH 0/2] Introduce CONFIG_HIBERNATION and CONFIG_SUSPEND (updated)
On Sunday 29 July 2007 20:21, Linus Torvalds wrote: > > Ok, I took this, and modified Len's patch to re-introduce ACPI_SLEEP on > top of it (I took the easy way out, and just made PM_SLEEP imply > ACPI_SLEEP, which should make everything come out right. I could have > dropped ACPI_SLEEP entirely in favour of PM_SLEEP, but that would have > implied changing more of Len's patch than I was really comfy with). > > Len, Rafael, please do check that the end result looks ok. SUSPEND depends only on (!SMP || SUSPEND_SMP_POSSIBLE). This means that while we limit the architectures it can build on if they are SMP, it can build on any !SMP architecture -- which probably isn't what we want. I think the right way to go is your SUSPEND_UP_POSSIBLE suggestion. Honestly, I though it was overly verbose when I first read it, but I like it better now, especially since it works;-) I'll reply w/ an incremental patch. > I suspect ACPI could now take the PM_SLEEP/SUSPEND/HIBERNATE details into > account, and that some of the code is not necessary when HIBERNATE is not > selected, for example, but I'm not at all sure that it's worth it being > very fine-grained. As you know, I don't think that it is worth dedicated config options to save 16KB on an SMP+ACPI kernel. The prospect of adding code to slice that 16KB into finer grain savings seems even less worthwhile. -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Introduce CONFIG_HIBERNATION and CONFIG_SUSPEND (updated)
On Monday, 30 July 2007 02:21, Linus Torvalds wrote:
>
> Ok, I took this, and modified Len's patch to re-introduce ACPI_SLEEP on
> top of it (I took the easy way out, and just made PM_SLEEP imply
> ACPI_SLEEP, which should make everything come out right. I could have
> dropped ACPI_SLEEP entirely in favour of PM_SLEEP, but that would have
> implied changing more of Len's patch than I was really comfy with).
>
> Len, Rafael, please do check that the end result looks ok.
I only found two really minor issues covered by the appended patch (on top of
the current -git).
> I suspect ACPI could now take the PM_SLEEP/SUSPEND/HIBERNATE details into
> account, and that some of the code is not necessary when HIBERNATE is not
> selected, for example, but I'm not at all sure that it's worth it being
> very fine-grained.
Well, IMO, for now let's make sure everything works as is. :-)
Greetings,
Rafael
---
(1) I think it's better to use CONFIG_ACPI_SLEEP instead of CONFIG_PM_SLEEP in
include/acpi/acpi_bus.h , too, for consistency.
(2) x86_64 defconfig is outdated
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
arch/x86_64/defconfig |3 ---
include/acpi/acpi_bus.h |6 +++---
2 files changed, 3 insertions(+), 6 deletions(-)
Index: linux-2.6/include/acpi/acpi_bus.h
===
--- linux-2.6.orig/include/acpi/acpi_bus.h 2007-07-30 07:58:48.0
+0200
+++ linux-2.6/include/acpi/acpi_bus.h 2007-07-30 08:25:32.0 +0200
@@ -366,16 +366,16 @@ acpi_handle acpi_get_child(acpi_handle,
acpi_handle acpi_get_pci_rootbridge_handle(unsigned int, unsigned int);
#define DEVICE_ACPI_HANDLE(dev) ((acpi_handle)((dev)->archdata.acpi_handle))
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_ACPI_SLEEP
int acpi_pm_device_sleep_state(struct device *, int, int *);
-#else /* !CONFIG_PM_SLEEP */
+#else /* !CONFIG_ACPI_SLEEP */
static inline int acpi_pm_device_sleep_state(struct device *d, int w, int *p)
{
if (p)
*p = ACPI_STATE_D0;
return ACPI_STATE_D3;
}
-#endif /* !CONFIG_PM_SLEEP */
+#endif /* !CONFIG_ACPI_SLEEP */
#endif /* CONFIG_ACPI */
Index: linux-2.6/arch/x86_64/defconfig
===
--- linux-2.6.orig/arch/x86_64/defconfig2007-07-30 07:58:48.0
+0200
+++ linux-2.6/arch/x86_64/defconfig 2007-07-30 08:27:27.0 +0200
@@ -207,9 +207,6 @@ CONFIG_SUSPEND_SMP=y
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
-CONFIG_ACPI_SLEEP=y
-CONFIG_ACPI_SLEEP_PROC_FS=y
-CONFIG_ACPI_SLEEP_PROC_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Introduce CONFIG_HIBERNATION and CONFIG_SUSPEND (updated)
On Monday, 30 July 2007 02:21, Linus Torvalds wrote:
Ok, I took this, and modified Len's patch to re-introduce ACPI_SLEEP on
top of it (I took the easy way out, and just made PM_SLEEP imply
ACPI_SLEEP, which should make everything come out right. I could have
dropped ACPI_SLEEP entirely in favour of PM_SLEEP, but that would have
implied changing more of Len's patch than I was really comfy with).
Len, Rafael, please do check that the end result looks ok.
I only found two really minor issues covered by the appended patch (on top of
the current -git).
I suspect ACPI could now take the PM_SLEEP/SUSPEND/HIBERNATE details into
account, and that some of the code is not necessary when HIBERNATE is not
selected, for example, but I'm not at all sure that it's worth it being
very fine-grained.
Well, IMO, for now let's make sure everything works as is. :-)
Greetings,
Rafael
---
(1) I think it's better to use CONFIG_ACPI_SLEEP instead of CONFIG_PM_SLEEP in
include/acpi/acpi_bus.h , too, for consistency.
(2) x86_64 defconfig is outdated
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
arch/x86_64/defconfig |3 ---
include/acpi/acpi_bus.h |6 +++---
2 files changed, 3 insertions(+), 6 deletions(-)
Index: linux-2.6/include/acpi/acpi_bus.h
===
--- linux-2.6.orig/include/acpi/acpi_bus.h 2007-07-30 07:58:48.0
+0200
+++ linux-2.6/include/acpi/acpi_bus.h 2007-07-30 08:25:32.0 +0200
@@ -366,16 +366,16 @@ acpi_handle acpi_get_child(acpi_handle,
acpi_handle acpi_get_pci_rootbridge_handle(unsigned int, unsigned int);
#define DEVICE_ACPI_HANDLE(dev) ((acpi_handle)((dev)-archdata.acpi_handle))
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_ACPI_SLEEP
int acpi_pm_device_sleep_state(struct device *, int, int *);
-#else /* !CONFIG_PM_SLEEP */
+#else /* !CONFIG_ACPI_SLEEP */
static inline int acpi_pm_device_sleep_state(struct device *d, int w, int *p)
{
if (p)
*p = ACPI_STATE_D0;
return ACPI_STATE_D3;
}
-#endif /* !CONFIG_PM_SLEEP */
+#endif /* !CONFIG_ACPI_SLEEP */
#endif /* CONFIG_ACPI */
Index: linux-2.6/arch/x86_64/defconfig
===
--- linux-2.6.orig/arch/x86_64/defconfig2007-07-30 07:58:48.0
+0200
+++ linux-2.6/arch/x86_64/defconfig 2007-07-30 08:27:27.0 +0200
@@ -207,9 +207,6 @@ CONFIG_SUSPEND_SMP=y
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
-CONFIG_ACPI_SLEEP=y
-CONFIG_ACPI_SLEEP_PROC_FS=y
-CONFIG_ACPI_SLEEP_PROC_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Introduce CONFIG_HIBERNATION and CONFIG_SUSPEND (updated)
On Sunday 29 July 2007 20:21, Linus Torvalds wrote: Ok, I took this, and modified Len's patch to re-introduce ACPI_SLEEP on top of it (I took the easy way out, and just made PM_SLEEP imply ACPI_SLEEP, which should make everything come out right. I could have dropped ACPI_SLEEP entirely in favour of PM_SLEEP, but that would have implied changing more of Len's patch than I was really comfy with). Len, Rafael, please do check that the end result looks ok. SUSPEND depends only on (!SMP || SUSPEND_SMP_POSSIBLE). This means that while we limit the architectures it can build on if they are SMP, it can build on any !SMP architecture -- which probably isn't what we want. I think the right way to go is your SUSPEND_UP_POSSIBLE suggestion. Honestly, I though it was overly verbose when I first read it, but I like it better now, especially since it works;-) I'll reply w/ an incremental patch. I suspect ACPI could now take the PM_SLEEP/SUSPEND/HIBERNATE details into account, and that some of the code is not necessary when HIBERNATE is not selected, for example, but I'm not at all sure that it's worth it being very fine-grained. As you know, I don't think that it is worth dedicated config options to save 16KB on an SMP+ACPI kernel. The prospect of adding code to slice that 16KB into finer grain savings seems even less worthwhile. -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Introduce CONFIG_HIBERNATION and CONFIG_SUSPEND (updated)
Ok, I took this, and modified Len's patch to re-introduce ACPI_SLEEP on top of it (I took the easy way out, and just made PM_SLEEP imply ACPI_SLEEP, which should make everything come out right. I could have dropped ACPI_SLEEP entirely in favour of PM_SLEEP, but that would have implied changing more of Len's patch than I was really comfy with). Len, Rafael, please do check that the end result looks ok. I suspect ACPI could now take the PM_SLEEP/SUSPEND/HIBERNATE details into account, and that some of the code is not necessary when HIBERNATE is not selected, for example, but I'm not at all sure that it's worth it being very fine-grained. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Introduce CONFIG_HIBERNATION and CONFIG_SUSPEND (updated)
On Sunday, 29 July 2007 12:20, Rafael J. Wysocki wrote: > On Saturday, 28 July 2007 20:31, Linus Torvalds wrote: > > > > On Sat, 28 Jul 2007, Rafael J. Wysocki wrote: > > > > > > OK, I'll prepare a patch to introduce CONFIG_SUSPEND, but that will > > > require > > > quite a bit of (compilation) testing on different architectures. > > > > Sure. I'm not too worried, the fallout should be of the trivial kind. > > > > Also, mind basing it on the (independent) cleanups that Adrian already > > sent out. This is all intertwined.. > > OK, it took more time than I had hoped, but I wanted CONFIG_HIBERNATION and > CONFIG_SUSPEND to be really independent of each other. > > The two patches in the next messages implement the idea: > * replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATION > * introduce CONFIG_SUSPEND that selects CONFIG_HOTPLUG_CPU, if necessary, > and make it possible to choose suspend and hibernation independently of each > other. Unfortunately, the patches that I have posted are against 2.6.23-rc1 with the suspend and hibernation patchset applied (http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc1/patches/) . Sorry for that. The corresponding patches on top of the current -git are in the next two messages. They do the following: * replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATION * introduce CONFIG_SUSPEND that selects CONFIG_HOTPLUG_CPU, if necessary, and make it possible to choose suspend and hibernation independently of each other * update the top-level PM-related headers and the ACPI code related to suspend and hibernation to use the new definitions Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Introduce CONFIG_HIBERNATION and CONFIG_SUSPEND (updated)
On Sunday, 29 July 2007 12:20, Rafael J. Wysocki wrote: On Saturday, 28 July 2007 20:31, Linus Torvalds wrote: On Sat, 28 Jul 2007, Rafael J. Wysocki wrote: OK, I'll prepare a patch to introduce CONFIG_SUSPEND, but that will require quite a bit of (compilation) testing on different architectures. Sure. I'm not too worried, the fallout should be of the trivial kind. Also, mind basing it on the (independent) cleanups that Adrian already sent out. This is all intertwined.. OK, it took more time than I had hoped, but I wanted CONFIG_HIBERNATION and CONFIG_SUSPEND to be really independent of each other. The two patches in the next messages implement the idea: * replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATION * introduce CONFIG_SUSPEND that selects CONFIG_HOTPLUG_CPU, if necessary, and make it possible to choose suspend and hibernation independently of each other. Unfortunately, the patches that I have posted are against 2.6.23-rc1 with the suspend and hibernation patchset applied (http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc1/patches/) . Sorry for that. The corresponding patches on top of the current -git are in the next two messages. They do the following: * replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATION * introduce CONFIG_SUSPEND that selects CONFIG_HOTPLUG_CPU, if necessary, and make it possible to choose suspend and hibernation independently of each other * update the top-level PM-related headers and the ACPI code related to suspend and hibernation to use the new definitions Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Introduce CONFIG_HIBERNATION and CONFIG_SUSPEND (updated)
Ok, I took this, and modified Len's patch to re-introduce ACPI_SLEEP on top of it (I took the easy way out, and just made PM_SLEEP imply ACPI_SLEEP, which should make everything come out right. I could have dropped ACPI_SLEEP entirely in favour of PM_SLEEP, but that would have implied changing more of Len's patch than I was really comfy with). Len, Rafael, please do check that the end result looks ok. I suspect ACPI could now take the PM_SLEEP/SUSPEND/HIBERNATE details into account, and that some of the code is not necessary when HIBERNATE is not selected, for example, but I'm not at all sure that it's worth it being very fine-grained. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
