On Saturday 06 January 2007 3:35 am, Zhang Rui wrote:
> 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
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
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
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 ...
>
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 ...
>
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 fi
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 inter
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
> > 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
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
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 h
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 ver
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 ag
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 power/wakeup do?
If a native hardware device driver knows how t
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 writin
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
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
On Wednesday 24 January 2007 7:28 pm, Len Brown wrote:
> >
> > The latest patches relevant to the RTC used by ACPI are:
> >
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=116802017116195&w=2
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=116802044406838&w=2
> > http://marc.theaimsgroup
> > > 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 ef
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.
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 remov
On Thursday 25 January 2007 4:08 am, Pavel Machek wrote:
> 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
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
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 w
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 AC
26 matches
Mail list logo