Hi,
On Thursday, 25 January 2007 03:52, Nigel Cunningham wrote:
Hi.
On Wed, 2007-01-24 at 21:03 -0500, Len Brown wrote:
Patch 03-05:
add ACPI sleep attributes in sysfs.
/proc/acpi/sleep is already deprecated by /sys/power/state.
Does that mean we drop
On Wednesday 24 January 2007 8:14 pm, Len Brown wrote:
On Sunday 07 January 2007 22:31, David Brownell wrote:
However, I'm not entirely sure /how/ that integration should happen. If
both the Linux driver and ACPI know how to enable wakeup for a device,
what should writing to
I think we need to make /sys/power/state handle S1.
There are two cases
1. Platform supports S1, but does not support S3.
This is more common. You see this a lot on server-class machines.
We could make mem simply mean S1 here b/c it is effectively
the closest
On Wed 2007-01-24 21:28:13, Len Brown wrote:
On Monday 08 January 2007 08:13, Pavel Machek wrote:
Hi!
This patch set is against acpi-test sysfs branch which already converts
ACPI to follow driver model. Now the ACPI procfs functions are
duplicated in sysfs step by step. And I want
Hi!
There will be another ACPI patch at some point, actually kicking
in hooks needed to handle system wakeup, but getting the PC into
the RTC class framework is an important first step.
Once there's a proper replacement for /proc/acpi/alarm it becomes
a candidate for removal. Maybe
Hi!
(Yes, there are huge gaps in Linux-PM wakeup support. Weak ACPI suppport
for it, especially from STR -- without swsusp -- is a big factor. I
was pleased to see RTC wakeup from ACPI S4 actually work ... first time
I've ever seen ACPI wakeup ever work correctly.)
Try your power
Hi!
This patch set is against acpi-test sysfs branch which already
converts
ACPI to follow driver model. Now the ACPI procfs functions are
duplicated in sysfs step by step. And I want the ACPI interface in
sysfs
works exactly the same way as in procfs.
No,
On Thu, 2007-01-25 at 20:51 +0100, Pavel Machek wrote:
Hi!
This patch set is against acpi-test sysfs branch which already
converts
ACPI to follow driver model. Now the ACPI procfs functions are
duplicated in sysfs step by step. And I want the ACPI interface in
Patch 03-05:
add ACPI sleep attributes in sysfs.
/proc/acpi/sleep is already deprecated by /sys/power/state.
Does that mean we drop standby (S1) capability on PCs?
I think we need to make /sys/power/state handle S1.
There are two cases
1. Platform supports S1, but does not
On Monday 08 January 2007 08:13, Pavel Machek wrote:
Hi!
This patch set is against acpi-test sysfs branch which already converts
ACPI to follow driver model. Now the ACPI procfs functions are
duplicated in sysfs step by step. And I want the ACPI interface in sysfs
works exactly the same
Hi.
On Wed, 2007-01-24 at 21:03 -0500, Len Brown wrote:
Patch 03-05:
add ACPI sleep attributes in sysfs.
/proc/acpi/sleep is already deprecated by /sys/power/state.
Does that mean we drop standby (S1) capability on PCs?
I think we need to make /sys/power/state handle S1.
Thanks for your detailed reply, David..
Third, stuff in /sys/power should be generic, and not depend on ACPI
infrastructure or models ... it should for example work for embedded
platforms where Linux runs on the bare metal. Moreover, in general
an ACPI-specific interface should be the very
On Sunday 07 January 2007 00:54, Matthew Garrett wrote:
On Sat, Jan 06, 2007 at 02:21:41PM -0800, David Brownell wrote:
Please tell me you mean devices with a /sys/devices/.../power/wakeup
attribute. And that ACPI is finally going to start working with those
attributes ...
I agree that
On Wednesday 10 January 2007 15:53, David Brownell wrote:
On Monday 08 January 2007 3:40 am, Zhang Rui wrote:
if /sys/class/rtc/rtcN/alarm can provide the same function, it's great
and I'll drop patch#03. I'll also mark /proc/acpi/alarm as deprecated if
David's patches are merged. :)
On Wed, Jan 24, 2007 at 11:14:22PM -0500, Len Brown wrote:
On Sunday 07 January 2007 22:31, David Brownell wrote:
However, I'm not entirely sure /how/ that integration should happen. If
both the Linux driver and ACPI know how to enable wakeup for a device,
what should writing to
On Monday 08 January 2007 3:40 am, Zhang Rui wrote:
if /sys/class/rtc/rtcN/alarm can provide the same function, it's great
and I'll drop patch#03. I'll also mark /proc/acpi/alarm as deprecated if
David's patches are merged. :)
One help there would be someone from the ACPI team signing off on
On Sun, 2007-01-07 at 05:54 +, Matthew Garrett wrote:
On Sat, Jan 06, 2007 at 02:21:41PM -0800, David Brownell wrote:
Please tell me you mean devices with a /sys/devices/.../power/wakeup
attribute. And that ACPI is finally going to start working with those
attributes ...
It's not
On Sun 2007-01-07 19:31:19, David Brownell wrote:
On Saturday 06 January 2007 9:54 pm, Matthew Garrett wrote:
On Sat, Jan 06, 2007 at 02:21:41PM -0800, David Brownell wrote:
Please tell me you mean devices with a /sys/devices/.../power/wakeup
attribute. And that ACPI is finally going
Hi!
This patch set is against acpi-test sysfs branch which already converts
ACPI to follow driver model. Now the ACPI procfs functions are
duplicated in sysfs step by step. And I want the ACPI interface in sysfs
works exactly the same way as in procfs.
No, you can't port same broken
Hi!
This patch set is against acpi-test sysfs branch, and will duplicate several
ACPI procfs functions in sysfs.
As struct subsystem power_subsys is referred and the interface under
/sys/power/ is changed by this patch series,
I wish to receive some comments from linux-pm too.
Thanks for
On Saturday 06 January 2007 9:54 pm, Matthew Garrett wrote:
On Sat, Jan 06, 2007 at 02:21:41PM -0800, David Brownell wrote:
Please tell me you mean devices with a /sys/devices/.../power/wakeup
attribute. And that ACPI is finally going to start working with those
attributes ...
It's
On Sat, Jan 06, 2007 at 02:21:41PM -0800, David Brownell wrote:
Please tell me you mean devices with a /sys/devices/.../power/wakeup
attribute. And that ACPI is finally going to start working with those
attributes ...
It's not necessarily possible to map from an ACPI object with a wakeup
22 matches
Mail list logo
