* Re: Power Mangement Interfaces
2007-04-02 16:55 ` Jordan Crouse
@ 2007-04-02 17:53 ` David Brownell
2007-04-02 17:53 ` David Brownell
` (6 subsequent siblings)
7 siblings, 0 replies; 126+ messages in thread
From: David Brownell @ 2007-04-02 17:53 UTC (permalink / raw)
To: Jordan Crouse; +Cc: linux-acpi, linux-pm, devel
On Monday 02 April 2007 9:55 am, Jordan Crouse wrote:
> On 01/04/07 17:28 -0700, David Brownell wrote:
> > > And so forth. Like the AT91, we enable the wakeup events prior to
> > > suspending. I'm willing to bet that other PM methods like ACPI
> > > could pick this up pretty quickly too.
> >
> > With AT91 (and most ARMs) the wake events are normal IRQs, and the
> > irq infrastructure already handles wake events cleanly. So I'd
> > claim they don't _want_ to change something that's inexpensive,
> > already deployed (training, code, testing, etc), and working.
> >
> > So I hope you'll tolerate me if I view this as less of a "how do
> > we get a generic solution" and more of a "how does _this_ x86-ish
> > issue get solved cleanly".
>
> Thats fair. x86 does live in a different world then the other embedded
> chips. I think its reasonable for the x86 folks to get their story straight
> and then move on from there.
And I think it's good that OLPC doesn't seem to be starved of the
relevant lowlevel chip specs, so the "story" can be based on what
the hardware needs, rather than only what ACPI allows.
> > > Moving
> > > it into the PM infrastructure seems the best way to handle everybody
> > > equally, regardless of the relative intelligence or stupidity of their
> > > hardware implementation.
> >
> > I guess that's where we disagree: you're assuming "one call to rule
> > them all", where I'm thinking that IRQ calls should manage IRQs,
> > PCI calls should manage PME#, and so on.
>
> Thats fine - I am not sold on a "one call to rule them all", but I do
> want to avoid any #ifdef CONFIG_PM_ACPI #elsif CONFIG_OLPC_PM #else
> nonsense.
Right. In terms of source code, per-device callbacks can encapsulate
that neatly: OLPC won't use ACPI files, and vice versa. There may be
cases where that approach isn't enough, but it should cover a bunch
of the most important cases. (Maybe OLPC won't need any more ...)
> We are keenly aware that we're committing a minor sin by implementing
> yet another PM interface for x86.
I couldn't call it a sin unless I thought that ACPI were a Goddess,
to be worshipped at the altar of HP/Intel/Microsoft/Phoenix/Toshiba!
Somehow, I don't think you'll find many people who think that ... ;)
> But we believe that our heart is in the
> right place, and we are dedicated to doing the right thing, and trying
> our hardest not to contribute further to fragmenting the PM subsystem with
> implementation specific code. In many cases we're looking to help
> bring the others into the fold, especially our fellow x86 implementations
> that suffer from the same issues that we do.
Implementation-specific stuff isn't really a problem except when sneaks
out into general purpose code. At that point you want some abstractions
to hide those platform details.
Yes, I suspect you could be a big help to non-ACPI implementors on x86.
> I appreciate your comments, and the rtc-cmos code will go to good use.
Good! RTCs are interesting to PM primarily because most platforms seem
to offer some kind of "wake alarm" mechanism ... which means they're a fair
test case for whether a cross-platform interface actually works!
- Dave
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: Power Mangement Interfaces
2007-04-02 16:55 ` Jordan Crouse
2007-04-02 17:53 ` David Brownell
@ 2007-04-02 17:53 ` David Brownell
2007-07-08 3:46 ` rtc-cmos not supporting RTC_AIE? Marcelo Tosatti
` (5 subsequent siblings)
7 siblings, 0 replies; 126+ messages in thread
From: David Brownell @ 2007-04-02 17:53 UTC (permalink / raw)
To: Jordan Crouse; +Cc: linux-acpi, linux-pm, devel
On Monday 02 April 2007 9:55 am, Jordan Crouse wrote:
> On 01/04/07 17:28 -0700, David Brownell wrote:
> > > And so forth. Like the AT91, we enable the wakeup events prior to
> > > suspending. I'm willing to bet that other PM methods like ACPI
> > > could pick this up pretty quickly too.
> >
> > With AT91 (and most ARMs) the wake events are normal IRQs, and the
> > irq infrastructure already handles wake events cleanly. So I'd
> > claim they don't _want_ to change something that's inexpensive,
> > already deployed (training, code, testing, etc), and working.
> >
> > So I hope you'll tolerate me if I view this as less of a "how do
> > we get a generic solution" and more of a "how does _this_ x86-ish
> > issue get solved cleanly".
>
> Thats fair. x86 does live in a different world then the other embedded
> chips. I think its reasonable for the x86 folks to get their story straight
> and then move on from there.
And I think it's good that OLPC doesn't seem to be starved of the
relevant lowlevel chip specs, so the "story" can be based on what
the hardware needs, rather than only what ACPI allows.
> > > Moving
> > > it into the PM infrastructure seems the best way to handle everybody
> > > equally, regardless of the relative intelligence or stupidity of their
> > > hardware implementation.
> >
> > I guess that's where we disagree: you're assuming "one call to rule
> > them all", where I'm thinking that IRQ calls should manage IRQs,
> > PCI calls should manage PME#, and so on.
>
> Thats fine - I am not sold on a "one call to rule them all", but I do
> want to avoid any #ifdef CONFIG_PM_ACPI #elsif CONFIG_OLPC_PM #else
> nonsense.
Right. In terms of source code, per-device callbacks can encapsulate
that neatly: OLPC won't use ACPI files, and vice versa. There may be
cases where that approach isn't enough, but it should cover a bunch
of the most important cases. (Maybe OLPC won't need any more ...)
> We are keenly aware that we're committing a minor sin by implementing
> yet another PM interface for x86.
I couldn't call it a sin unless I thought that ACPI were a Goddess,
to be worshipped at the altar of HP/Intel/Microsoft/Phoenix/Toshiba!
Somehow, I don't think you'll find many people who think that ... ;)
> But we believe that our heart is in the
> right place, and we are dedicated to doing the right thing, and trying
> our hardest not to contribute further to fragmenting the PM subsystem with
> implementation specific code. In many cases we're looking to help
> bring the others into the fold, especially our fellow x86 implementations
> that suffer from the same issues that we do.
Implementation-specific stuff isn't really a problem except when sneaks
out into general purpose code. At that point you want some abstractions
to hide those platform details.
Yes, I suspect you could be a big help to non-ACPI implementors on x86.
> I appreciate your comments, and the rtc-cmos code will go to good use.
Good! RTCs are interesting to PM primarily because most platforms seem
to offer some kind of "wake alarm" mechanism ... which means they're a fair
test case for whether a cross-platform interface actually works!
- Dave
^ permalink raw reply [flat|nested] 126+ messages in thread* rtc-cmos not supporting RTC_AIE?
2007-04-02 16:55 ` Jordan Crouse
2007-04-02 17:53 ` David Brownell
2007-04-02 17:53 ` David Brownell
@ 2007-07-08 3:46 ` Marcelo Tosatti
2007-07-08 3:46 ` Marcelo Tosatti
` (4 subsequent siblings)
7 siblings, 0 replies; 126+ messages in thread
From: Marcelo Tosatti @ 2007-07-08 3:46 UTC (permalink / raw)
To: David Brownell; +Cc: linux-pm, devel, linux-acpi
On Mon, Apr 02, 2007 at 10:55:11AM -0600, Jordan Crouse wrote:
> On 01/04/07 17:28 -0700, David Brownell wrote:
> >
> > > So, for better or worse, we are implementing a new power management
> > > manger. Here is the code:
> > >
> > > http://dev.laptop.org/git.do?p=olpc-2.6;a=blob;h=e6e19ac32a881be962db7190f2cb460e9f60a9da;hb=powermgmt;f=arch/i386/kernel/olpc-pm.c
> >
> > Does that work yet with CONFIG_NO_HZ, so that the system idle loop
> > enters some "almost everyting is turned off" low power state? Or
> > would that be something other than a "PM Manager"?
>
> I think eventually we'll get into entering deeper states in the idle
> loop. For now, we're just going into the classic C1 / hlt state, which
> is actually quite thrifty on the Geode, due to automatic hardware clock
> gating that happens throughout the chip(s).
>
> > > > > On the Geode, we have 17 possible wake sources, all of which are ORed
> > > >
> > > > What are those? You mentioned four before. (RTC alarm, two GPIOs,
> > > > and the power button.) I'd guess various PCI devices can also issue
> > > > wakeups. (And if USB is one of them, up to 126 USB devices hooked
> > > > up to each USB host controller!)
> > >
> > > The silicon can handle wakeups from RTC, a sleep button, a power button,
> > > 8 GPIO groups, the USB controller (covering any and all USB events),
> > > UART1, UART2, SMbus and the PIC.
> > >
> > > OLPC really only cares about 4 of those, because our only sleep state
> > > is ~S3, and the PIC, smbus, UARTs and USB are off in S3. We also only
> > > have the power button, and all the rest of the wakeup sources come from
> > > the GPIOs.
> >
> > So it's a slightly deeper "S3" than I've usually seen, but not by much.
> >
> > And correct me if I'm wrong, but your RTC can work with "rtc-cmos", and
> > the wake hooks I've posted (and which will be in the next MM release)
> > sound like they'll work just fine (given OLPC-specific implementation,
> > which is clearly not included in the code above).
>
> Indeed, and thank you much for that work - we'll be sure to integrate
> it.
>
> > > > > This looks very good, and is pretty close to what I was proposing.
> > > > > Replace the acpi_*_event() calls with a generic pm_ infrastructure, and
> > > >
> > > > Inside ACPI ... why?
> > >
> > > I'm not saying inside ACPI - I'm saying at the driver level.
> >
> > Whereas in that patch, the only ACPI calls were inside ACPI itself;
> > and that driver only had a callback. FWIW that's the first time
> > I've ever needed to have indirection on wakeup event handling ...
>
> This is the first real "embedded" scenario to pop its head up in x86 land,
> up to this point, most of the boards have just been really weak desktops.
>
> > > And so forth. Like the AT91, we enable the wakeup events prior to
> > > suspending. I'm willing to bet that other PM methods like ACPI
> > > could pick this up pretty quickly too.
> >
> > With AT91 (and most ARMs) the wake events are normal IRQs, and the
> > irq infrastructure already handles wake events cleanly. So I'd
> > claim they don't _want_ to change something that's inexpensive,
> > already deployed (training, code, testing, etc), and working.
> >
> > So I hope you'll tolerate me if I view this as less of a "how do
> > we get a generic solution" and more of a "how does _this_ x86-ish
> > issue get solved cleanly".
>
> Thats fair. x86 does live in a different world then the other embedded
> chips. I think its reasonable for the x86 folks to get their story straight
> and then move on from there.
>
> > > Moving
> > > it into the PM infrastructure seems the best way to handle everybody
> > > equally, regardless of the relative intelligence or stupidity of their
> > > hardware implementation.
> >
> > I guess that's where we disagree: you're assuming "one call to rule
> > them all", where I'm thinking that IRQ calls should manage IRQs,
> > PCI calls should manage PME#, and so on.
>
> Thats fine - I am not sold on a "one call to rule them all", but I do
> want to avoid any #ifdef CONFIG_PM_ACPI #elsif CONFIG_OLPC_PM #else
> nonsense.
>
> > > I guess we'll probably have to do something similar for our OLPC PM code
> > > - but thats the sort of platform specific fragmentation thing I was trying
> > > to avoid.
> >
> > Since OLPC isn't using ACPI, it can be more like embedded Linux,
> > and just Do The Right Thing ... create platform devices, etc. :)
> >
> > My point above was that ACPI isn't yet integrating with the things
> > it needs to be integrating with. If you're concerned about how to
> > work with wakeup events in Linux, don't even bother looking at ACPI.
> > Look at the embedded implementations; look at USB. AT91 is by far
> > the cleanest and most complete (simplest hardware too!!), but some
> > of the other systems (OMAP, PXA, SA1100, etc) also implement wakeup
> > using board-specific code.
> >
> > OLPC _could_ use that same "board-specific hacks" approach found in
> > most embedded platforms. I'm glad you're thinking about how to
> > avoid doing that.
>
> We are keenly aware that we're committing a minor sin by implementing
> yet another PM interface for x86. But we believe that our heart is in the
> right place, and we are dedicated to doing the right thing, and trying
> our hardest not to contribute further to fragmenting the PM subsystem with
> implementation specific code. In many cases we're looking to help
> bring the others into the fold, especially our fellow x86 implementations
> that suffer from the same issues that we do.
>
> I appreciate your comments, and the rtc-cmos code will go to good use.
David,
Is there any reason why programs using RTC_AIE/RTC_ALM_SET ioctls are
unable to arm alarm irq's?
I'm aware of the new RTC_WKALM_SET... but shouldnt backward
compatibility be kept?
The code seems to imply that its not supported anymore, however ioctl
returns success but no alarm is fired (for instance alarm.enabled is set
to 0):
case RTC_ALM_SET:
if (copy_from_user(&alarm.time, uarg, sizeof(tm)))
return -EFAULT;
alarm.enabled = 0;
alarm.pending = 0;
alarm.time.tm_wday = -1;
alarm.time.tm_yday = -1;
alarm.time.tm_isdst = -1;
Thanks
^ permalink raw reply [flat|nested] 126+ messages in thread* rtc-cmos not supporting RTC_AIE?
2007-04-02 16:55 ` Jordan Crouse
` (2 preceding siblings ...)
2007-07-08 3:46 ` rtc-cmos not supporting RTC_AIE? Marcelo Tosatti
@ 2007-07-08 3:46 ` Marcelo Tosatti
2007-07-08 5:26 ` David Brownell
2007-07-08 5:26 ` David Brownell
2007-07-08 3:49 ` [PATCH] rtc-cmos: use cmos_rtc_board_info to determine wake_on callback Marcelo Tosatti
` (3 subsequent siblings)
7 siblings, 2 replies; 126+ messages in thread
From: Marcelo Tosatti @ 2007-07-08 3:46 UTC (permalink / raw)
To: David Brownell; +Cc: linux-pm, devel, linux-acpi
On Mon, Apr 02, 2007 at 10:55:11AM -0600, Jordan Crouse wrote:
> On 01/04/07 17:28 -0700, David Brownell wrote:
> >
> > > So, for better or worse, we are implementing a new power management
> > > manger. Here is the code:
> > >
> > > http://dev.laptop.org/git.do?p=olpc-2.6;a=blob;h=e6e19ac32a881be962db7190f2cb460e9f60a9da;hb=powermgmt;f=arch/i386/kernel/olpc-pm.c
> >
> > Does that work yet with CONFIG_NO_HZ, so that the system idle loop
> > enters some "almost everyting is turned off" low power state? Or
> > would that be something other than a "PM Manager"?
>
> I think eventually we'll get into entering deeper states in the idle
> loop. For now, we're just going into the classic C1 / hlt state, which
> is actually quite thrifty on the Geode, due to automatic hardware clock
> gating that happens throughout the chip(s).
>
> > > > > On the Geode, we have 17 possible wake sources, all of which are ORed
> > > >
> > > > What are those? You mentioned four before. (RTC alarm, two GPIOs,
> > > > and the power button.) I'd guess various PCI devices can also issue
> > > > wakeups. (And if USB is one of them, up to 126 USB devices hooked
> > > > up to each USB host controller!)
> > >
> > > The silicon can handle wakeups from RTC, a sleep button, a power button,
> > > 8 GPIO groups, the USB controller (covering any and all USB events),
> > > UART1, UART2, SMbus and the PIC.
> > >
> > > OLPC really only cares about 4 of those, because our only sleep state
> > > is ~S3, and the PIC, smbus, UARTs and USB are off in S3. We also only
> > > have the power button, and all the rest of the wakeup sources come from
> > > the GPIOs.
> >
> > So it's a slightly deeper "S3" than I've usually seen, but not by much.
> >
> > And correct me if I'm wrong, but your RTC can work with "rtc-cmos", and
> > the wake hooks I've posted (and which will be in the next MM release)
> > sound like they'll work just fine (given OLPC-specific implementation,
> > which is clearly not included in the code above).
>
> Indeed, and thank you much for that work - we'll be sure to integrate
> it.
>
> > > > > This looks very good, and is pretty close to what I was proposing.
> > > > > Replace the acpi_*_event() calls with a generic pm_ infrastructure, and
> > > >
> > > > Inside ACPI ... why?
> > >
> > > I'm not saying inside ACPI - I'm saying at the driver level.
> >
> > Whereas in that patch, the only ACPI calls were inside ACPI itself;
> > and that driver only had a callback. FWIW that's the first time
> > I've ever needed to have indirection on wakeup event handling ...
>
> This is the first real "embedded" scenario to pop its head up in x86 land,
> up to this point, most of the boards have just been really weak desktops.
>
> > > And so forth. Like the AT91, we enable the wakeup events prior to
> > > suspending. I'm willing to bet that other PM methods like ACPI
> > > could pick this up pretty quickly too.
> >
> > With AT91 (and most ARMs) the wake events are normal IRQs, and the
> > irq infrastructure already handles wake events cleanly. So I'd
> > claim they don't _want_ to change something that's inexpensive,
> > already deployed (training, code, testing, etc), and working.
> >
> > So I hope you'll tolerate me if I view this as less of a "how do
> > we get a generic solution" and more of a "how does _this_ x86-ish
> > issue get solved cleanly".
>
> Thats fair. x86 does live in a different world then the other embedded
> chips. I think its reasonable for the x86 folks to get their story straight
> and then move on from there.
>
> > > Moving
> > > it into the PM infrastructure seems the best way to handle everybody
> > > equally, regardless of the relative intelligence or stupidity of their
> > > hardware implementation.
> >
> > I guess that's where we disagree: you're assuming "one call to rule
> > them all", where I'm thinking that IRQ calls should manage IRQs,
> > PCI calls should manage PME#, and so on.
>
> Thats fine - I am not sold on a "one call to rule them all", but I do
> want to avoid any #ifdef CONFIG_PM_ACPI #elsif CONFIG_OLPC_PM #else
> nonsense.
>
> > > I guess we'll probably have to do something similar for our OLPC PM code
> > > - but thats the sort of platform specific fragmentation thing I was trying
> > > to avoid.
> >
> > Since OLPC isn't using ACPI, it can be more like embedded Linux,
> > and just Do The Right Thing ... create platform devices, etc. :)
> >
> > My point above was that ACPI isn't yet integrating with the things
> > it needs to be integrating with. If you're concerned about how to
> > work with wakeup events in Linux, don't even bother looking at ACPI.
> > Look at the embedded implementations; look at USB. AT91 is by far
> > the cleanest and most complete (simplest hardware too!!), but some
> > of the other systems (OMAP, PXA, SA1100, etc) also implement wakeup
> > using board-specific code.
> >
> > OLPC _could_ use that same "board-specific hacks" approach found in
> > most embedded platforms. I'm glad you're thinking about how to
> > avoid doing that.
>
> We are keenly aware that we're committing a minor sin by implementing
> yet another PM interface for x86. But we believe that our heart is in the
> right place, and we are dedicated to doing the right thing, and trying
> our hardest not to contribute further to fragmenting the PM subsystem with
> implementation specific code. In many cases we're looking to help
> bring the others into the fold, especially our fellow x86 implementations
> that suffer from the same issues that we do.
>
> I appreciate your comments, and the rtc-cmos code will go to good use.
David,
Is there any reason why programs using RTC_AIE/RTC_ALM_SET ioctls are
unable to arm alarm irq's?
I'm aware of the new RTC_WKALM_SET... but shouldnt backward
compatibility be kept?
The code seems to imply that its not supported anymore, however ioctl
returns success but no alarm is fired (for instance alarm.enabled is set
to 0):
case RTC_ALM_SET:
if (copy_from_user(&alarm.time, uarg, sizeof(tm)))
return -EFAULT;
alarm.enabled = 0;
alarm.pending = 0;
alarm.time.tm_wday = -1;
alarm.time.tm_yday = -1;
alarm.time.tm_isdst = -1;
Thanks
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: rtc-cmos not supporting RTC_AIE?
2007-07-08 3:46 ` Marcelo Tosatti
@ 2007-07-08 5:26 ` David Brownell
2007-07-08 5:26 ` David Brownell
1 sibling, 0 replies; 126+ messages in thread
From: David Brownell @ 2007-07-08 5:26 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-pm, rtc-linux, devel, linux-acpi
On Saturday 07 July 2007, Marcelo Tosatti wrote:
>
> David,
>
> Is there any reason why programs using RTC_AIE/RTC_ALM_SET ioctls are
> unable to arm alarm irq's?
The ALM_SET request never did! And I'm pretty sure AIE_ON does
indeed set it ... the test cases use ALM_SET then AIE_ON, which
is the "traditional" idiom (i.e. legacy drivers/char/rtc.c idiom).
> I'm aware of the new RTC_WKALM_SET... but shouldnt backward
> compatibility be kept?
According to <linux/rtc.h> the ALM_SET ioctl takes an rtc_time,
while WKALM_SET takes an rtc_wkalm ... which differs from the
former by including the flag controlling wheter the alarm will
be enabled (or not) when setting the alarm. (Model inherited
from EFI.)
> The code seems to imply that its not supported anymore, however ioctl
> returns success but no alarm is fired (for instance alarm.enabled is set
> to 0):
>
> case RTC_ALM_SET:
> if (copy_from_user(&alarm.time, uarg, sizeof(tm)))
> return -EFAULT;
>
> alarm.enabled = 0;
> alarm.pending = 0;
> alarm.time.tm_wday = -1;
> alarm.time.tm_yday = -1;
> alarm.time.tm_isdst = -1;
That code is generic RTC framework code (rtc-dev.c), and not
code specific to rtc-cmos ... the comment immediately following
that (2.6.22-rc7 and previous) should clarify many of the issues.
I think the current manpage does the same. (If it mentions the
/dev/rtc0, /dev/rtc1, etc files, it should be current enough.)
What it does is just stuff the rtc_time into the expanded
rtc_wkalm. The idea is that the RTC drivers only support one
alarm-setting method, but the /dev/rtcN ioctl interface uses
it in two modes:
- "legacy", up to 24 hours in the future, and requiring
the alarm to be enabled later with AIE_ON;
- "EFI-style", into the arbitrary future, and bundling the
flag saying whether to enable the alarm.
Since ALM_SET is the legacy mode, it requires separate AIE_ON
(from the RTC driver directly). But RTC_WKALM_SET doesn't.
- Dave
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: rtc-cmos not supporting RTC_AIE?
2007-07-08 3:46 ` Marcelo Tosatti
2007-07-08 5:26 ` David Brownell
@ 2007-07-08 5:26 ` David Brownell
2007-07-08 19:03 ` Marcelo Tosatti
2007-07-08 19:03 ` Marcelo Tosatti
1 sibling, 2 replies; 126+ messages in thread
From: David Brownell @ 2007-07-08 5:26 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Jordan Crouse, linux-acpi, linux-pm, devel, rtc-linux
On Saturday 07 July 2007, Marcelo Tosatti wrote:
>
> David,
>
> Is there any reason why programs using RTC_AIE/RTC_ALM_SET ioctls are
> unable to arm alarm irq's?
The ALM_SET request never did! And I'm pretty sure AIE_ON does
indeed set it ... the test cases use ALM_SET then AIE_ON, which
is the "traditional" idiom (i.e. legacy drivers/char/rtc.c idiom).
> I'm aware of the new RTC_WKALM_SET... but shouldnt backward
> compatibility be kept?
According to <linux/rtc.h> the ALM_SET ioctl takes an rtc_time,
while WKALM_SET takes an rtc_wkalm ... which differs from the
former by including the flag controlling wheter the alarm will
be enabled (or not) when setting the alarm. (Model inherited
from EFI.)
> The code seems to imply that its not supported anymore, however ioctl
> returns success but no alarm is fired (for instance alarm.enabled is set
> to 0):
>
> case RTC_ALM_SET:
> if (copy_from_user(&alarm.time, uarg, sizeof(tm)))
> return -EFAULT;
>
> alarm.enabled = 0;
> alarm.pending = 0;
> alarm.time.tm_wday = -1;
> alarm.time.tm_yday = -1;
> alarm.time.tm_isdst = -1;
That code is generic RTC framework code (rtc-dev.c), and not
code specific to rtc-cmos ... the comment immediately following
that (2.6.22-rc7 and previous) should clarify many of the issues.
I think the current manpage does the same. (If it mentions the
/dev/rtc0, /dev/rtc1, etc files, it should be current enough.)
What it does is just stuff the rtc_time into the expanded
rtc_wkalm. The idea is that the RTC drivers only support one
alarm-setting method, but the /dev/rtcN ioctl interface uses
it in two modes:
- "legacy", up to 24 hours in the future, and requiring
the alarm to be enabled later with AIE_ON;
- "EFI-style", into the arbitrary future, and bundling the
flag saying whether to enable the alarm.
Since ALM_SET is the legacy mode, it requires separate AIE_ON
(from the RTC driver directly). But RTC_WKALM_SET doesn't.
- Dave
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: rtc-cmos not supporting RTC_AIE?
2007-07-08 5:26 ` David Brownell
@ 2007-07-08 19:03 ` Marcelo Tosatti
2007-07-08 19:03 ` Marcelo Tosatti
1 sibling, 0 replies; 126+ messages in thread
From: Marcelo Tosatti @ 2007-07-08 19:03 UTC (permalink / raw)
To: David Brownell; +Cc: rtc-linux, linux-acpi, linux-pm, devel
On Sat, Jul 07, 2007 at 10:26:49PM -0700, David Brownell wrote:
> On Saturday 07 July 2007, Marcelo Tosatti wrote:
>
> >
> > David,
> >
> > Is there any reason why programs using RTC_AIE/RTC_ALM_SET ioctls are
> > unable to arm alarm irq's?
>
> The ALM_SET request never did! And I'm pretty sure AIE_ON does
> indeed set it ... the test cases use ALM_SET then AIE_ON, which
> is the "traditional" idiom (i.e. legacy drivers/char/rtc.c idiom).
My point is that RTC_ALM_SET after RTC_AIE_ON works with drivers/char/rtc.c
but not rtc-cmos:
ret = ioctl(fd, RTC_AIE_ON);
if (ret) {
perror("ioctl RTC_AIE_ON");
exit(0);
}
ret = ioctl(fd, RTC_ALM_SET, &rtctime);
if (ret) {
perror("ioctl RTC_ALM_SET");
exit(0);
}
I think its fine to consider such applications broken anyway?
> > I'm aware of the new RTC_WKALM_SET... but shouldnt backward
> > compatibility be kept?
>
> According to <linux/rtc.h> the ALM_SET ioctl takes an rtc_time,
> while WKALM_SET takes an rtc_wkalm ... which differs from the
> former by including the flag controlling wheter the alarm will
> be enabled (or not) when setting the alarm. (Model inherited
> from EFI.)
Right.
>
> > The code seems to imply that its not supported anymore, however ioctl
> > returns success but no alarm is fired (for instance alarm.enabled is set
> > to 0):
> >
> > case RTC_ALM_SET:
> > if (copy_from_user(&alarm.time, uarg, sizeof(tm)))
> > return -EFAULT;
> >
> > alarm.enabled = 0;
> > alarm.pending = 0;
> > alarm.time.tm_wday = -1;
> > alarm.time.tm_yday = -1;
> > alarm.time.tm_isdst = -1;
>
> That code is generic RTC framework code (rtc-dev.c), and not
> code specific to rtc-cmos ... the comment immediately following
> that (2.6.22-rc7 and previous) should clarify many of the issues.
>
> I think the current manpage does the same. (If it mentions the
> /dev/rtc0, /dev/rtc1, etc files, it should be current enough.)
>
> What it does is just stuff the rtc_time into the expanded
> rtc_wkalm. The idea is that the RTC drivers only support one
> alarm-setting method, but the /dev/rtcN ioctl interface uses
> it in two modes:
>
> - "legacy", up to 24 hours in the future, and requiring
> the alarm to be enabled later with AIE_ON;
>
> - "EFI-style", into the arbitrary future, and bundling the
> flag saying whether to enable the alarm.
>
> Since ALM_SET is the legacy mode, it requires separate AIE_ON
> (from the RTC driver directly). But RTC_WKALM_SET doesn't.
>
> - Dave
>
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: rtc-cmos not supporting RTC_AIE?
2007-07-08 5:26 ` David Brownell
2007-07-08 19:03 ` Marcelo Tosatti
@ 2007-07-08 19:03 ` Marcelo Tosatti
2007-07-08 19:17 ` David Brownell
2007-07-08 19:17 ` David Brownell
1 sibling, 2 replies; 126+ messages in thread
From: Marcelo Tosatti @ 2007-07-08 19:03 UTC (permalink / raw)
To: David Brownell; +Cc: rtc-linux, linux-acpi, linux-pm, devel
On Sat, Jul 07, 2007 at 10:26:49PM -0700, David Brownell wrote:
> On Saturday 07 July 2007, Marcelo Tosatti wrote:
>
> >
> > David,
> >
> > Is there any reason why programs using RTC_AIE/RTC_ALM_SET ioctls are
> > unable to arm alarm irq's?
>
> The ALM_SET request never did! And I'm pretty sure AIE_ON does
> indeed set it ... the test cases use ALM_SET then AIE_ON, which
> is the "traditional" idiom (i.e. legacy drivers/char/rtc.c idiom).
My point is that RTC_ALM_SET after RTC_AIE_ON works with drivers/char/rtc.c
but not rtc-cmos:
ret = ioctl(fd, RTC_AIE_ON);
if (ret) {
perror("ioctl RTC_AIE_ON");
exit(0);
}
ret = ioctl(fd, RTC_ALM_SET, &rtctime);
if (ret) {
perror("ioctl RTC_ALM_SET");
exit(0);
}
I think its fine to consider such applications broken anyway?
> > I'm aware of the new RTC_WKALM_SET... but shouldnt backward
> > compatibility be kept?
>
> According to <linux/rtc.h> the ALM_SET ioctl takes an rtc_time,
> while WKALM_SET takes an rtc_wkalm ... which differs from the
> former by including the flag controlling wheter the alarm will
> be enabled (or not) when setting the alarm. (Model inherited
> from EFI.)
Right.
>
> > The code seems to imply that its not supported anymore, however ioctl
> > returns success but no alarm is fired (for instance alarm.enabled is set
> > to 0):
> >
> > case RTC_ALM_SET:
> > if (copy_from_user(&alarm.time, uarg, sizeof(tm)))
> > return -EFAULT;
> >
> > alarm.enabled = 0;
> > alarm.pending = 0;
> > alarm.time.tm_wday = -1;
> > alarm.time.tm_yday = -1;
> > alarm.time.tm_isdst = -1;
>
> That code is generic RTC framework code (rtc-dev.c), and not
> code specific to rtc-cmos ... the comment immediately following
> that (2.6.22-rc7 and previous) should clarify many of the issues.
>
> I think the current manpage does the same. (If it mentions the
> /dev/rtc0, /dev/rtc1, etc files, it should be current enough.)
>
> What it does is just stuff the rtc_time into the expanded
> rtc_wkalm. The idea is that the RTC drivers only support one
> alarm-setting method, but the /dev/rtcN ioctl interface uses
> it in two modes:
>
> - "legacy", up to 24 hours in the future, and requiring
> the alarm to be enabled later with AIE_ON;
>
> - "EFI-style", into the arbitrary future, and bundling the
> flag saying whether to enable the alarm.
>
> Since ALM_SET is the legacy mode, it requires separate AIE_ON
> (from the RTC driver directly). But RTC_WKALM_SET doesn't.
>
> - Dave
>
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: rtc-cmos not supporting RTC_AIE?
2007-07-08 19:03 ` Marcelo Tosatti
@ 2007-07-08 19:17 ` David Brownell
2007-07-08 19:17 ` David Brownell
1 sibling, 0 replies; 126+ messages in thread
From: David Brownell @ 2007-07-08 19:17 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-pm, rtc-linux, devel, linux-acpi
On Sunday 08 July 2007, Marcelo Tosatti wrote:
> My point is that RTC_ALM_SET after RTC_AIE_ON works with drivers/char/rtc.c
> but not rtc-cmos:
>
> ret = ioctl(fd, RTC_AIE_ON);
> if (ret) {
> perror("ioctl RTC_AIE_ON");
> exit(0);
> }
>
> ret = ioctl(fd, RTC_ALM_SET, &rtctime);
> if (ret) {
> perror("ioctl RTC_ALM_SET");
> exit(0);
> }
>
> I think its fine to consider such applications broken anyway?
I think so ... although that's unfortunately another difference
between the legacy x86-mostly code and the newer RTC framework.
Unless enough folk strongly disagree, I'd say this is just something
else to watch out for as part of converting. Not every quirk got
carried forward.
- Dave
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: rtc-cmos not supporting RTC_AIE?
2007-07-08 19:03 ` Marcelo Tosatti
2007-07-08 19:17 ` David Brownell
@ 2007-07-08 19:17 ` David Brownell
2007-07-08 19:31 ` Richard Hughes
2007-07-08 19:31 ` rtc-cmos not supporting RTC_AIE? Richard Hughes
1 sibling, 2 replies; 126+ messages in thread
From: David Brownell @ 2007-07-08 19:17 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-pm, rtc-linux, devel, linux-acpi
On Sunday 08 July 2007, Marcelo Tosatti wrote:
> My point is that RTC_ALM_SET after RTC_AIE_ON works with drivers/char/rtc.c
> but not rtc-cmos:
>
> ret = ioctl(fd, RTC_AIE_ON);
> if (ret) {
> perror("ioctl RTC_AIE_ON");
> exit(0);
> }
>
> ret = ioctl(fd, RTC_ALM_SET, &rtctime);
> if (ret) {
> perror("ioctl RTC_ALM_SET");
> exit(0);
> }
>
> I think its fine to consider such applications broken anyway?
I think so ... although that's unfortunately another difference
between the legacy x86-mostly code and the newer RTC framework.
Unless enough folk strongly disagree, I'd say this is just something
else to watch out for as part of converting. Not every quirk got
carried forward.
- Dave
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: rtc-cmos not supporting RTC_AIE?
2007-07-08 19:17 ` David Brownell
@ 2007-07-08 19:31 ` Richard Hughes
2007-07-08 20:15 ` Hibernate after alarm wakes from STR David Brownell
2007-07-08 20:15 ` David Brownell
2007-07-08 19:31 ` rtc-cmos not supporting RTC_AIE? Richard Hughes
1 sibling, 2 replies; 126+ messages in thread
From: Richard Hughes @ 2007-07-08 19:31 UTC (permalink / raw)
To: David Brownell; +Cc: linux-acpi, linux-pm, devel, rtc-linux
On Sun, 2007-07-08 at 12:17 -0700, David Brownell wrote:
>
> I think so ... although that's unfortunately another difference
> between the legacy x86-mostly code and the newer RTC framework.
(sorry for hijacking the thread)
Is this the interface should stuff like HAL use to do:
* Suspend for 10 minutes
* auto wakeup and then hibernate.
I figure we can do a suspend setting the rtc using the ioctls and then
we wakeup, and HAL has to know that we woke up from the alarm rather
than from a lid event or keypress.
Is this something we can do (or should do) for OLPC and general ACPI?
Cheers guys.
Richard.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Hibernate after alarm wakes from STR
2007-07-08 19:31 ` Richard Hughes
@ 2007-07-08 20:15 ` David Brownell
2007-07-08 20:15 ` David Brownell
1 sibling, 0 replies; 126+ messages in thread
From: David Brownell @ 2007-07-08 20:15 UTC (permalink / raw)
To: Richard Hughes; +Cc: linux-acpi, linux-pm, devel, rtc-linux
On Sunday 08 July 2007, Richard Hughes wrote:
> On Sun, 2007-07-08 at 12:17 -0700, David Brownell wrote:
> >
> > I think so ... although that's unfortunately another difference
> > between the legacy x86-mostly code and the newer RTC framework.
>
> (sorry for hijacking the thread)
I changed $SUBJECT ...
> Is this the interface should stuff like HAL use to do:
>
> * Suspend for 10 minutes
> * auto wakeup and then hibernate...
That is, "Suspend-to-RAM" or "standby"? Yes, assuming that works on
this particular system. Arguably that would be a direction for
cpuidle to think about too, but I think alarm-driven wakeup is more
ready-to-use at this point.
> I figure we can do a suspend setting the rtc using the ioctls and then
> we wakeup, and HAL has to know that we woke up from the alarm rather
> than from a lid event or keypress.
... although I don't know whether that particular distinction is
made to userspace right now. ACPI provides a bit like that, and
at least a few other systems can do something analagous.
That is, we may want to provide a bit more information about the
specific event which triggered wakeup. I don't believe there is
such an interface, in general.
Plus, the notion seems kind of racey to me. (If you press a key
right while the wakealarm fires, you don't want hibernation..)
> Is this something we can do (or should do) for OLPC and general ACPI?
I'd certainly rather see laptops doing that than what they do now:
running the battery out, and needing filesystem recovery!!
- Dave
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Hibernate after alarm wakes from STR
2007-07-08 19:31 ` Richard Hughes
2007-07-08 20:15 ` Hibernate after alarm wakes from STR David Brownell
@ 2007-07-08 20:15 ` David Brownell
2007-07-08 22:31 ` Marcelo Tosatti
2007-07-08 22:31 ` Marcelo Tosatti
1 sibling, 2 replies; 126+ messages in thread
From: David Brownell @ 2007-07-08 20:15 UTC (permalink / raw)
To: Richard Hughes; +Cc: linux-acpi, linux-pm, devel, rtc-linux
On Sunday 08 July 2007, Richard Hughes wrote:
> On Sun, 2007-07-08 at 12:17 -0700, David Brownell wrote:
> >
> > I think so ... although that's unfortunately another difference
> > between the legacy x86-mostly code and the newer RTC framework.
>
> (sorry for hijacking the thread)
I changed $SUBJECT ...
> Is this the interface should stuff like HAL use to do:
>
> * Suspend for 10 minutes
> * auto wakeup and then hibernate...
That is, "Suspend-to-RAM" or "standby"? Yes, assuming that works on
this particular system. Arguably that would be a direction for
cpuidle to think about too, but I think alarm-driven wakeup is more
ready-to-use at this point.
> I figure we can do a suspend setting the rtc using the ioctls and then
> we wakeup, and HAL has to know that we woke up from the alarm rather
> than from a lid event or keypress.
... although I don't know whether that particular distinction is
made to userspace right now. ACPI provides a bit like that, and
at least a few other systems can do something analagous.
That is, we may want to provide a bit more information about the
specific event which triggered wakeup. I don't believe there is
such an interface, in general.
Plus, the notion seems kind of racey to me. (If you press a key
right while the wakealarm fires, you don't want hibernation..)
> Is this something we can do (or should do) for OLPC and general ACPI?
I'd certainly rather see laptops doing that than what they do now:
running the battery out, and needing filesystem recovery!!
- Dave
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Hibernate after alarm wakes from STR
2007-07-08 20:15 ` David Brownell
@ 2007-07-08 22:31 ` Marcelo Tosatti
2007-07-09 2:44 ` David Brownell
2007-07-09 2:44 ` David Brownell
2007-07-08 22:31 ` Marcelo Tosatti
1 sibling, 2 replies; 126+ messages in thread
From: Marcelo Tosatti @ 2007-07-08 22:31 UTC (permalink / raw)
To: David Brownell; +Cc: rtc-linux, linux-acpi, linux-pm, devel
On Sun, Jul 08, 2007 at 01:15:40PM -0700, David Brownell wrote:
> On Sunday 08 July 2007, Richard Hughes wrote:
> > On Sun, 2007-07-08 at 12:17 -0700, David Brownell wrote:
> > >
> > > I think so ... although that's unfortunately another difference
> > > between the legacy x86-mostly code and the newer RTC framework.
> >
> > (sorry for hijacking the thread)
>
> I changed $SUBJECT ...
>
>
> > Is this the interface should stuff like HAL use to do:
> >
> > * Suspend for 10 minutes
> > * auto wakeup and then hibernate...
>
> That is, "Suspend-to-RAM" or "standby"? Yes, assuming that works on
> this particular system. Arguably that would be a direction for
> cpuidle to think about too, but I think alarm-driven wakeup is more
> ready-to-use at this point.
>
>
> > I figure we can do a suspend setting the rtc using the ioctls and then
> > we wakeup, and HAL has to know that we woke up from the alarm rather
> > than from a lid event or keypress.
On OLPC hibernate would be suspend-to-disk, but we haven't done any
testing with that yet. It would be necessary to check for available disk
space before attempting it (or reserving space perhaps?).
> ... although I don't know whether that particular distinction is
> made to userspace right now. ACPI provides a bit like that, and
> at least a few other systems can do something analagous.
Yes, we can poke at registers to find that out.
> That is, we may want to provide a bit more information about the
> specific event which triggered wakeup. I don't believe there is
> such an interface, in general.
What would be a nice interface? Perhaps an additional file under
/sys/devices/.../power/wakeup_fired or something (only for devices with
can_wakeup set).
> Plus, the notion seems kind of racey to me. (If you press a key
> right while the wakealarm fires, you don't want hibernation..)
Then you check if the any key or other wakeup event has happened other
than RTC... I don't see any problem with that.
> > Is this something we can do (or should do) for OLPC and general ACPI?
>
> I'd certainly rather see laptops doing that than what they do now:
> running the battery out, and needing filesystem recovery!!
Yep.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Hibernate after alarm wakes from STR
2007-07-08 22:31 ` Marcelo Tosatti
@ 2007-07-09 2:44 ` David Brownell
2007-07-09 2:44 ` David Brownell
1 sibling, 0 replies; 126+ messages in thread
From: David Brownell @ 2007-07-09 2:44 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-acpi, linux-pm, Richard Hughes, rtc-linux
On Sunday 08 July 2007, Marcelo Tosatti wrote:
> On Sun, Jul 08, 2007 at 01:15:40PM -0700, David Brownell wrote:
> > On Sunday 08 July 2007, Richard Hughes wrote:
> >
> > That is, we may want to provide a bit more information about the
> > specific event which triggered wakeup. I don't believe there is
> > such an interface, in general.
>
> What would be a nice interface? Perhaps an additional file under
> /sys/devices/.../power/wakeup_fired or something (only for devices with
> can_wakeup set).
Better a /sys/power/wakeup_event (or whatever) that's more easily
found. It could link to the device issuing the event.
> > Plus, the notion seems kind of racey to me. (If you press a key
> > right while the wakealarm fires, you don't want hibernation..)
>
> Then you check if the any key or other wakeup event has happened other
> than RTC... I don't see any problem with that.
It might be best not to need to re-activate the whole system from
STR though ... it ought to be possible to just power off, having
already written the image to disk. Right?
Yes, there's all that stuff about how to quiesce the system properly,
freezer/icebox/flamesuits/etc. Regardless, going from STR to fully
operational and then hibernating would take time and energy that
might not be available...
- Dave
> > > Is this something we can do (or should do) for OLPC and general ACPI?
> >
> > I'd certainly rather see laptops doing that than what they do now:
> > running the battery out, and needing filesystem recovery!!
>
> Yep.
>
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Hibernate after alarm wakes from STR
2007-07-08 22:31 ` Marcelo Tosatti
2007-07-09 2:44 ` David Brownell
@ 2007-07-09 2:44 ` David Brownell
2007-07-09 8:34 ` Richard Hughes
` (3 more replies)
1 sibling, 4 replies; 126+ messages in thread
From: David Brownell @ 2007-07-09 2:44 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Richard Hughes, linux-pm, rtc-linux, linux-acpi
On Sunday 08 July 2007, Marcelo Tosatti wrote:
> On Sun, Jul 08, 2007 at 01:15:40PM -0700, David Brownell wrote:
> > On Sunday 08 July 2007, Richard Hughes wrote:
> >
> > That is, we may want to provide a bit more information about the
> > specific event which triggered wakeup. I don't believe there is
> > such an interface, in general.
>
> What would be a nice interface? Perhaps an additional file under
> /sys/devices/.../power/wakeup_fired or something (only for devices with
> can_wakeup set).
Better a /sys/power/wakeup_event (or whatever) that's more easily
found. It could link to the device issuing the event.
> > Plus, the notion seems kind of racey to me. (If you press a key
> > right while the wakealarm fires, you don't want hibernation..)
>
> Then you check if the any key or other wakeup event has happened other
> than RTC... I don't see any problem with that.
It might be best not to need to re-activate the whole system from
STR though ... it ought to be possible to just power off, having
already written the image to disk. Right?
Yes, there's all that stuff about how to quiesce the system properly,
freezer/icebox/flamesuits/etc. Regardless, going from STR to fully
operational and then hibernating would take time and energy that
might not be available...
- Dave
> > > Is this something we can do (or should do) for OLPC and general ACPI?
> >
> > I'd certainly rather see laptops doing that than what they do now:
> > running the battery out, and needing filesystem recovery!!
>
> Yep.
>
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: Hibernate after alarm wakes from STR
2007-07-09 2:44 ` David Brownell
@ 2007-07-09 8:34 ` Richard Hughes
2007-07-09 8:34 ` Richard Hughes
` (2 subsequent siblings)
3 siblings, 0 replies; 126+ messages in thread
From: Richard Hughes @ 2007-07-09 8:34 UTC (permalink / raw)
To: David Brownell; +Cc: linux-acpi, linux-pm, rtc-linux
On Sun, 2007-07-08 at 19:44 -0700, David Brownell wrote:
> On Sunday 08 July 2007, Marcelo Tosatti wrote:
> > On Sun, Jul 08, 2007 at 01:15:40PM -0700, David Brownell wrote:
> > > On Sunday 08 July 2007, Richard Hughes wrote:
> > >
> > > That is, we may want to provide a bit more information about the
> > > specific event which triggered wakeup. I don't believe there is
> > > such an interface, in general.
> >
> > What would be a nice interface? Perhaps an additional file under
> > /sys/devices/.../power/wakeup_fired or something (only for devices with
> > can_wakeup set).
>
> Better a /sys/power/wakeup_event (or whatever) that's more easily
> found. It could link to the device issuing the event.
Good plan.
> > > Plus, the notion seems kind of racey to me. (If you press a key
> > > right while the wakealarm fires, you don't want hibernation..)
> >
> > Then you check if the any key or other wakeup event has happened other
> > than RTC... I don't see any problem with that.
>
> It might be best not to need to re-activate the whole system from
> STR though ... it ought to be possible to just power off, having
> already written the image to disk. Right?
>
> Yes, there's all that stuff about how to quiesce the system properly,
> freezer/icebox/flamesuits/etc. Regardless, going from STR to fully
> operational and then hibernating would take time and energy that
> might not be available...
Sure, although quick-suspend on a few minutes idle, slow
hibernate-on-long idle is one of the biggest requested features of
g-p-m.
Richard.
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: Hibernate after alarm wakes from STR
2007-07-09 2:44 ` David Brownell
2007-07-09 8:34 ` Richard Hughes
@ 2007-07-09 8:34 ` Richard Hughes
2007-07-09 15:40 ` Marcelo Tosatti
2007-07-09 15:40 ` Marcelo Tosatti
3 siblings, 0 replies; 126+ messages in thread
From: Richard Hughes @ 2007-07-09 8:34 UTC (permalink / raw)
To: David Brownell; +Cc: Marcelo Tosatti, linux-pm, rtc-linux, linux-acpi
On Sun, 2007-07-08 at 19:44 -0700, David Brownell wrote:
> On Sunday 08 July 2007, Marcelo Tosatti wrote:
> > On Sun, Jul 08, 2007 at 01:15:40PM -0700, David Brownell wrote:
> > > On Sunday 08 July 2007, Richard Hughes wrote:
> > >
> > > That is, we may want to provide a bit more information about the
> > > specific event which triggered wakeup. I don't believe there is
> > > such an interface, in general.
> >
> > What would be a nice interface? Perhaps an additional file under
> > /sys/devices/.../power/wakeup_fired or something (only for devices with
> > can_wakeup set).
>
> Better a /sys/power/wakeup_event (or whatever) that's more easily
> found. It could link to the device issuing the event.
Good plan.
> > > Plus, the notion seems kind of racey to me. (If you press a key
> > > right while the wakealarm fires, you don't want hibernation..)
> >
> > Then you check if the any key or other wakeup event has happened other
> > than RTC... I don't see any problem with that.
>
> It might be best not to need to re-activate the whole system from
> STR though ... it ought to be possible to just power off, having
> already written the image to disk. Right?
>
> Yes, there's all that stuff about how to quiesce the system properly,
> freezer/icebox/flamesuits/etc. Regardless, going from STR to fully
> operational and then hibernating would take time and energy that
> might not be available...
Sure, although quick-suspend on a few minutes idle, slow
hibernate-on-long idle is one of the biggest requested features of
g-p-m.
Richard.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Hibernate after alarm wakes from STR
2007-07-09 2:44 ` David Brownell
2007-07-09 8:34 ` Richard Hughes
2007-07-09 8:34 ` Richard Hughes
@ 2007-07-09 15:40 ` Marcelo Tosatti
2007-07-09 15:40 ` Marcelo Tosatti
3 siblings, 0 replies; 126+ messages in thread
From: Marcelo Tosatti @ 2007-07-09 15:40 UTC (permalink / raw)
To: David Brownell; +Cc: linux-acpi, linux-pm, Richard Hughes, rtc-linux
On Sun, Jul 08, 2007 at 07:44:03PM -0700, David Brownell wrote:
> On Sunday 08 July 2007, Marcelo Tosatti wrote:
> > On Sun, Jul 08, 2007 at 01:15:40PM -0700, David Brownell wrote:
> > > On Sunday 08 July 2007, Richard Hughes wrote:
> > >
> > > That is, we may want to provide a bit more information about the
> > > specific event which triggered wakeup. I don't believe there is
> > > such an interface, in general.
> >
> > What would be a nice interface? Perhaps an additional file under
> > /sys/devices/.../power/wakeup_fired or something (only for devices with
> > can_wakeup set).
>
> Better a /sys/power/wakeup_event (or whatever) that's more easily
> found. It could link to the device issuing the event.
As you mentioned, there might be two wakeup sources (RTC and power
button for instance) or even more at the same time.
Do you think its fine to simply but the device separated by spaces in
the wakeup_event file?
Sounds fine by me, but what about the one-value-per-file sysfs rule?
> > > Plus, the notion seems kind of racey to me. (If you press a key
> > > right while the wakealarm fires, you don't want hibernation..)
> >
> > Then you check if the any key or other wakeup event has happened other
> > than RTC... I don't see any problem with that.
>
> It might be best not to need to re-activate the whole system from
> STR though ... it ought to be possible to just power off, having
> already written the image to disk. Right?
Perhaps, yes...
> Yes, there's all that stuff about how to quiesce the system properly,
> freezer/icebox/flamesuits/etc. Regardless, going from STR to fully
> operational and then hibernating would take time and energy that
> might not be available...
True, that needs to be taken into account.
> - Dave
>
>
> > > > Is this something we can do (or should do) for OLPC and general ACPI?
> > >
> > > I'd certainly rather see laptops doing that than what they do now:
> > > running the battery out, and needing filesystem recovery!!
> >
> > Yep.
> >
>
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Hibernate after alarm wakes from STR
2007-07-09 2:44 ` David Brownell
` (2 preceding siblings ...)
2007-07-09 15:40 ` Marcelo Tosatti
@ 2007-07-09 15:40 ` Marcelo Tosatti
2007-07-09 16:26 ` David Brownell
2007-07-09 16:26 ` David Brownell
3 siblings, 2 replies; 126+ messages in thread
From: Marcelo Tosatti @ 2007-07-09 15:40 UTC (permalink / raw)
To: David Brownell
Cc: Marcelo Tosatti, Richard Hughes, linux-pm, rtc-linux, linux-acpi
On Sun, Jul 08, 2007 at 07:44:03PM -0700, David Brownell wrote:
> On Sunday 08 July 2007, Marcelo Tosatti wrote:
> > On Sun, Jul 08, 2007 at 01:15:40PM -0700, David Brownell wrote:
> > > On Sunday 08 July 2007, Richard Hughes wrote:
> > >
> > > That is, we may want to provide a bit more information about the
> > > specific event which triggered wakeup. I don't believe there is
> > > such an interface, in general.
> >
> > What would be a nice interface? Perhaps an additional file under
> > /sys/devices/.../power/wakeup_fired or something (only for devices with
> > can_wakeup set).
>
> Better a /sys/power/wakeup_event (or whatever) that's more easily
> found. It could link to the device issuing the event.
As you mentioned, there might be two wakeup sources (RTC and power
button for instance) or even more at the same time.
Do you think its fine to simply but the device separated by spaces in
the wakeup_event file?
Sounds fine by me, but what about the one-value-per-file sysfs rule?
> > > Plus, the notion seems kind of racey to me. (If you press a key
> > > right while the wakealarm fires, you don't want hibernation..)
> >
> > Then you check if the any key or other wakeup event has happened other
> > than RTC... I don't see any problem with that.
>
> It might be best not to need to re-activate the whole system from
> STR though ... it ought to be possible to just power off, having
> already written the image to disk. Right?
Perhaps, yes...
> Yes, there's all that stuff about how to quiesce the system properly,
> freezer/icebox/flamesuits/etc. Regardless, going from STR to fully
> operational and then hibernating would take time and energy that
> might not be available...
True, that needs to be taken into account.
> - Dave
>
>
> > > > Is this something we can do (or should do) for OLPC and general ACPI?
> > >
> > > I'd certainly rather see laptops doing that than what they do now:
> > > running the battery out, and needing filesystem recovery!!
> >
> > Yep.
> >
>
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: Hibernate after alarm wakes from STR
2007-07-09 15:40 ` Marcelo Tosatti
@ 2007-07-09 16:26 ` David Brownell
2007-07-09 16:26 ` David Brownell
1 sibling, 0 replies; 126+ messages in thread
From: David Brownell @ 2007-07-09 16:26 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-acpi, linux-pm, Richard Hughes, rtc-linux
On Monday 09 July 2007, Marcelo Tosatti wrote:
> On Sun, Jul 08, 2007 at 07:44:03PM -0700, David Brownell wrote:
> > Better a /sys/power/wakeup_event (or whatever) that's more easily
> > found. It could link to the device issuing the event.
>
> As you mentioned, there might be two wakeup sources (RTC and power
> button for instance) or even more at the same time.
Actually I though I said that there would be races. Though come
to think of it, one way they'd show up on a typical embedded system
would be to have multiple wake IRQs pending ... you couldn't tell
which one came first. (The typical case would be a single event,
of course.) ACPI-ish systems would do that with GPEs and the
magic "rtc woke" flag.
And then there are shared IRQ lines serving as wake sources. There
could be three wake-enabled devices on that line (plus others that
aren't wake-enabled); the drivers returning IRQ_HANDLED should likely
be reported as having been wake sources, but not the ones returning
IRQ_NONE ...
... so yes, systems might need to present multiple wake events.
> Do you think its fine to simply but the device separated by spaces in
> the wakeup_event file?
>
> Sounds fine by me, but what about the one-value-per-file sysfs rule?
Better to have that node be a directory of links then, rather than
a single link.
Note that I'm just throwing ideas out there. I suspect that
in the general case it may not be easy to map from wake event
to device, without infrastructure that's now missing.
- Dave
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Hibernate after alarm wakes from STR
2007-07-09 15:40 ` Marcelo Tosatti
2007-07-09 16:26 ` David Brownell
@ 2007-07-09 16:26 ` David Brownell
2007-07-10 2:45 ` Nigel Cunningham
2007-07-10 2:45 ` [linux-pm] " Nigel Cunningham
1 sibling, 2 replies; 126+ messages in thread
From: David Brownell @ 2007-07-09 16:26 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Richard Hughes, linux-pm, rtc-linux, linux-acpi
On Monday 09 July 2007, Marcelo Tosatti wrote:
> On Sun, Jul 08, 2007 at 07:44:03PM -0700, David Brownell wrote:
> > Better a /sys/power/wakeup_event (or whatever) that's more easily
> > found. It could link to the device issuing the event.
>
> As you mentioned, there might be two wakeup sources (RTC and power
> button for instance) or even more at the same time.
Actually I though I said that there would be races. Though come
to think of it, one way they'd show up on a typical embedded system
would be to have multiple wake IRQs pending ... you couldn't tell
which one came first. (The typical case would be a single event,
of course.) ACPI-ish systems would do that with GPEs and the
magic "rtc woke" flag.
And then there are shared IRQ lines serving as wake sources. There
could be three wake-enabled devices on that line (plus others that
aren't wake-enabled); the drivers returning IRQ_HANDLED should likely
be reported as having been wake sources, but not the ones returning
IRQ_NONE ...
... so yes, systems might need to present multiple wake events.
> Do you think its fine to simply but the device separated by spaces in
> the wakeup_event file?
>
> Sounds fine by me, but what about the one-value-per-file sysfs rule?
Better to have that node be a directory of links then, rather than
a single link.
Note that I'm just throwing ideas out there. I suspect that
in the general case it may not be easy to map from wake event
to device, without infrastructure that's now missing.
- Dave
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Re: Hibernate after alarm wakes from STR
2007-07-09 16:26 ` David Brownell
@ 2007-07-10 2:45 ` Nigel Cunningham
2007-07-10 2:45 ` [linux-pm] " Nigel Cunningham
1 sibling, 0 replies; 126+ messages in thread
From: Nigel Cunningham @ 2007-07-10 2:45 UTC (permalink / raw)
To: linux-pm; +Cc: Richard Hughes, rtc-linux, linux-acpi
[-- Attachment #1.1: Type: text/plain, Size: 2645 bytes --]
Hi.
On Tuesday 10 July 2007 02:26:32 David Brownell wrote:
> On Monday 09 July 2007, Marcelo Tosatti wrote:
> > On Sun, Jul 08, 2007 at 07:44:03PM -0700, David Brownell wrote:
>
> > > Better a /sys/power/wakeup_event (or whatever) that's more easily
> > > found. It could link to the device issuing the event.
> >
> > As you mentioned, there might be two wakeup sources (RTC and power
> > button for instance) or even more at the same time.
>
> Actually I though I said that there would be races. Though come
> to think of it, one way they'd show up on a typical embedded system
> would be to have multiple wake IRQs pending ... you couldn't tell
> which one came first. (The typical case would be a single event,
> of course.) ACPI-ish systems would do that with GPEs and the
> magic "rtc woke" flag.
>
> And then there are shared IRQ lines serving as wake sources. There
> could be three wake-enabled devices on that line (plus others that
> aren't wake-enabled); the drivers returning IRQ_HANDLED should likely
> be reported as having been wake sources, but not the ones returning
> IRQ_NONE ...
>
> ... so yes, systems might need to present multiple wake events.
>
>
> > Do you think its fine to simply but the device separated by spaces in
> > the wakeup_event file?
> >
> > Sounds fine by me, but what about the one-value-per-file sysfs rule?
>
> Better to have that node be a directory of links then, rather than
> a single link.
>
> Note that I'm just throwing ideas out there. I suspect that
> in the general case it may not be easy to map from wake event
> to device, without infrastructure that's now missing.
FWIW, I've recently added code to Suspend2 to allow it to (optionally) set the
RTC wake alarm when it's finished writing the image and check the lid switch
when waking, entering a different sleep state if the lid switch is still
closed. It achieves this by letting the user set the name of an rtc alarm to
use (the 'rtc0' in /sys/class/rtc/rtc0/*) and of a button to use (lid/LID
in /proc/acpi/button/lid/LID/*). It then opens the button directory's state
file and the rtc directory's since_epoch and wakealarm files, and uses them
to determine read the time since epoch and set the wakealarm and determine
whether the lid button is still closed.
I don't really like the opening /proc and /sysfs files in this way - whatever
solution you come up with, could you consider exposing some way for kernel
code to do this more neatly?
Regards,
Nigel
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [linux-pm] Re: Hibernate after alarm wakes from STR
2007-07-09 16:26 ` David Brownell
2007-07-10 2:45 ` Nigel Cunningham
@ 2007-07-10 2:45 ` Nigel Cunningham
2007-07-10 16:51 ` David Brownell
2007-07-10 16:51 ` [linux-pm] " David Brownell
1 sibling, 2 replies; 126+ messages in thread
From: Nigel Cunningham @ 2007-07-10 2:45 UTC (permalink / raw)
To: linux-pm
Cc: David Brownell, Marcelo Tosatti, linux-acpi, Richard Hughes, rtc-linux
[-- Attachment #1: Type: text/plain, Size: 2645 bytes --]
Hi.
On Tuesday 10 July 2007 02:26:32 David Brownell wrote:
> On Monday 09 July 2007, Marcelo Tosatti wrote:
> > On Sun, Jul 08, 2007 at 07:44:03PM -0700, David Brownell wrote:
>
> > > Better a /sys/power/wakeup_event (or whatever) that's more easily
> > > found. It could link to the device issuing the event.
> >
> > As you mentioned, there might be two wakeup sources (RTC and power
> > button for instance) or even more at the same time.
>
> Actually I though I said that there would be races. Though come
> to think of it, one way they'd show up on a typical embedded system
> would be to have multiple wake IRQs pending ... you couldn't tell
> which one came first. (The typical case would be a single event,
> of course.) ACPI-ish systems would do that with GPEs and the
> magic "rtc woke" flag.
>
> And then there are shared IRQ lines serving as wake sources. There
> could be three wake-enabled devices on that line (plus others that
> aren't wake-enabled); the drivers returning IRQ_HANDLED should likely
> be reported as having been wake sources, but not the ones returning
> IRQ_NONE ...
>
> ... so yes, systems might need to present multiple wake events.
>
>
> > Do you think its fine to simply but the device separated by spaces in
> > the wakeup_event file?
> >
> > Sounds fine by me, but what about the one-value-per-file sysfs rule?
>
> Better to have that node be a directory of links then, rather than
> a single link.
>
> Note that I'm just throwing ideas out there. I suspect that
> in the general case it may not be easy to map from wake event
> to device, without infrastructure that's now missing.
FWIW, I've recently added code to Suspend2 to allow it to (optionally) set the
RTC wake alarm when it's finished writing the image and check the lid switch
when waking, entering a different sleep state if the lid switch is still
closed. It achieves this by letting the user set the name of an rtc alarm to
use (the 'rtc0' in /sys/class/rtc/rtc0/*) and of a button to use (lid/LID
in /proc/acpi/button/lid/LID/*). It then opens the button directory's state
file and the rtc directory's since_epoch and wakealarm files, and uses them
to determine read the time since epoch and set the wakealarm and determine
whether the lid button is still closed.
I don't really like the opening /proc and /sysfs files in this way - whatever
solution you come up with, could you consider exposing some way for kernel
code to do this more neatly?
Regards,
Nigel
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Re: Hibernate after alarm wakes from STR
2007-07-10 2:45 ` [linux-pm] " Nigel Cunningham
@ 2007-07-10 16:51 ` David Brownell
2007-07-10 16:51 ` [linux-pm] " David Brownell
1 sibling, 0 replies; 126+ messages in thread
From: David Brownell @ 2007-07-10 16:51 UTC (permalink / raw)
To: nigel; +Cc: linux-acpi, linux-pm, Richard Hughes, rtc-linux
On Monday 09 July 2007, Nigel Cunningham wrote:
> Hi.
>
> On Tuesday 10 July 2007 02:26:32 David Brownell wrote:
> > On Monday 09 July 2007, Marcelo Tosatti wrote:
> > > On Sun, Jul 08, 2007 at 07:44:03PM -0700, David Brownell wrote:
> >
> > > > Better a /sys/power/wakeup_event (or whatever) that's more easily
> > > > found. It could link to the device issuing the event.
> > >
> > > As you mentioned, there might be two wakeup sources (RTC and power
> > > button for instance) or even more at the same time.
> >
> > Actually I though I said that there would be races. Though come
> > to think of it, one way they'd show up on a typical embedded system
> > would be to have multiple wake IRQs pending ... you couldn't tell
> > which one came first. (The typical case would be a single event,
> > of course.) ACPI-ish systems would do that with GPEs and the
> > magic "rtc woke" flag.
> >
> > And then there are shared IRQ lines serving as wake sources. There
> > could be three wake-enabled devices on that line (plus others that
> > aren't wake-enabled); the drivers returning IRQ_HANDLED should likely
> > be reported as having been wake sources, but not the ones returning
> > IRQ_NONE ...
> >
> > ... so yes, systems might need to present multiple wake events.
> >
> >
> > > Do you think its fine to simply but the device separated by spaces in
> > > the wakeup_event file?
> > >
> > > Sounds fine by me, but what about the one-value-per-file sysfs rule?
> >
> > Better to have that node be a directory of links then, rather than
> > a single link.
> >
> > Note that I'm just throwing ideas out there. I suspect that
> > in the general case it may not be easy to map from wake event
> > to device, without infrastructure that's now missing.
>
> FWIW, I've recently added code to Suspend2 to allow it to (optionally) set the
> RTC wake alarm when it's finished writing the image and check the lid switch
> when waking, entering a different sleep state if the lid switch is still
> closed. It achieves this by letting the user set the name of an rtc alarm to
> use (the 'rtc0' in /sys/class/rtc/rtc0/*) and of a button to use (lid/LID
> in /proc/acpi/button/lid/LID/*). It then opens the button directory's state
> file and the rtc directory's since_epoch and wakealarm files, and uses them
> to determine read the time since epoch and set the wakealarm and determine
> whether the lid button is still closed.
Interesting...
> I don't really like the opening /proc and /sysfs files in this way - whatever
> solution you come up with, could you consider exposing some way for kernel
> code to do this more neatly?
You're supposed to be able to use /sys/... files this way!
But that's not true of /proc/... files.
- Dave
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [linux-pm] Re: Hibernate after alarm wakes from STR
2007-07-10 2:45 ` [linux-pm] " Nigel Cunningham
2007-07-10 16:51 ` David Brownell
@ 2007-07-10 16:51 ` David Brownell
2007-07-10 22:16 ` Nigel Cunningham
2007-07-10 22:16 ` [linux-pm] " Nigel Cunningham
1 sibling, 2 replies; 126+ messages in thread
From: David Brownell @ 2007-07-10 16:51 UTC (permalink / raw)
To: nigel; +Cc: linux-pm, Marcelo Tosatti, linux-acpi, Richard Hughes, rtc-linux
On Monday 09 July 2007, Nigel Cunningham wrote:
> Hi.
>
> On Tuesday 10 July 2007 02:26:32 David Brownell wrote:
> > On Monday 09 July 2007, Marcelo Tosatti wrote:
> > > On Sun, Jul 08, 2007 at 07:44:03PM -0700, David Brownell wrote:
> >
> > > > Better a /sys/power/wakeup_event (or whatever) that's more easily
> > > > found. It could link to the device issuing the event.
> > >
> > > As you mentioned, there might be two wakeup sources (RTC and power
> > > button for instance) or even more at the same time.
> >
> > Actually I though I said that there would be races. Though come
> > to think of it, one way they'd show up on a typical embedded system
> > would be to have multiple wake IRQs pending ... you couldn't tell
> > which one came first. (The typical case would be a single event,
> > of course.) ACPI-ish systems would do that with GPEs and the
> > magic "rtc woke" flag.
> >
> > And then there are shared IRQ lines serving as wake sources. There
> > could be three wake-enabled devices on that line (plus others that
> > aren't wake-enabled); the drivers returning IRQ_HANDLED should likely
> > be reported as having been wake sources, but not the ones returning
> > IRQ_NONE ...
> >
> > ... so yes, systems might need to present multiple wake events.
> >
> >
> > > Do you think its fine to simply but the device separated by spaces in
> > > the wakeup_event file?
> > >
> > > Sounds fine by me, but what about the one-value-per-file sysfs rule?
> >
> > Better to have that node be a directory of links then, rather than
> > a single link.
> >
> > Note that I'm just throwing ideas out there. I suspect that
> > in the general case it may not be easy to map from wake event
> > to device, without infrastructure that's now missing.
>
> FWIW, I've recently added code to Suspend2 to allow it to (optionally) set the
> RTC wake alarm when it's finished writing the image and check the lid switch
> when waking, entering a different sleep state if the lid switch is still
> closed. It achieves this by letting the user set the name of an rtc alarm to
> use (the 'rtc0' in /sys/class/rtc/rtc0/*) and of a button to use (lid/LID
> in /proc/acpi/button/lid/LID/*). It then opens the button directory's state
> file and the rtc directory's since_epoch and wakealarm files, and uses them
> to determine read the time since epoch and set the wakealarm and determine
> whether the lid button is still closed.
Interesting...
> I don't really like the opening /proc and /sysfs files in this way - whatever
> solution you come up with, could you consider exposing some way for kernel
> code to do this more neatly?
You're supposed to be able to use /sys/... files this way!
But that's not true of /proc/... files.
- Dave
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Re: Hibernate after alarm wakes from STR
2007-07-10 16:51 ` [linux-pm] " David Brownell
@ 2007-07-10 22:16 ` Nigel Cunningham
2007-07-10 22:16 ` [linux-pm] " Nigel Cunningham
1 sibling, 0 replies; 126+ messages in thread
From: Nigel Cunningham @ 2007-07-10 22:16 UTC (permalink / raw)
To: David Brownell; +Cc: rtc-linux, linux-acpi, nigel, Richard Hughes, linux-pm
[-- Attachment #1.1: Type: text/plain, Size: 3529 bytes --]
Hi.
On Wednesday 11 July 2007 02:51:03 David Brownell wrote:
> On Monday 09 July 2007, Nigel Cunningham wrote:
> > Hi.
> >
> > On Tuesday 10 July 2007 02:26:32 David Brownell wrote:
> > > On Monday 09 July 2007, Marcelo Tosatti wrote:
> > > > On Sun, Jul 08, 2007 at 07:44:03PM -0700, David Brownell wrote:
> > >
> > > > > Better a /sys/power/wakeup_event (or whatever) that's more easily
> > > > > found. It could link to the device issuing the event.
> > > >
> > > > As you mentioned, there might be two wakeup sources (RTC and power
> > > > button for instance) or even more at the same time.
> > >
> > > Actually I though I said that there would be races. Though come
> > > to think of it, one way they'd show up on a typical embedded system
> > > would be to have multiple wake IRQs pending ... you couldn't tell
> > > which one came first. (The typical case would be a single event,
> > > of course.) ACPI-ish systems would do that with GPEs and the
> > > magic "rtc woke" flag.
> > >
> > > And then there are shared IRQ lines serving as wake sources. There
> > > could be three wake-enabled devices on that line (plus others that
> > > aren't wake-enabled); the drivers returning IRQ_HANDLED should likely
> > > be reported as having been wake sources, but not the ones returning
> > > IRQ_NONE ...
> > >
> > > ... so yes, systems might need to present multiple wake events.
> > >
> > >
> > > > Do you think its fine to simply but the device separated by spaces in
> > > > the wakeup_event file?
> > > >
> > > > Sounds fine by me, but what about the one-value-per-file sysfs rule?
> > >
> > > Better to have that node be a directory of links then, rather than
> > > a single link.
> > >
> > > Note that I'm just throwing ideas out there. I suspect that
> > > in the general case it may not be easy to map from wake event
> > > to device, without infrastructure that's now missing.
> >
> > FWIW, I've recently added code to Suspend2 to allow it to (optionally) set
the
> > RTC wake alarm when it's finished writing the image and check the lid
switch
> > when waking, entering a different sleep state if the lid switch is still
> > closed. It achieves this by letting the user set the name of an rtc alarm
to
> > use (the 'rtc0' in /sys/class/rtc/rtc0/*) and of a button to use (lid/LID
> > in /proc/acpi/button/lid/LID/*). It then opens the button directory's
state
> > file and the rtc directory's since_epoch and wakealarm files, and uses
them
> > to determine read the time since epoch and set the wakealarm and determine
> > whether the lid button is still closed.
>
> Interesting...
>
> > I don't really like the opening /proc and /sysfs files in this way -
whatever
> > solution you come up with, could you consider exposing some way for kernel
> > code to do this more neatly?
>
> You're supposed to be able to use /sys/... files this way!
>
> But that's not true of /proc/... files.
Yeah, the bit I consider to be ugly is opening the files from within the
kernel, but it seemed to be necessary in order to provide the functionality
without having to rely on userspace or do some sort of messy work to figure
out how to access the lid button and so on.
Re proc files, are the button files already exposed under sysfs and I just
don't know? If so, I'll happily shift to using them.
Regards,
Nigel
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [linux-pm] Re: Hibernate after alarm wakes from STR
2007-07-10 16:51 ` [linux-pm] " David Brownell
2007-07-10 22:16 ` Nigel Cunningham
@ 2007-07-10 22:16 ` Nigel Cunningham
2007-07-11 0:45 ` Matthew Garrett
` (3 more replies)
1 sibling, 4 replies; 126+ messages in thread
From: Nigel Cunningham @ 2007-07-10 22:16 UTC (permalink / raw)
To: David Brownell
Cc: nigel, linux-pm, Marcelo Tosatti, linux-acpi, Richard Hughes, rtc-linux
[-- Attachment #1: Type: text/plain, Size: 3529 bytes --]
Hi.
On Wednesday 11 July 2007 02:51:03 David Brownell wrote:
> On Monday 09 July 2007, Nigel Cunningham wrote:
> > Hi.
> >
> > On Tuesday 10 July 2007 02:26:32 David Brownell wrote:
> > > On Monday 09 July 2007, Marcelo Tosatti wrote:
> > > > On Sun, Jul 08, 2007 at 07:44:03PM -0700, David Brownell wrote:
> > >
> > > > > Better a /sys/power/wakeup_event (or whatever) that's more easily
> > > > > found. It could link to the device issuing the event.
> > > >
> > > > As you mentioned, there might be two wakeup sources (RTC and power
> > > > button for instance) or even more at the same time.
> > >
> > > Actually I though I said that there would be races. Though come
> > > to think of it, one way they'd show up on a typical embedded system
> > > would be to have multiple wake IRQs pending ... you couldn't tell
> > > which one came first. (The typical case would be a single event,
> > > of course.) ACPI-ish systems would do that with GPEs and the
> > > magic "rtc woke" flag.
> > >
> > > And then there are shared IRQ lines serving as wake sources. There
> > > could be three wake-enabled devices on that line (plus others that
> > > aren't wake-enabled); the drivers returning IRQ_HANDLED should likely
> > > be reported as having been wake sources, but not the ones returning
> > > IRQ_NONE ...
> > >
> > > ... so yes, systems might need to present multiple wake events.
> > >
> > >
> > > > Do you think its fine to simply but the device separated by spaces in
> > > > the wakeup_event file?
> > > >
> > > > Sounds fine by me, but what about the one-value-per-file sysfs rule?
> > >
> > > Better to have that node be a directory of links then, rather than
> > > a single link.
> > >
> > > Note that I'm just throwing ideas out there. I suspect that
> > > in the general case it may not be easy to map from wake event
> > > to device, without infrastructure that's now missing.
> >
> > FWIW, I've recently added code to Suspend2 to allow it to (optionally) set
the
> > RTC wake alarm when it's finished writing the image and check the lid
switch
> > when waking, entering a different sleep state if the lid switch is still
> > closed. It achieves this by letting the user set the name of an rtc alarm
to
> > use (the 'rtc0' in /sys/class/rtc/rtc0/*) and of a button to use (lid/LID
> > in /proc/acpi/button/lid/LID/*). It then opens the button directory's
state
> > file and the rtc directory's since_epoch and wakealarm files, and uses
them
> > to determine read the time since epoch and set the wakealarm and determine
> > whether the lid button is still closed.
>
> Interesting...
>
> > I don't really like the opening /proc and /sysfs files in this way -
whatever
> > solution you come up with, could you consider exposing some way for kernel
> > code to do this more neatly?
>
> You're supposed to be able to use /sys/... files this way!
>
> But that's not true of /proc/... files.
Yeah, the bit I consider to be ugly is opening the files from within the
kernel, but it seemed to be necessary in order to provide the functionality
without having to rely on userspace or do some sort of messy work to figure
out how to access the lid button and so on.
Re proc files, are the button files already exposed under sysfs and I just
don't know? If so, I'll happily shift to using them.
Regards,
Nigel
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: [linux-pm] Re: Hibernate after alarm wakes from STR
2007-07-10 22:16 ` [linux-pm] " Nigel Cunningham
@ 2007-07-11 0:45 ` Matthew Garrett
2007-07-11 0:53 ` Nigel Cunningham
2007-07-11 0:53 ` Nigel Cunningham
2007-07-11 0:45 ` Matthew Garrett
` (2 subsequent siblings)
3 siblings, 2 replies; 126+ messages in thread
From: Matthew Garrett @ 2007-07-11 0:45 UTC (permalink / raw)
To: nigel
Cc: David Brownell, linux-pm, Marcelo Tosatti, linux-acpi,
Richard Hughes, rtc-linux
On Wed, Jul 11, 2007 at 08:16:40AM +1000, Nigel Cunningham wrote:
> Yeah, the bit I consider to be ugly is opening the files from within the
> kernel, but it seemed to be necessary in order to provide the functionality
> without having to rely on userspace or do some sort of messy work to figure
> out how to access the lid button and so on.
How are you going to shift into suspend to disk without going via
userspace? It's quite plausible that people will want different
configuration at that point (or, realistically, need a different set of
workarounds...)
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: [linux-pm] Re: Hibernate after alarm wakes from STR
2007-07-11 0:45 ` Matthew Garrett
@ 2007-07-11 0:53 ` Nigel Cunningham
2007-07-11 1:23 ` Matthew Garrett
2007-07-11 1:23 ` Matthew Garrett
2007-07-11 0:53 ` Nigel Cunningham
1 sibling, 2 replies; 126+ messages in thread
From: Nigel Cunningham @ 2007-07-11 0:53 UTC (permalink / raw)
To: Matthew Garrett
Cc: nigel, David Brownell, linux-pm, Marcelo Tosatti, linux-acpi,
Richard Hughes, rtc-linux
[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]
Hi.
On Wednesday 11 July 2007 10:45:50 Matthew Garrett wrote:
> On Wed, Jul 11, 2007 at 08:16:40AM +1000, Nigel Cunningham wrote:
> > Yeah, the bit I consider to be ugly is opening the files from within the
> > kernel, but it seemed to be necessary in order to provide the
functionality
> > without having to rely on userspace or do some sort of messy work to
figure
> > out how to access the lid button and so on.
>
> How are you going to shift into suspend to disk without going via
> userspace? It's quite plausible that people will want different
> configuration at that point (or, realistically, need a different set of
> workarounds...)
This is done after writing the image, from kernel space. We do the
suspend-to-ram, and if/when we wake from that, we look at the lid switch
state before removing the image. If it's still closed, the kernel code powers
down again (this time properly) without userspace ever seeing the light of
day.
Regards,
Nigel
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [linux-pm] Re: Hibernate after alarm wakes from STR
2007-07-11 0:53 ` Nigel Cunningham
@ 2007-07-11 1:23 ` Matthew Garrett
2007-07-11 1:39 ` Nigel Cunningham
2007-07-11 1:39 ` [linux-pm] " Nigel Cunningham
2007-07-11 1:23 ` Matthew Garrett
1 sibling, 2 replies; 126+ messages in thread
From: Matthew Garrett @ 2007-07-11 1:23 UTC (permalink / raw)
To: nigel
Cc: David Brownell, linux-pm, Marcelo Tosatti, linux-acpi,
Richard Hughes, rtc-linux
On Wed, Jul 11, 2007 at 10:53:35AM +1000, Nigel Cunningham wrote:
> On Wednesday 11 July 2007 10:45:50 Matthew Garrett wrote:
> > How are you going to shift into suspend to disk without going via
> > userspace? It's quite plausible that people will want different
> > configuration at that point (or, realistically, need a different set of
> > workarounds...)
>
> This is done after writing the image, from kernel space. We do the
> suspend-to-ram, and if/when we wake from that, we look at the lid switch
> state before removing the image. If it's still closed, the kernel code powers
> down again (this time properly) without userspace ever seeing the light of
> day.
Yes. I'm sort of struggling to see how this is done especially reliably
- if we have separate hibernation and suspend to ram pathways, which is
executed in this scenario?
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Re: Hibernate after alarm wakes from STR
2007-07-11 1:23 ` Matthew Garrett
@ 2007-07-11 1:39 ` Nigel Cunningham
2007-07-11 1:39 ` [linux-pm] " Nigel Cunningham
1 sibling, 0 replies; 126+ messages in thread
From: Nigel Cunningham @ 2007-07-11 1:39 UTC (permalink / raw)
To: Matthew Garrett; +Cc: rtc-linux, linux-acpi, nigel, Richard Hughes, linux-pm
[-- Attachment #1.1: Type: text/plain, Size: 1886 bytes --]
Hi.
On Wednesday 11 July 2007 11:23:02 Matthew Garrett wrote:
> On Wed, Jul 11, 2007 at 10:53:35AM +1000, Nigel Cunningham wrote:
> > On Wednesday 11 July 2007 10:45:50 Matthew Garrett wrote:
> > > How are you going to shift into suspend to disk without going via
> > > userspace? It's quite plausible that people will want different
> > > configuration at that point (or, realistically, need a different set of
> > > workarounds...)
> >
> > This is done after writing the image, from kernel space. We do the
> > suspend-to-ram, and if/when we wake from that, we look at the lid switch
> > state before removing the image. If it's still closed, the kernel code
powers
> > down again (this time properly) without userspace ever seeing the light of
> > day.
>
> Yes. I'm sort of struggling to see how this is done especially reliably
> - if we have separate hibernation and suspend to ram pathways, which is
> executed in this scenario?
Yeah, that is a bit confusing. At the moment, I'm doing the suspend to ram
platform dependent preparation and cleanup in this scenario. That's
definitely the right thing to do in the case where we write an image, then
suspend to ram, wake and continue working without running running out of
battery (writing the image is redundant in that case). Where we end up
properly powering down after suspending to ram, I believe we don't run the
pm_ops->finish after doing the atomic restore when resuming the image.
I haven't looked at what uswsusp does (I'm just looking at Suspend2 code
above), but it will have similar issues as it also has support for suspending
to ram after writing an image.
Regards,
Nigel
--
Nigel Cunningham
Christian Reformed Church of Cobden
103 Curdie Street, Cobden 3266, Victoria, Australia
Ph. +61 3 5595 1185 / +61 417 100 574
Communal Worship: 11 am Sunday.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [linux-pm] Re: Hibernate after alarm wakes from STR
2007-07-11 1:23 ` Matthew Garrett
2007-07-11 1:39 ` Nigel Cunningham
@ 2007-07-11 1:39 ` Nigel Cunningham
2007-07-11 1:59 ` Matthew Garrett
2007-07-11 1:59 ` [linux-pm] " Matthew Garrett
1 sibling, 2 replies; 126+ messages in thread
From: Nigel Cunningham @ 2007-07-11 1:39 UTC (permalink / raw)
To: Matthew Garrett
Cc: nigel, David Brownell, linux-pm, Marcelo Tosatti, linux-acpi,
Richard Hughes, rtc-linux
[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]
Hi.
On Wednesday 11 July 2007 11:23:02 Matthew Garrett wrote:
> On Wed, Jul 11, 2007 at 10:53:35AM +1000, Nigel Cunningham wrote:
> > On Wednesday 11 July 2007 10:45:50 Matthew Garrett wrote:
> > > How are you going to shift into suspend to disk without going via
> > > userspace? It's quite plausible that people will want different
> > > configuration at that point (or, realistically, need a different set of
> > > workarounds...)
> >
> > This is done after writing the image, from kernel space. We do the
> > suspend-to-ram, and if/when we wake from that, we look at the lid switch
> > state before removing the image. If it's still closed, the kernel code
powers
> > down again (this time properly) without userspace ever seeing the light of
> > day.
>
> Yes. I'm sort of struggling to see how this is done especially reliably
> - if we have separate hibernation and suspend to ram pathways, which is
> executed in this scenario?
Yeah, that is a bit confusing. At the moment, I'm doing the suspend to ram
platform dependent preparation and cleanup in this scenario. That's
definitely the right thing to do in the case where we write an image, then
suspend to ram, wake and continue working without running running out of
battery (writing the image is redundant in that case). Where we end up
properly powering down after suspending to ram, I believe we don't run the
pm_ops->finish after doing the atomic restore when resuming the image.
I haven't looked at what uswsusp does (I'm just looking at Suspend2 code
above), but it will have similar issues as it also has support for suspending
to ram after writing an image.
Regards,
Nigel
--
Nigel Cunningham
Christian Reformed Church of Cobden
103 Curdie Street, Cobden 3266, Victoria, Australia
Ph. +61 3 5595 1185 / +61 417 100 574
Communal Worship: 11 am Sunday.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Re: Hibernate after alarm wakes from STR
2007-07-11 1:39 ` [linux-pm] " Nigel Cunningham
@ 2007-07-11 1:59 ` Matthew Garrett
2007-07-11 1:59 ` [linux-pm] " Matthew Garrett
1 sibling, 0 replies; 126+ messages in thread
From: Matthew Garrett @ 2007-07-11 1:59 UTC (permalink / raw)
To: Nigel Cunningham; +Cc: rtc-linux, linux-acpi, nigel, Richard Hughes, linux-pm
On Wed, Jul 11, 2007 at 11:39:37AM +1000, Nigel Cunningham wrote:
> Yeah, that is a bit confusing. At the moment, I'm doing the suspend to ram
> platform dependent preparation and cleanup in this scenario. That's
> definitely the right thing to do in the case where we write an image, then
> suspend to ram, wake and continue working without running running out of
> battery (writing the image is redundant in that case). Where we end up
> properly powering down after suspending to ram, I believe we don't run the
> pm_ops->finish after doing the atomic restore when resuming the image.
I'm not convinced this can work terribly well. It's not unlikely that
hardware will need different state stored over different types of
suspend. Can you separate out the saving of kernel memory and userspace
memory, then resume/suspend/save the new kernel state without touching
the userspace state?
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [linux-pm] Re: Hibernate after alarm wakes from STR
2007-07-11 1:39 ` [linux-pm] " Nigel Cunningham
2007-07-11 1:59 ` Matthew Garrett
@ 2007-07-11 1:59 ` Matthew Garrett
2007-07-11 3:14 ` Nigel Cunningham
2007-07-11 3:14 ` Nigel Cunningham
1 sibling, 2 replies; 126+ messages in thread
From: Matthew Garrett @ 2007-07-11 1:59 UTC (permalink / raw)
To: Nigel Cunningham
Cc: nigel, David Brownell, linux-pm, Marcelo Tosatti, linux-acpi,
Richard Hughes, rtc-linux
On Wed, Jul 11, 2007 at 11:39:37AM +1000, Nigel Cunningham wrote:
> Yeah, that is a bit confusing. At the moment, I'm doing the suspend to ram
> platform dependent preparation and cleanup in this scenario. That's
> definitely the right thing to do in the case where we write an image, then
> suspend to ram, wake and continue working without running running out of
> battery (writing the image is redundant in that case). Where we end up
> properly powering down after suspending to ram, I believe we don't run the
> pm_ops->finish after doing the atomic restore when resuming the image.
I'm not convinced this can work terribly well. It's not unlikely that
hardware will need different state stored over different types of
suspend. Can you separate out the saving of kernel memory and userspace
memory, then resume/suspend/save the new kernel state without touching
the userspace state?
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [linux-pm] Re: Hibernate after alarm wakes from STR
2007-07-11 1:59 ` [linux-pm] " Matthew Garrett
@ 2007-07-11 3:14 ` Nigel Cunningham
2007-07-11 10:09 ` Rafael J. Wysocki
2007-07-11 10:09 ` [linux-pm] " Rafael J. Wysocki
2007-07-11 3:14 ` Nigel Cunningham
1 sibling, 2 replies; 126+ messages in thread
From: Nigel Cunningham @ 2007-07-11 3:14 UTC (permalink / raw)
To: Matthew Garrett
Cc: nigel, David Brownell, linux-pm, Marcelo Tosatti, linux-acpi,
Richard Hughes, rtc-linux
[-- Attachment #1: Type: text/plain, Size: 2455 bytes --]
Hi.
On Wednesday 11 July 2007 11:59:48 Matthew Garrett wrote:
> On Wed, Jul 11, 2007 at 11:39:37AM +1000, Nigel Cunningham wrote:
>
> > Yeah, that is a bit confusing. At the moment, I'm doing the suspend to ram
> > platform dependent preparation and cleanup in this scenario. That's
> > definitely the right thing to do in the case where we write an image, then
> > suspend to ram, wake and continue working without running running out of
> > battery (writing the image is redundant in that case). Where we end up
> > properly powering down after suspending to ram, I believe we don't run the
> > pm_ops->finish after doing the atomic restore when resuming the image.
>
> I'm not convinced this can work terribly well. It's not unlikely that
> hardware will need different state stored over different types of
> suspend. Can you separate out the saving of kernel memory and userspace
> memory, then resume/suspend/save the new kernel state without touching
> the userspace state?
Yeah, we could redo and resave the atomic copy, but it doesn't seem to be
necessary at the moment; it has been working reliably, regardless of which
combination of events occurs. If/when I come across a case where we have
problems, I'll give resaving the atomic copy a go.
(Thinks some more). Ah, I think we're already doing the right thing, if I'm
recalling the order of actions right. If I'm remembering correctly, prior to
the atomic copy, we do hibernation prep, then after the atomic copy,
hibernation cleanup. Then, if suspending to ram, we do the prep/enter/cleanup
after the image has finished writing. If we lose power from suspend to ram,
it doesn't matter because we're just doing a normal resume then, with the
hibernation cleanup post atomic restore machine the prep that was done prior
to the atomic copy.
To summarise:
Hibernate + STR + full wake.
Hibernation prep
(Atomic copy)
Hibernation cleanup
STR prep
STR enter
STR cleanup
Remove hibernation image
Hibernate + STR + poweroff + hibernate resume:
Hibernation prep
(Atomic copy)
Hibernation cleanup
STR prep
STR enter
<power out> or <STR wake + power off> (STR prep/enter no longer matters)
(Fresh boot)
Atomic restore
Hibernation cleanup (matching prep at start)
Remove hibernation image
Regards,
Nigel
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Re: Hibernate after alarm wakes from STR
2007-07-11 3:14 ` Nigel Cunningham
@ 2007-07-11 10:09 ` Rafael J. Wysocki
2007-07-11 10:09 ` [linux-pm] " Rafael J. Wysocki
1 sibling, 0 replies; 126+ messages in thread
From: Rafael J. Wysocki @ 2007-07-11 10:09 UTC (permalink / raw)
To: nigel; +Cc: Matthew Garrett, rtc-linux, Richard Hughes, linux-acpi, linux-pm
Hi,
On Wednesday, 11 July 2007 05:14, Nigel Cunningham wrote:
> Hi.
>
> On Wednesday 11 July 2007 11:59:48 Matthew Garrett wrote:
> > On Wed, Jul 11, 2007 at 11:39:37AM +1000, Nigel Cunningham wrote:
> >
> > > Yeah, that is a bit confusing. At the moment, I'm doing the suspend to ram
> > > platform dependent preparation and cleanup in this scenario. That's
> > > definitely the right thing to do in the case where we write an image, then
> > > suspend to ram, wake and continue working without running running out of
> > > battery (writing the image is redundant in that case). Where we end up
> > > properly powering down after suspending to ram, I believe we don't run the
> > > pm_ops->finish after doing the atomic restore when resuming the image.
> >
> > I'm not convinced this can work terribly well. It's not unlikely that
> > hardware will need different state stored over different types of
> > suspend. Can you separate out the saving of kernel memory and userspace
> > memory, then resume/suspend/save the new kernel state without touching
> > the userspace state?
>
> Yeah, we could redo and resave the atomic copy, but it doesn't seem to be
> necessary at the moment; it has been working reliably, regardless of which
> combination of events occurs. If/when I come across a case where we have
> problems, I'll give resaving the atomic copy a go.
>
> (Thinks some more). Ah, I think we're already doing the right thing, if I'm
> recalling the order of actions right. If I'm remembering correctly, prior to
> the atomic copy, we do hibernation prep, then after the atomic copy,
> hibernation cleanup. Then, if suspending to ram, we do the prep/enter/cleanup
> after the image has finished writing. If we lose power from suspend to ram,
> it doesn't matter because we're just doing a normal resume then, with the
> hibernation cleanup post atomic restore machine the prep that was done prior
> to the atomic copy.
>
> To summarise:
>
> Hibernate + STR + full wake.
> Hibernation prep
> (Atomic copy)
> Hibernation cleanup
> STR prep
> STR enter
> STR cleanup
> Remove hibernation image
>
> Hibernate + STR + poweroff + hibernate resume:
>
> Hibernation prep
> (Atomic copy)
> Hibernation cleanup
> STR prep
> STR enter
> <power out> or <STR wake + power off> (STR prep/enter no longer matters)
> (Fresh boot)
> Atomic restore
> Hibernation cleanup (matching prep at start)
> Remove hibernation image
Yes, I think that this is the right ordering, but for some graphics adapters
we need to do some tricks from the user space before 'STR prep' and after
'STR cleanup', which is theoretically possible with uswsusp.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [linux-pm] Re: Hibernate after alarm wakes from STR
2007-07-11 3:14 ` Nigel Cunningham
2007-07-11 10:09 ` Rafael J. Wysocki
@ 2007-07-11 10:09 ` Rafael J. Wysocki
2007-07-11 10:14 ` Nigel Cunningham
2007-07-11 10:14 ` [linux-pm] " Nigel Cunningham
1 sibling, 2 replies; 126+ messages in thread
From: Rafael J. Wysocki @ 2007-07-11 10:09 UTC (permalink / raw)
To: nigel
Cc: Matthew Garrett, David Brownell, linux-pm, Marcelo Tosatti,
linux-acpi, Richard Hughes, rtc-linux
Hi,
On Wednesday, 11 July 2007 05:14, Nigel Cunningham wrote:
> Hi.
>
> On Wednesday 11 July 2007 11:59:48 Matthew Garrett wrote:
> > On Wed, Jul 11, 2007 at 11:39:37AM +1000, Nigel Cunningham wrote:
> >
> > > Yeah, that is a bit confusing. At the moment, I'm doing the suspend to ram
> > > platform dependent preparation and cleanup in this scenario. That's
> > > definitely the right thing to do in the case where we write an image, then
> > > suspend to ram, wake and continue working without running running out of
> > > battery (writing the image is redundant in that case). Where we end up
> > > properly powering down after suspending to ram, I believe we don't run the
> > > pm_ops->finish after doing the atomic restore when resuming the image.
> >
> > I'm not convinced this can work terribly well. It's not unlikely that
> > hardware will need different state stored over different types of
> > suspend. Can you separate out the saving of kernel memory and userspace
> > memory, then resume/suspend/save the new kernel state without touching
> > the userspace state?
>
> Yeah, we could redo and resave the atomic copy, but it doesn't seem to be
> necessary at the moment; it has been working reliably, regardless of which
> combination of events occurs. If/when I come across a case where we have
> problems, I'll give resaving the atomic copy a go.
>
> (Thinks some more). Ah, I think we're already doing the right thing, if I'm
> recalling the order of actions right. If I'm remembering correctly, prior to
> the atomic copy, we do hibernation prep, then after the atomic copy,
> hibernation cleanup. Then, if suspending to ram, we do the prep/enter/cleanup
> after the image has finished writing. If we lose power from suspend to ram,
> it doesn't matter because we're just doing a normal resume then, with the
> hibernation cleanup post atomic restore machine the prep that was done prior
> to the atomic copy.
>
> To summarise:
>
> Hibernate + STR + full wake.
> Hibernation prep
> (Atomic copy)
> Hibernation cleanup
> STR prep
> STR enter
> STR cleanup
> Remove hibernation image
>
> Hibernate + STR + poweroff + hibernate resume:
>
> Hibernation prep
> (Atomic copy)
> Hibernation cleanup
> STR prep
> STR enter
> <power out> or <STR wake + power off> (STR prep/enter no longer matters)
> (Fresh boot)
> Atomic restore
> Hibernation cleanup (matching prep at start)
> Remove hibernation image
Yes, I think that this is the right ordering, but for some graphics adapters
we need to do some tricks from the user space before 'STR prep' and after
'STR cleanup', which is theoretically possible with uswsusp.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Re: Hibernate after alarm wakes from STR
2007-07-11 10:09 ` [linux-pm] " Rafael J. Wysocki
@ 2007-07-11 10:14 ` Nigel Cunningham
2007-07-11 10:14 ` [linux-pm] " Nigel Cunningham
1 sibling, 0 replies; 126+ messages in thread
From: Nigel Cunningham @ 2007-07-11 10:14 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Matthew Garrett, rtc-linux, linux-acpi, nigel, Richard Hughes, linux-pm
[-- Attachment #1.1: Type: text/plain, Size: 3204 bytes --]
Hi.
On Wednesday 11 July 2007 20:09:04 Rafael J. Wysocki wrote:
> On Wednesday, 11 July 2007 05:14, Nigel Cunningham wrote:
> > On Wednesday 11 July 2007 11:59:48 Matthew Garrett wrote:
> > > On Wed, Jul 11, 2007 at 11:39:37AM +1000, Nigel Cunningham wrote:
> > >
> > > > Yeah, that is a bit confusing. At the moment, I'm doing the suspend to
ram
> > > > platform dependent preparation and cleanup in this scenario. That's
> > > > definitely the right thing to do in the case where we write an image,
then
> > > > suspend to ram, wake and continue working without running running out
of
> > > > battery (writing the image is redundant in that case). Where we end up
> > > > properly powering down after suspending to ram, I believe we don't run
the
> > > > pm_ops->finish after doing the atomic restore when resuming the image.
> > >
> > > I'm not convinced this can work terribly well. It's not unlikely that
> > > hardware will need different state stored over different types of
> > > suspend. Can you separate out the saving of kernel memory and userspace
> > > memory, then resume/suspend/save the new kernel state without touching
> > > the userspace state?
> >
> > Yeah, we could redo and resave the atomic copy, but it doesn't seem to be
> > necessary at the moment; it has been working reliably, regardless of which
> > combination of events occurs. If/when I come across a case where we have
> > problems, I'll give resaving the atomic copy a go.
> >
> > (Thinks some more). Ah, I think we're already doing the right thing, if
I'm
> > recalling the order of actions right. If I'm remembering correctly, prior
to
> > the atomic copy, we do hibernation prep, then after the atomic copy,
> > hibernation cleanup. Then, if suspending to ram, we do the
prep/enter/cleanup
> > after the image has finished writing. If we lose power from suspend to
ram,
> > it doesn't matter because we're just doing a normal resume then, with the
> > hibernation cleanup post atomic restore machine the prep that was done
prior
> > to the atomic copy.
> >
> > To summarise:
> >
> > Hibernate + STR + full wake.
> > Hibernation prep
> > (Atomic copy)
> > Hibernation cleanup
> > STR prep
> > STR enter
> > STR cleanup
> > Remove hibernation image
> >
> > Hibernate + STR + poweroff + hibernate resume:
> >
> > Hibernation prep
> > (Atomic copy)
> > Hibernation cleanup
> > STR prep
> > STR enter
> > <power out> or <STR wake + power off> (STR prep/enter no longer matters)
> > (Fresh boot)
> > Atomic restore
> > Hibernation cleanup (matching prep at start)
> > Remove hibernation image
>
> Yes, I think that this is the right ordering, but for some graphics adapters
> we need to do some tricks from the user space before 'STR prep' and after
> 'STR cleanup', which is theoretically possible with uswsusp.
Yeah. I haven't done it yet, but intend to implement that using userui.
Regards,
Nigel
--
Nigel Cunningham
Christian Reformed Church of Cobden
103 Curdie Street, Cobden 3266, Victoria, Australia
Ph. +61 3 5595 1185 / +61 417 100 574
Communal Worship: 11 am Sunday.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [linux-pm] Re: Hibernate after alarm wakes from STR
2007-07-11 10:09 ` [linux-pm] " Rafael J. Wysocki
2007-07-11 10:14 ` Nigel Cunningham
@ 2007-07-11 10:14 ` Nigel Cunningham
2007-07-11 10:31 ` Rafael J. Wysocki
2007-07-11 10:31 ` Rafael J. Wysocki
1 sibling, 2 replies; 126+ messages in thread
From: Nigel Cunningham @ 2007-07-11 10:14 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: nigel, Matthew Garrett, David Brownell, linux-pm,
Marcelo Tosatti, linux-acpi, Richard Hughes, rtc-linux
[-- Attachment #1: Type: text/plain, Size: 3204 bytes --]
Hi.
On Wednesday 11 July 2007 20:09:04 Rafael J. Wysocki wrote:
> On Wednesday, 11 July 2007 05:14, Nigel Cunningham wrote:
> > On Wednesday 11 July 2007 11:59:48 Matthew Garrett wrote:
> > > On Wed, Jul 11, 2007 at 11:39:37AM +1000, Nigel Cunningham wrote:
> > >
> > > > Yeah, that is a bit confusing. At the moment, I'm doing the suspend to
ram
> > > > platform dependent preparation and cleanup in this scenario. That's
> > > > definitely the right thing to do in the case where we write an image,
then
> > > > suspend to ram, wake and continue working without running running out
of
> > > > battery (writing the image is redundant in that case). Where we end up
> > > > properly powering down after suspending to ram, I believe we don't run
the
> > > > pm_ops->finish after doing the atomic restore when resuming the image.
> > >
> > > I'm not convinced this can work terribly well. It's not unlikely that
> > > hardware will need different state stored over different types of
> > > suspend. Can you separate out the saving of kernel memory and userspace
> > > memory, then resume/suspend/save the new kernel state without touching
> > > the userspace state?
> >
> > Yeah, we could redo and resave the atomic copy, but it doesn't seem to be
> > necessary at the moment; it has been working reliably, regardless of which
> > combination of events occurs. If/when I come across a case where we have
> > problems, I'll give resaving the atomic copy a go.
> >
> > (Thinks some more). Ah, I think we're already doing the right thing, if
I'm
> > recalling the order of actions right. If I'm remembering correctly, prior
to
> > the atomic copy, we do hibernation prep, then after the atomic copy,
> > hibernation cleanup. Then, if suspending to ram, we do the
prep/enter/cleanup
> > after the image has finished writing. If we lose power from suspend to
ram,
> > it doesn't matter because we're just doing a normal resume then, with the
> > hibernation cleanup post atomic restore machine the prep that was done
prior
> > to the atomic copy.
> >
> > To summarise:
> >
> > Hibernate + STR + full wake.
> > Hibernation prep
> > (Atomic copy)
> > Hibernation cleanup
> > STR prep
> > STR enter
> > STR cleanup
> > Remove hibernation image
> >
> > Hibernate + STR + poweroff + hibernate resume:
> >
> > Hibernation prep
> > (Atomic copy)
> > Hibernation cleanup
> > STR prep
> > STR enter
> > <power out> or <STR wake + power off> (STR prep/enter no longer matters)
> > (Fresh boot)
> > Atomic restore
> > Hibernation cleanup (matching prep at start)
> > Remove hibernation image
>
> Yes, I think that this is the right ordering, but for some graphics adapters
> we need to do some tricks from the user space before 'STR prep' and after
> 'STR cleanup', which is theoretically possible with uswsusp.
Yeah. I haven't done it yet, but intend to implement that using userui.
Regards,
Nigel
--
Nigel Cunningham
Christian Reformed Church of Cobden
103 Curdie Street, Cobden 3266, Victoria, Australia
Ph. +61 3 5595 1185 / +61 417 100 574
Communal Worship: 11 am Sunday.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [linux-pm] Re: Hibernate after alarm wakes from STR
2007-07-11 10:14 ` [linux-pm] " Nigel Cunningham
@ 2007-07-11 10:31 ` Rafael J. Wysocki
2007-07-11 10:31 ` Rafael J. Wysocki
1 sibling, 0 replies; 126+ messages in thread
From: Rafael J. Wysocki @ 2007-07-11 10:31 UTC (permalink / raw)
To: Nigel Cunningham
Cc: nigel, Matthew Garrett, David Brownell, linux-pm,
Marcelo Tosatti, linux-acpi, Richard Hughes, rtc-linux
On Wednesday, 11 July 2007 12:14, Nigel Cunningham wrote:
> Hi.
>
> On Wednesday 11 July 2007 20:09:04 Rafael J. Wysocki wrote:
> > On Wednesday, 11 July 2007 05:14, Nigel Cunningham wrote:
> > > On Wednesday 11 July 2007 11:59:48 Matthew Garrett wrote:
> > > > On Wed, Jul 11, 2007 at 11:39:37AM +1000, Nigel Cunningham wrote:
> > > >
> > > > > Yeah, that is a bit confusing. At the moment, I'm doing the suspend to
> ram
> > > > > platform dependent preparation and cleanup in this scenario. That's
> > > > > definitely the right thing to do in the case where we write an image,
> then
> > > > > suspend to ram, wake and continue working without running running out
> of
> > > > > battery (writing the image is redundant in that case). Where we end up
> > > > > properly powering down after suspending to ram, I believe we don't run
> the
> > > > > pm_ops->finish after doing the atomic restore when resuming the image.
> > > >
> > > > I'm not convinced this can work terribly well. It's not unlikely that
> > > > hardware will need different state stored over different types of
> > > > suspend. Can you separate out the saving of kernel memory and userspace
> > > > memory, then resume/suspend/save the new kernel state without touching
> > > > the userspace state?
> > >
> > > Yeah, we could redo and resave the atomic copy, but it doesn't seem to be
> > > necessary at the moment; it has been working reliably, regardless of which
> > > combination of events occurs. If/when I come across a case where we have
> > > problems, I'll give resaving the atomic copy a go.
> > >
> > > (Thinks some more). Ah, I think we're already doing the right thing, if
> I'm
> > > recalling the order of actions right. If I'm remembering correctly, prior
> to
> > > the atomic copy, we do hibernation prep, then after the atomic copy,
> > > hibernation cleanup. Then, if suspending to ram, we do the
> prep/enter/cleanup
> > > after the image has finished writing. If we lose power from suspend to
> ram,
> > > it doesn't matter because we're just doing a normal resume then, with the
> > > hibernation cleanup post atomic restore machine the prep that was done
> prior
> > > to the atomic copy.
> > >
> > > To summarise:
> > >
> > > Hibernate + STR + full wake.
> > > Hibernation prep
> > > (Atomic copy)
> > > Hibernation cleanup
> > > STR prep
> > > STR enter
> > > STR cleanup
> > > Remove hibernation image
> > >
> > > Hibernate + STR + poweroff + hibernate resume:
> > >
> > > Hibernation prep
> > > (Atomic copy)
> > > Hibernation cleanup
> > > STR prep
> > > STR enter
> > > <power out> or <STR wake + power off> (STR prep/enter no longer matters)
> > > (Fresh boot)
> > > Atomic restore
> > > Hibernation cleanup (matching prep at start)
> > > Remove hibernation image
> >
> > Yes, I think that this is the right ordering, but for some graphics adapters
> > we need to do some tricks from the user space before 'STR prep' and after
> > 'STR cleanup', which is theoretically possible with uswsusp.
>
> Yeah. I haven't done it yet, but intend to implement that using userui.
I thought of a hibernation daemon that could communicate with the hibernation
thread via sysfs/kevent or something like this.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Re: Hibernate after alarm wakes from STR
2007-07-11 10:14 ` [linux-pm] " Nigel Cunningham
2007-07-11 10:31 ` Rafael J. Wysocki
@ 2007-07-11 10:31 ` Rafael J. Wysocki
1 sibling, 0 replies; 126+ messages in thread
From: Rafael J. Wysocki @ 2007-07-11 10:31 UTC (permalink / raw)
To: Nigel Cunningham
Cc: Matthew Garrett, rtc-linux, linux-acpi, nigel, Richard Hughes, linux-pm
On Wednesday, 11 July 2007 12:14, Nigel Cunningham wrote:
> Hi.
>
> On Wednesday 11 July 2007 20:09:04 Rafael J. Wysocki wrote:
> > On Wednesday, 11 July 2007 05:14, Nigel Cunningham wrote:
> > > On Wednesday 11 July 2007 11:59:48 Matthew Garrett wrote:
> > > > On Wed, Jul 11, 2007 at 11:39:37AM +1000, Nigel Cunningham wrote:
> > > >
> > > > > Yeah, that is a bit confusing. At the moment, I'm doing the suspend to
> ram
> > > > > platform dependent preparation and cleanup in this scenario. That's
> > > > > definitely the right thing to do in the case where we write an image,
> then
> > > > > suspend to ram, wake and continue working without running running out
> of
> > > > > battery (writing the image is redundant in that case). Where we end up
> > > > > properly powering down after suspending to ram, I believe we don't run
> the
> > > > > pm_ops->finish after doing the atomic restore when resuming the image.
> > > >
> > > > I'm not convinced this can work terribly well. It's not unlikely that
> > > > hardware will need different state stored over different types of
> > > > suspend. Can you separate out the saving of kernel memory and userspace
> > > > memory, then resume/suspend/save the new kernel state without touching
> > > > the userspace state?
> > >
> > > Yeah, we could redo and resave the atomic copy, but it doesn't seem to be
> > > necessary at the moment; it has been working reliably, regardless of which
> > > combination of events occurs. If/when I come across a case where we have
> > > problems, I'll give resaving the atomic copy a go.
> > >
> > > (Thinks some more). Ah, I think we're already doing the right thing, if
> I'm
> > > recalling the order of actions right. If I'm remembering correctly, prior
> to
> > > the atomic copy, we do hibernation prep, then after the atomic copy,
> > > hibernation cleanup. Then, if suspending to ram, we do the
> prep/enter/cleanup
> > > after the image has finished writing. If we lose power from suspend to
> ram,
> > > it doesn't matter because we're just doing a normal resume then, with the
> > > hibernation cleanup post atomic restore machine the prep that was done
> prior
> > > to the atomic copy.
> > >
> > > To summarise:
> > >
> > > Hibernate + STR + full wake.
> > > Hibernation prep
> > > (Atomic copy)
> > > Hibernation cleanup
> > > STR prep
> > > STR enter
> > > STR cleanup
> > > Remove hibernation image
> > >
> > > Hibernate + STR + poweroff + hibernate resume:
> > >
> > > Hibernation prep
> > > (Atomic copy)
> > > Hibernation cleanup
> > > STR prep
> > > STR enter
> > > <power out> or <STR wake + power off> (STR prep/enter no longer matters)
> > > (Fresh boot)
> > > Atomic restore
> > > Hibernation cleanup (matching prep at start)
> > > Remove hibernation image
> >
> > Yes, I think that this is the right ordering, but for some graphics adapters
> > we need to do some tricks from the user space before 'STR prep' and after
> > 'STR cleanup', which is theoretically possible with uswsusp.
>
> Yeah. I haven't done it yet, but intend to implement that using userui.
I thought of a hibernation daemon that could communicate with the hibernation
thread via sysfs/kevent or something like this.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Re: Hibernate after alarm wakes from STR
2007-07-11 1:59 ` [linux-pm] " Matthew Garrett
2007-07-11 3:14 ` Nigel Cunningham
@ 2007-07-11 3:14 ` Nigel Cunningham
1 sibling, 0 replies; 126+ messages in thread
From: Nigel Cunningham @ 2007-07-11 3:14 UTC (permalink / raw)
To: Matthew Garrett; +Cc: rtc-linux, linux-acpi, nigel, Richard Hughes, linux-pm
[-- Attachment #1.1: Type: text/plain, Size: 2455 bytes --]
Hi.
On Wednesday 11 July 2007 11:59:48 Matthew Garrett wrote:
> On Wed, Jul 11, 2007 at 11:39:37AM +1000, Nigel Cunningham wrote:
>
> > Yeah, that is a bit confusing. At the moment, I'm doing the suspend to ram
> > platform dependent preparation and cleanup in this scenario. That's
> > definitely the right thing to do in the case where we write an image, then
> > suspend to ram, wake and continue working without running running out of
> > battery (writing the image is redundant in that case). Where we end up
> > properly powering down after suspending to ram, I believe we don't run the
> > pm_ops->finish after doing the atomic restore when resuming the image.
>
> I'm not convinced this can work terribly well. It's not unlikely that
> hardware will need different state stored over different types of
> suspend. Can you separate out the saving of kernel memory and userspace
> memory, then resume/suspend/save the new kernel state without touching
> the userspace state?
Yeah, we could redo and resave the atomic copy, but it doesn't seem to be
necessary at the moment; it has been working reliably, regardless of which
combination of events occurs. If/when I come across a case where we have
problems, I'll give resaving the atomic copy a go.
(Thinks some more). Ah, I think we're already doing the right thing, if I'm
recalling the order of actions right. If I'm remembering correctly, prior to
the atomic copy, we do hibernation prep, then after the atomic copy,
hibernation cleanup. Then, if suspending to ram, we do the prep/enter/cleanup
after the image has finished writing. If we lose power from suspend to ram,
it doesn't matter because we're just doing a normal resume then, with the
hibernation cleanup post atomic restore machine the prep that was done prior
to the atomic copy.
To summarise:
Hibernate + STR + full wake.
Hibernation prep
(Atomic copy)
Hibernation cleanup
STR prep
STR enter
STR cleanup
Remove hibernation image
Hibernate + STR + poweroff + hibernate resume:
Hibernation prep
(Atomic copy)
Hibernation cleanup
STR prep
STR enter
<power out> or <STR wake + power off> (STR prep/enter no longer matters)
(Fresh boot)
Atomic restore
Hibernation cleanup (matching prep at start)
Remove hibernation image
Regards,
Nigel
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Re: Hibernate after alarm wakes from STR
2007-07-11 0:53 ` Nigel Cunningham
2007-07-11 1:23 ` Matthew Garrett
@ 2007-07-11 1:23 ` Matthew Garrett
1 sibling, 0 replies; 126+ messages in thread
From: Matthew Garrett @ 2007-07-11 1:23 UTC (permalink / raw)
To: nigel; +Cc: rtc-linux, Richard Hughes, linux-acpi, linux-pm
On Wed, Jul 11, 2007 at 10:53:35AM +1000, Nigel Cunningham wrote:
> On Wednesday 11 July 2007 10:45:50 Matthew Garrett wrote:
> > How are you going to shift into suspend to disk without going via
> > userspace? It's quite plausible that people will want different
> > configuration at that point (or, realistically, need a different set of
> > workarounds...)
>
> This is done after writing the image, from kernel space. We do the
> suspend-to-ram, and if/when we wake from that, we look at the lid switch
> state before removing the image. If it's still closed, the kernel code powers
> down again (this time properly) without userspace ever seeing the light of
> day.
Yes. I'm sort of struggling to see how this is done especially reliably
- if we have separate hibernation and suspend to ram pathways, which is
executed in this scenario?
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Re: Hibernate after alarm wakes from STR
2007-07-11 0:45 ` Matthew Garrett
2007-07-11 0:53 ` Nigel Cunningham
@ 2007-07-11 0:53 ` Nigel Cunningham
1 sibling, 0 replies; 126+ messages in thread
From: Nigel Cunningham @ 2007-07-11 0:53 UTC (permalink / raw)
To: Matthew Garrett; +Cc: rtc-linux, linux-acpi, nigel, Richard Hughes, linux-pm
[-- Attachment #1.1: Type: text/plain, Size: 1090 bytes --]
Hi.
On Wednesday 11 July 2007 10:45:50 Matthew Garrett wrote:
> On Wed, Jul 11, 2007 at 08:16:40AM +1000, Nigel Cunningham wrote:
> > Yeah, the bit I consider to be ugly is opening the files from within the
> > kernel, but it seemed to be necessary in order to provide the
functionality
> > without having to rely on userspace or do some sort of messy work to
figure
> > out how to access the lid button and so on.
>
> How are you going to shift into suspend to disk without going via
> userspace? It's quite plausible that people will want different
> configuration at that point (or, realistically, need a different set of
> workarounds...)
This is done after writing the image, from kernel space. We do the
suspend-to-ram, and if/when we wake from that, we look at the lid switch
state before removing the image. If it's still closed, the kernel code powers
down again (this time properly) without userspace ever seeing the light of
day.
Regards,
Nigel
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Re: Hibernate after alarm wakes from STR
2007-07-10 22:16 ` [linux-pm] " Nigel Cunningham
2007-07-11 0:45 ` Matthew Garrett
@ 2007-07-11 0:45 ` Matthew Garrett
2007-07-11 16:04 ` [linux-pm] " David Brownell
2007-07-11 16:04 ` David Brownell
3 siblings, 0 replies; 126+ messages in thread
From: Matthew Garrett @ 2007-07-11 0:45 UTC (permalink / raw)
To: nigel; +Cc: rtc-linux, Richard Hughes, linux-acpi, linux-pm
On Wed, Jul 11, 2007 at 08:16:40AM +1000, Nigel Cunningham wrote:
> Yeah, the bit I consider to be ugly is opening the files from within the
> kernel, but it seemed to be necessary in order to provide the functionality
> without having to rely on userspace or do some sort of messy work to figure
> out how to access the lid button and so on.
How are you going to shift into suspend to disk without going via
userspace? It's quite plausible that people will want different
configuration at that point (or, realistically, need a different set of
workarounds...)
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [linux-pm] Re: Hibernate after alarm wakes from STR
2007-07-10 22:16 ` [linux-pm] " Nigel Cunningham
2007-07-11 0:45 ` Matthew Garrett
2007-07-11 0:45 ` Matthew Garrett
@ 2007-07-11 16:04 ` David Brownell
2007-07-11 22:48 ` Nigel Cunningham
2007-07-11 22:48 ` [linux-pm] " Nigel Cunningham
2007-07-11 16:04 ` David Brownell
3 siblings, 2 replies; 126+ messages in thread
From: David Brownell @ 2007-07-11 16:04 UTC (permalink / raw)
To: nigel; +Cc: linux-pm, Marcelo Tosatti, linux-acpi, Richard Hughes, rtc-linux
On Tuesday 10 July 2007, Nigel Cunningham wrote:
> Yeah, the bit I consider to be ugly is opening the files from within the
> kernel, but it seemed to be necessary in order to provide the functionality
> without having to rely on userspace or do some sort of messy work to figure
> out how to access the lid button and so on.
Perhaps there should be a formal API to such buttons.
> Re proc files, are the button files already exposed under sysfs and I just
> don't know? If so, I'll happily shift to using them.
ascent:/sys/devices/acpi_system:00/device:00/PNP0C0D:00$ ls -l
total 0
lrwxrwxrwx 1 root root 0 2007-07-11 08:58 bus -> ../../../../bus/acpi/
lrwxrwxrwx 1 root root 0 2007-07-11 08:58 driver -> ../../../../bus/acpi/drivers/button/
-r--r--r-- 1 root root 4096 2007-07-11 08:58 hid
lrwxrwxrwx 1 root root 0 2007-07-11 08:58 input:event2 -> ../../../../class/input/input2/event2/
lrwxrwxrwx 1 root root 0 2007-07-11 08:58 input:input2 -> ../../../../class/input/input2/
-r--r--r-- 1 root root 4096 2007-07-11 08:58 path
drwxr-xr-x 2 root root 0 2007-07-11 08:58 power/
lrwxrwxrwx 1 root root 0 2007-07-11 08:58 subsystem -> ../../../../bus/acpi/
-rw-r--r-- 1 root root 4096 2007-07-11 08:58 uevent
db@ascent:/sys/devices/acpi_system:00/device:00/PNP0C0D:00$ cat path
\_SB_.LID_
ascent:/sys/devices/acpi_system:00/device:00/PNP0C0D:00$
If the generic kernel doesn't show that, then it's likely
a consequence of a submitted-but-not-yet-merged patch.
- Dave
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Re: Hibernate after alarm wakes from STR
2007-07-11 16:04 ` [linux-pm] " David Brownell
@ 2007-07-11 22:48 ` Nigel Cunningham
2007-07-11 22:48 ` [linux-pm] " Nigel Cunningham
1 sibling, 0 replies; 126+ messages in thread
From: Nigel Cunningham @ 2007-07-11 22:48 UTC (permalink / raw)
To: David Brownell; +Cc: rtc-linux, linux-acpi, nigel, Richard Hughes, linux-pm
[-- Attachment #1.1: Type: text/plain, Size: 1892 bytes --]
Hi.
On Thursday 12 July 2007 02:04:33 David Brownell wrote:
> On Tuesday 10 July 2007, Nigel Cunningham wrote:
> > Yeah, the bit I consider to be ugly is opening the files from within the
> > kernel, but it seemed to be necessary in order to provide the
functionality
> > without having to rely on userspace or do some sort of messy work to
figure
> > out how to access the lid button and so on.
>
> Perhaps there should be a formal API to such buttons.
That would be good.
> > Re proc files, are the button files already exposed under sysfs and I just
> > don't know? If so, I'll happily shift to using them.
>
> ascent:/sys/devices/acpi_system:00/device:00/PNP0C0D:00$ ls -l
> total 0
> lrwxrwxrwx 1 root root 0 2007-07-11 08:58 bus -> ../../../../bus/acpi/
> lrwxrwxrwx 1 root root 0 2007-07-11 08:58
driver -> ../../../../bus/acpi/drivers/button/
> -r--r--r-- 1 root root 4096 2007-07-11 08:58 hid
> lrwxrwxrwx 1 root root 0 2007-07-11 08:58
input:event2 -> ../../../../class/input/input2/event2/
> lrwxrwxrwx 1 root root 0 2007-07-11 08:58
input:input2 -> ../../../../class/input/input2/
> -r--r--r-- 1 root root 4096 2007-07-11 08:58 path
> drwxr-xr-x 2 root root 0 2007-07-11 08:58 power/
> lrwxrwxrwx 1 root root 0 2007-07-11 08:58
subsystem -> ../../../../bus/acpi/
> -rw-r--r-- 1 root root 4096 2007-07-11 08:58 uevent
> db@ascent:/sys/devices/acpi_system:00/device:00/PNP0C0D:00$ cat path
> \_SB_.LID_
> ascent:/sys/devices/acpi_system:00/device:00/PNP0C0D:00$
>
> If the generic kernel doesn't show that, then it's likely
> a consequence of a submitted-but-not-yet-merged patch.
I have that too, but I can't seem to figure out which file contains the state
of the button. Is there one?
Regards,
Nigel
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [linux-pm] Re: Hibernate after alarm wakes from STR
2007-07-11 16:04 ` [linux-pm] " David Brownell
2007-07-11 22:48 ` Nigel Cunningham
@ 2007-07-11 22:48 ` Nigel Cunningham
1 sibling, 0 replies; 126+ messages in thread
From: Nigel Cunningham @ 2007-07-11 22:48 UTC (permalink / raw)
To: David Brownell
Cc: nigel, linux-pm, Marcelo Tosatti, linux-acpi, Richard Hughes, rtc-linux
[-- Attachment #1: Type: text/plain, Size: 1892 bytes --]
Hi.
On Thursday 12 July 2007 02:04:33 David Brownell wrote:
> On Tuesday 10 July 2007, Nigel Cunningham wrote:
> > Yeah, the bit I consider to be ugly is opening the files from within the
> > kernel, but it seemed to be necessary in order to provide the
functionality
> > without having to rely on userspace or do some sort of messy work to
figure
> > out how to access the lid button and so on.
>
> Perhaps there should be a formal API to such buttons.
That would be good.
> > Re proc files, are the button files already exposed under sysfs and I just
> > don't know? If so, I'll happily shift to using them.
>
> ascent:/sys/devices/acpi_system:00/device:00/PNP0C0D:00$ ls -l
> total 0
> lrwxrwxrwx 1 root root 0 2007-07-11 08:58 bus -> ../../../../bus/acpi/
> lrwxrwxrwx 1 root root 0 2007-07-11 08:58
driver -> ../../../../bus/acpi/drivers/button/
> -r--r--r-- 1 root root 4096 2007-07-11 08:58 hid
> lrwxrwxrwx 1 root root 0 2007-07-11 08:58
input:event2 -> ../../../../class/input/input2/event2/
> lrwxrwxrwx 1 root root 0 2007-07-11 08:58
input:input2 -> ../../../../class/input/input2/
> -r--r--r-- 1 root root 4096 2007-07-11 08:58 path
> drwxr-xr-x 2 root root 0 2007-07-11 08:58 power/
> lrwxrwxrwx 1 root root 0 2007-07-11 08:58
subsystem -> ../../../../bus/acpi/
> -rw-r--r-- 1 root root 4096 2007-07-11 08:58 uevent
> db@ascent:/sys/devices/acpi_system:00/device:00/PNP0C0D:00$ cat path
> \_SB_.LID_
> ascent:/sys/devices/acpi_system:00/device:00/PNP0C0D:00$
>
> If the generic kernel doesn't show that, then it's likely
> a consequence of a submitted-but-not-yet-merged patch.
I have that too, but I can't seem to figure out which file contains the state
of the button. Is there one?
Regards,
Nigel
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Re: Hibernate after alarm wakes from STR
2007-07-10 22:16 ` [linux-pm] " Nigel Cunningham
` (2 preceding siblings ...)
2007-07-11 16:04 ` [linux-pm] " David Brownell
@ 2007-07-11 16:04 ` David Brownell
3 siblings, 0 replies; 126+ messages in thread
From: David Brownell @ 2007-07-11 16:04 UTC (permalink / raw)
To: nigel; +Cc: linux-acpi, linux-pm, Richard Hughes, rtc-linux
On Tuesday 10 July 2007, Nigel Cunningham wrote:
> Yeah, the bit I consider to be ugly is opening the files from within the
> kernel, but it seemed to be necessary in order to provide the functionality
> without having to rely on userspace or do some sort of messy work to figure
> out how to access the lid button and so on.
Perhaps there should be a formal API to such buttons.
> Re proc files, are the button files already exposed under sysfs and I just
> don't know? If so, I'll happily shift to using them.
ascent:/sys/devices/acpi_system:00/device:00/PNP0C0D:00$ ls -l
total 0
lrwxrwxrwx 1 root root 0 2007-07-11 08:58 bus -> ../../../../bus/acpi/
lrwxrwxrwx 1 root root 0 2007-07-11 08:58 driver -> ../../../../bus/acpi/drivers/button/
-r--r--r-- 1 root root 4096 2007-07-11 08:58 hid
lrwxrwxrwx 1 root root 0 2007-07-11 08:58 input:event2 -> ../../../../class/input/input2/event2/
lrwxrwxrwx 1 root root 0 2007-07-11 08:58 input:input2 -> ../../../../class/input/input2/
-r--r--r-- 1 root root 4096 2007-07-11 08:58 path
drwxr-xr-x 2 root root 0 2007-07-11 08:58 power/
lrwxrwxrwx 1 root root 0 2007-07-11 08:58 subsystem -> ../../../../bus/acpi/
-rw-r--r-- 1 root root 4096 2007-07-11 08:58 uevent
db@ascent:/sys/devices/acpi_system:00/device:00/PNP0C0D:00$ cat path
\_SB_.LID_
ascent:/sys/devices/acpi_system:00/device:00/PNP0C0D:00$
If the generic kernel doesn't show that, then it's likely
a consequence of a submitted-but-not-yet-merged patch.
- Dave
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Hibernate after alarm wakes from STR
2007-07-08 20:15 ` David Brownell
2007-07-08 22:31 ` Marcelo Tosatti
@ 2007-07-08 22:31 ` Marcelo Tosatti
1 sibling, 0 replies; 126+ messages in thread
From: Marcelo Tosatti @ 2007-07-08 22:31 UTC (permalink / raw)
To: David Brownell; +Cc: rtc-linux, Richard Hughes, linux-acpi, linux-pm, devel
On Sun, Jul 08, 2007 at 01:15:40PM -0700, David Brownell wrote:
> On Sunday 08 July 2007, Richard Hughes wrote:
> > On Sun, 2007-07-08 at 12:17 -0700, David Brownell wrote:
> > >
> > > I think so ... although that's unfortunately another difference
> > > between the legacy x86-mostly code and the newer RTC framework.
> >
> > (sorry for hijacking the thread)
>
> I changed $SUBJECT ...
>
>
> > Is this the interface should stuff like HAL use to do:
> >
> > * Suspend for 10 minutes
> > * auto wakeup and then hibernate...
>
> That is, "Suspend-to-RAM" or "standby"? Yes, assuming that works on
> this particular system. Arguably that would be a direction for
> cpuidle to think about too, but I think alarm-driven wakeup is more
> ready-to-use at this point.
>
>
> > I figure we can do a suspend setting the rtc using the ioctls and then
> > we wakeup, and HAL has to know that we woke up from the alarm rather
> > than from a lid event or keypress.
On OLPC hibernate would be suspend-to-disk, but we haven't done any
testing with that yet. It would be necessary to check for available disk
space before attempting it (or reserving space perhaps?).
> ... although I don't know whether that particular distinction is
> made to userspace right now. ACPI provides a bit like that, and
> at least a few other systems can do something analagous.
Yes, we can poke at registers to find that out.
> That is, we may want to provide a bit more information about the
> specific event which triggered wakeup. I don't believe there is
> such an interface, in general.
What would be a nice interface? Perhaps an additional file under
/sys/devices/.../power/wakeup_fired or something (only for devices with
can_wakeup set).
> Plus, the notion seems kind of racey to me. (If you press a key
> right while the wakealarm fires, you don't want hibernation..)
Then you check if the any key or other wakeup event has happened other
than RTC... I don't see any problem with that.
> > Is this something we can do (or should do) for OLPC and general ACPI?
>
> I'd certainly rather see laptops doing that than what they do now:
> running the battery out, and needing filesystem recovery!!
Yep.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: rtc-cmos not supporting RTC_AIE?
2007-07-08 19:17 ` David Brownell
2007-07-08 19:31 ` Richard Hughes
@ 2007-07-08 19:31 ` Richard Hughes
1 sibling, 0 replies; 126+ messages in thread
From: Richard Hughes @ 2007-07-08 19:31 UTC (permalink / raw)
To: David Brownell; +Cc: linux-acpi, linux-pm, devel, rtc-linux
On Sun, 2007-07-08 at 12:17 -0700, David Brownell wrote:
>
> I think so ... although that's unfortunately another difference
> between the legacy x86-mostly code and the newer RTC framework.
(sorry for hijacking the thread)
Is this the interface should stuff like HAL use to do:
* Suspend for 10 minutes
* auto wakeup and then hibernate.
I figure we can do a suspend setting the rtc using the ioctls and then
we wakeup, and HAL has to know that we woke up from the alarm rather
than from a lid event or keypress.
Is this something we can do (or should do) for OLPC and general ACPI?
Cheers guys.
Richard.
^ permalink raw reply [flat|nested] 126+ messages in thread
* [PATCH] rtc-cmos: use cmos_rtc_board_info to determine wake_on callback
2007-04-02 16:55 ` Jordan Crouse
` (3 preceding siblings ...)
2007-07-08 3:46 ` Marcelo Tosatti
@ 2007-07-08 3:49 ` Marcelo Tosatti
2007-07-08 3:49 ` Marcelo Tosatti
` (2 subsequent siblings)
7 siblings, 0 replies; 126+ messages in thread
From: Marcelo Tosatti @ 2007-07-08 3:49 UTC (permalink / raw)
To: David Brownell; +Cc: linux-pm, devel, linux-acpi
>From my understand ACPI fills a cmos_rtc_board_info with pointers for
wake_on/wake_off callbacks and registers that at dev->platform_data.
So use that to retrieve the callback pointers.
Am I missing something?
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index e24ea82..5bfab23 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -549,6 +549,7 @@ #ifdef CONFIG_PM
static int cmos_suspend(struct device *dev, pm_message_t mesg)
{
struct cmos_rtc *cmos = dev_get_drvdata(dev);
+ struct cmos_rtc_board_info *board_info = dev->platform_data;
int do_wake = device_may_wakeup(dev);
unsigned char tmp;
@@ -572,8 +573,8 @@ static int cmos_suspend(struct device *d
if (tmp & RTC_AIE) {
cmos->enabled_wake = 1;
- if (cmos->wake_on)
- cmos->wake_on(dev);
+ if (board_info->wake_on)
+ board_info->wake_on(dev);
else
enable_irq_wake(cmos->irq);
}
^ permalink raw reply related [flat|nested] 126+ messages in thread* [PATCH] rtc-cmos: use cmos_rtc_board_info to determine wake_on callback
2007-04-02 16:55 ` Jordan Crouse
` (4 preceding siblings ...)
2007-07-08 3:49 ` [PATCH] rtc-cmos: use cmos_rtc_board_info to determine wake_on callback Marcelo Tosatti
@ 2007-07-08 3:49 ` Marcelo Tosatti
2007-07-08 5:06 ` David Brownell
2007-07-08 5:06 ` David Brownell
2007-07-08 3:55 ` [PATCH] OLPC rtc-cmos support Marcelo Tosatti
2007-07-08 3:55 ` Marcelo Tosatti
7 siblings, 2 replies; 126+ messages in thread
From: Marcelo Tosatti @ 2007-07-08 3:49 UTC (permalink / raw)
To: David Brownell; +Cc: linux-pm, devel, linux-acpi
>From my understand ACPI fills a cmos_rtc_board_info with pointers for
wake_on/wake_off callbacks and registers that at dev->platform_data.
So use that to retrieve the callback pointers.
Am I missing something?
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index e24ea82..5bfab23 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -549,6 +549,7 @@ #ifdef CONFIG_PM
static int cmos_suspend(struct device *dev, pm_message_t mesg)
{
struct cmos_rtc *cmos = dev_get_drvdata(dev);
+ struct cmos_rtc_board_info *board_info = dev->platform_data;
int do_wake = device_may_wakeup(dev);
unsigned char tmp;
@@ -572,8 +573,8 @@ static int cmos_suspend(struct device *d
if (tmp & RTC_AIE) {
cmos->enabled_wake = 1;
- if (cmos->wake_on)
- cmos->wake_on(dev);
+ if (board_info->wake_on)
+ board_info->wake_on(dev);
else
enable_irq_wake(cmos->irq);
}
^ permalink raw reply related [flat|nested] 126+ messages in thread* Re: [PATCH] rtc-cmos: use cmos_rtc_board_info to determine wake_on callback
2007-07-08 3:49 ` Marcelo Tosatti
@ 2007-07-08 5:06 ` David Brownell
2007-07-08 5:06 ` David Brownell
1 sibling, 0 replies; 126+ messages in thread
From: David Brownell @ 2007-07-08 5:06 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Jordan Crouse, linux-acpi, linux-pm, devel
On Saturday 07 July 2007, Marcelo Tosatti wrote:
>
> From my understand ACPI fills a cmos_rtc_board_info with pointers for
> wake_on/wake_off callbacks and registers that at dev->platform_data.
>
> So use that to retrieve the callback pointers.
>
> Am I missing something?
This is retrieved already in the probe() routine, which
does other board-specific setup that may be needed.
So this patch isn't needed. Or, in fact, correct ... both
the wake_on() and wake_off() methods are required.
> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index e24ea82..5bfab23 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -549,6 +549,7 @@ #ifdef CONFIG_PM
> static int cmos_suspend(struct device *dev, pm_message_t mesg)
> {
> struct cmos_rtc *cmos = dev_get_drvdata(dev);
> + struct cmos_rtc_board_info *board_info = dev->platform_data;
> int do_wake = device_may_wakeup(dev);
> unsigned char tmp;
>
> @@ -572,8 +573,8 @@ static int cmos_suspend(struct device *d
>
> if (tmp & RTC_AIE) {
> cmos->enabled_wake = 1;
> - if (cmos->wake_on)
> - cmos->wake_on(dev);
> + if (board_info->wake_on)
> + board_info->wake_on(dev);
> else
> enable_irq_wake(cmos->irq);
> }
>
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: [PATCH] rtc-cmos: use cmos_rtc_board_info to determine wake_on callback
2007-07-08 3:49 ` Marcelo Tosatti
2007-07-08 5:06 ` David Brownell
@ 2007-07-08 5:06 ` David Brownell
1 sibling, 0 replies; 126+ messages in thread
From: David Brownell @ 2007-07-08 5:06 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-pm, devel, linux-acpi
On Saturday 07 July 2007, Marcelo Tosatti wrote:
>
> From my understand ACPI fills a cmos_rtc_board_info with pointers for
> wake_on/wake_off callbacks and registers that at dev->platform_data.
>
> So use that to retrieve the callback pointers.
>
> Am I missing something?
This is retrieved already in the probe() routine, which
does other board-specific setup that may be needed.
So this patch isn't needed. Or, in fact, correct ... both
the wake_on() and wake_off() methods are required.
> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index e24ea82..5bfab23 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -549,6 +549,7 @@ #ifdef CONFIG_PM
> static int cmos_suspend(struct device *dev, pm_message_t mesg)
> {
> struct cmos_rtc *cmos = dev_get_drvdata(dev);
> + struct cmos_rtc_board_info *board_info = dev->platform_data;
> int do_wake = device_may_wakeup(dev);
> unsigned char tmp;
>
> @@ -572,8 +573,8 @@ static int cmos_suspend(struct device *d
>
> if (tmp & RTC_AIE) {
> cmos->enabled_wake = 1;
> - if (cmos->wake_on)
> - cmos->wake_on(dev);
> + if (board_info->wake_on)
> + board_info->wake_on(dev);
> else
> enable_irq_wake(cmos->irq);
> }
>
^ permalink raw reply [flat|nested] 126+ messages in thread
* [PATCH] OLPC rtc-cmos support
2007-04-02 16:55 ` Jordan Crouse
` (5 preceding siblings ...)
2007-07-08 3:49 ` Marcelo Tosatti
@ 2007-07-08 3:55 ` Marcelo Tosatti
2007-07-08 5:13 ` David Brownell
2007-07-08 5:13 ` David Brownell
2007-07-08 3:55 ` Marcelo Tosatti
7 siblings, 2 replies; 126+ messages in thread
From: Marcelo Tosatti @ 2007-07-08 3:55 UTC (permalink / raw)
To: David Brownell; +Cc: linux-pm, devel, linux-acpi
Hi,
The following patch implements the hooks necessary for OLPC to use the
rtc-cmos driver. This is necessary since we do not want CONFIG_PNP.
This makes it possible to control rtc wakeup via
/sys/devices/platform/rtc_cmos/power/wakeup.
Comments?
diff --git a/arch/i386/kernel/olpc-pm.c b/arch/i386/kernel/olpc-pm.c
index 9599dbe..d92c54a 100644
--- a/arch/i386/kernel/olpc-pm.c
+++ b/arch/i386/kernel/olpc-pm.c
@@ -11,6 +11,9 @@ #include <linux/delay.h>
#include <linux/input.h>
#include <linux/suspend.h>
#include <linux/bootmem.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+#include <linux/mc146818rtc.h>
#include <asm/io.h>
#include <asm/olpc.h>
@@ -272,6 +275,8 @@ static int olpc_pm_enter(suspend_state_t
return 0;
}
+static u16 olpc_wakeup_mask = CS5536_PM_PWRBTN;
+
int asmlinkage olpc_do_sleep(u8 sleep_state)
{
void *pgd_addr = __va(read_cr3());
@@ -282,7 +287,7 @@ int asmlinkage olpc_do_sleep(u8 sleep_st
/* FIXME: Set any other SCI events that we might want here */
- outl((CS5536_PM_PWRBTN << 16) | 0xFFFF, acpi_base + PM1_STS);
+ outl((olpc_wakeup_mask << 16) | 0xFFFF, acpi_base + PM1_STS);
/* If we are in test mode, then just return (simulate a successful
suspend/resume). Otherwise, if we are doing the real thing,
@@ -549,6 +554,92 @@ static int __init olpc_pm_init(void)
return 0;
}
+
+#if defined (CONFIG_RTC_DRV_CMOS) || defined (CONFIG_RTC_DRV_CMOS_MODULE)
+struct resource rtc_platform_resource[2] = {
+ {
+ .flags = IORESOURCE_IO,
+ .start = RTC_PORT(0),
+ .end = RTC_PORT(0) + RTC_IO_EXTENT
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ .start = 8,
+ .end = 8,
+ },
+};
+
+struct resource rtc_platform_irq = {
+ .flags = IORESOURCE_IRQ,
+ .start = 8,
+ .end = 8,
+};
+
+static int olpc_add_rtc(void)
+{
+ struct platform_device *pd;
+
+ pd = platform_device_register_simple("rtc_cmos", -1,
+ rtc_platform_resource, 2);
+ if (IS_ERR(pd))
+ return PTR_ERR(pd);
+
+ /* rtc-cmos only supports 24-hr mode */
+ CMOS_WRITE(CMOS_READ(RTC_CONTROL) | RTC_24H, RTC_CONTROL);
+
+ return 0;
+}
+arch_initcall(olpc_add_rtc);
+
+static struct cmos_rtc_board_info rtc_info;
+
+static void rtc_wake_on(struct device *dev)
+{
+ olpc_wakeup_mask |= CS5536_PM_RTC;
+}
+
+static void rtc_wake_off(struct device *dev)
+{
+ olpc_wakeup_mask &= ~(CS5536_PM_RTC);
+}
+
+static int rtc_match(struct device *dev, void *data)
+{
+ static const char *devname = { "rtc_cmos" };
+ struct rtc_device *rtcdev = to_rtc_device(dev);
+
+ if (!strcmp(devname, rtcdev->name))
+ return 1;
+
+ return 0;
+}
+
+static struct device * get_rtc_dev(void)
+{
+ return bus_find_device(&platform_bus_type, NULL, NULL, rtc_match);
+}
+
+static int olpc_rtc_init(void)
+{
+ struct device *dev = get_rtc_dev();
+
+ if (dev) {
+ rtc_info.rtc_day_alarm = 0;
+ rtc_info.rtc_mon_alarm = 0;
+ rtc_info.rtc_century = 0;
+ rtc_info.wake_on = rtc_wake_on;
+ rtc_info.wake_off = rtc_wake_off;
+
+ dev->platform_data = &rtc_info;
+
+ device_init_wakeup(dev, 1);
+ } else
+ printk(KERN_ERR "no rtc\n");
+ return 0;
+}
+fs_initcall(olpc_rtc_init);
+#endif /* CONFIG_RTC_DRV_CMOS */
+
static void olpc_pm_exit(void)
{
/* Clear any pending events, and disable them */
^ permalink raw reply related [flat|nested] 126+ messages in thread* Re: [PATCH] OLPC rtc-cmos support
2007-07-08 3:55 ` [PATCH] OLPC rtc-cmos support Marcelo Tosatti
@ 2007-07-08 5:13 ` David Brownell
2007-07-08 18:40 ` Marcelo Tosatti
2007-07-08 18:40 ` Marcelo Tosatti
2007-07-08 5:13 ` David Brownell
1 sibling, 2 replies; 126+ messages in thread
From: David Brownell @ 2007-07-08 5:13 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Jordan Crouse, linux-acpi, linux-pm, devel
On Saturday 07 July 2007, Marcelo Tosatti wrote:
>
> Hi,
>
> The following patch implements the hooks necessary for OLPC to use the
> rtc-cmos driver. This is necessary since we do not want CONFIG_PNP.
>
> This makes it possible to control rtc wakeup via
> /sys/devices/platform/rtc_cmos/power/wakeup.
>
> Comments?
Looks almost right ... though I'd have expected the RTC to
support alarms more than just 24 hours into the future!
It's more complicated than necessary. It'd be much simpler
to just declare a static platform_device with pre-initted
platform_data. Then call device_init_wakeup() on that before
calling the usual platform_device_register() routine.
That way you wouldn't need to have two different init sections
just to set up one device, where one of them is spending most
of its time working around the possibility that the other one
failed. And you'd also pretty much eliminate the possibility
that the (now) single init section fails. :)
- Dave
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [PATCH] OLPC rtc-cmos support
2007-07-08 5:13 ` David Brownell
@ 2007-07-08 18:40 ` Marcelo Tosatti
2007-07-08 19:10 ` David Brownell
2007-07-08 19:10 ` David Brownell
2007-07-08 18:40 ` Marcelo Tosatti
1 sibling, 2 replies; 126+ messages in thread
From: Marcelo Tosatti @ 2007-07-08 18:40 UTC (permalink / raw)
To: David Brownell; +Cc: linux-pm, devel, linux-acpi
On Sat, Jul 07, 2007 at 10:13:40PM -0700, David Brownell wrote:
> On Saturday 07 July 2007, Marcelo Tosatti wrote:
> >
> > Hi,
> >
> > The following patch implements the hooks necessary for OLPC to use the
> > rtc-cmos driver. This is necessary since we do not want CONFIG_PNP.
> >
> > This makes it possible to control rtc wakeup via
> > /sys/devices/platform/rtc_cmos/power/wakeup.
> >
> > Comments?
>
> Looks almost right ... though I'd have expected the RTC to
> support alarms more than just 24 hours into the future!
>
> It's more complicated than necessary. It'd be much simpler
> to just declare a static platform_device with pre-initted
> platform_data. Then call device_init_wakeup() on that before
> calling the usual platform_device_register() routine.
>
> That way you wouldn't need to have two different init sections
> just to set up one device, where one of them is spending most
> of its time working around the possibility that the other one
> failed. And you'd also pretty much eliminate the possibility
> that the (now) single init section fails. :)
David,
Like this?
diff --git a/arch/i386/kernel/olpc-pm.c b/arch/i386/kernel/olpc-pm.c
index 9599dbe..8072e68 100644
--- a/arch/i386/kernel/olpc-pm.c
+++ b/arch/i386/kernel/olpc-pm.c
@@ -11,6 +11,9 @@ #include <linux/delay.h>
#include <linux/input.h>
#include <linux/suspend.h>
#include <linux/bootmem.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+#include <linux/mc146818rtc.h>
#include <asm/io.h>
#include <asm/olpc.h>
@@ -272,6 +275,8 @@ static int olpc_pm_enter(suspend_state_t
return 0;
}
+static u16 olpc_wakeup_mask = CS5536_PM_PWRBTN;
+
int asmlinkage olpc_do_sleep(u8 sleep_state)
{
void *pgd_addr = __va(read_cr3());
@@ -282,7 +287,7 @@ int asmlinkage olpc_do_sleep(u8 sleep_st
/* FIXME: Set any other SCI events that we might want here */
- outl((CS5536_PM_PWRBTN << 16) | 0xFFFF, acpi_base + PM1_STS);
+ outl((olpc_wakeup_mask << 16) | 0xFFFF, acpi_base + PM1_STS);
/* If we are in test mode, then just return (simulate a successful
suspend/resume). Otherwise, if we are doing the real thing,
@@ -549,6 +554,65 @@ static int __init olpc_pm_init(void)
return 0;
}
+
+#if defined (CONFIG_RTC_DRV_CMOS) || defined (CONFIG_RTC_DRV_CMOS_MODULE)
+struct resource rtc_platform_resource[2] = {
+ {
+ .flags = IORESOURCE_IO,
+ .start = RTC_PORT(0),
+ .end = RTC_PORT(0) + RTC_IO_EXTENT
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ .start = 8,
+ .end = 8,
+ },
+};
+
+
+static struct cmos_rtc_board_info rtc_info;
+
+struct platform_device olpc_rtc_device = {
+ .name = "rtc_cmos",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(rtc_platform_resource),
+ .dev.platform_data = &rtc_info,
+ .resource = rtc_platform_resource,
+};
+
+struct resource rtc_platform_irq = {
+ .flags = IORESOURCE_IRQ,
+ .start = 8,
+ .end = 8,
+};
+
+static void rtc_wake_on(struct device *dev)
+{
+ olpc_wakeup_mask |= CS5536_PM_RTC;
+}
+
+static void rtc_wake_off(struct device *dev)
+{
+ olpc_wakeup_mask &= ~(CS5536_PM_RTC);
+}
+
+static int olpc_rtc_init(void)
+{
+ rtc_info.rtc_day_alarm = 0;
+ rtc_info.rtc_mon_alarm = 0;
+ rtc_info.rtc_century = 0;
+ rtc_info.wake_on = rtc_wake_on;
+ rtc_info.wake_off = rtc_wake_off;
+
+ (void)platform_device_register(&olpc_rtc_device);
+
+ device_init_wakeup(&olpc_rtc_device.dev, 1);
+
+ return 0;
+}
+fs_initcall(olpc_rtc_init);
+#endif /* CONFIG_RTC_DRV_CMOS */
+
static void olpc_pm_exit(void)
{
/* Clear any pending events, and disable them */
^ permalink raw reply related [flat|nested] 126+ messages in thread* Re: [PATCH] OLPC rtc-cmos support
2007-07-08 18:40 ` Marcelo Tosatti
@ 2007-07-08 19:10 ` David Brownell
2007-07-08 19:10 ` David Brownell
1 sibling, 0 replies; 126+ messages in thread
From: David Brownell @ 2007-07-08 19:10 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-pm, devel, linux-acpi
On Sunday 08 July 2007, Marcelo Tosatti wrote:
> Like this?
Not quite ...
> +struct resource rtc_platform_irq = {
> + .flags = IORESOURCE_IRQ,
> + .start = 8,
> + .end = 8,
> +};
Unused, right?
> +static int olpc_rtc_init(void)
... should be marked __init ...
> +{
> + rtc_info.rtc_day_alarm = 0;
> + rtc_info.rtc_mon_alarm = 0;
> + rtc_info.rtc_century = 0;
> + rtc_info.wake_on = rtc_wake_on;
> + rtc_info.wake_off = rtc_wake_off;
... that can all just be static init ...
> +
> + (void)platform_device_register(&olpc_rtc_device);
> +
> + device_init_wakeup(&olpc_rtc_device.dev, 1);
... do the init_wakeup before registering the device, so
there can never be confusion about whether a probe() will
see that part of device config ...
> +
> + return 0;
> +}
> +fs_initcall(olpc_rtc_init);
... and try to register platform devices in arch_initcall().
Just to avoid potential confusion; that's where it's normally
done, and I don't think you had a need to do it elsewhere.
- Dave
> +#endif /* CONFIG_RTC_DRV_CMOS */
> +
> static void olpc_pm_exit(void)
> {
> /* Clear any pending events, and disable them */
>
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: [PATCH] OLPC rtc-cmos support
2007-07-08 18:40 ` Marcelo Tosatti
2007-07-08 19:10 ` David Brownell
@ 2007-07-08 19:10 ` David Brownell
2007-07-08 20:17 ` Marcelo Tosatti
2007-07-08 20:17 ` Marcelo Tosatti
1 sibling, 2 replies; 126+ messages in thread
From: David Brownell @ 2007-07-08 19:10 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-pm, devel, linux-acpi
On Sunday 08 July 2007, Marcelo Tosatti wrote:
> Like this?
Not quite ...
> +struct resource rtc_platform_irq = {
> + .flags = IORESOURCE_IRQ,
> + .start = 8,
> + .end = 8,
> +};
Unused, right?
> +static int olpc_rtc_init(void)
... should be marked __init ...
> +{
> + rtc_info.rtc_day_alarm = 0;
> + rtc_info.rtc_mon_alarm = 0;
> + rtc_info.rtc_century = 0;
> + rtc_info.wake_on = rtc_wake_on;
> + rtc_info.wake_off = rtc_wake_off;
... that can all just be static init ...
> +
> + (void)platform_device_register(&olpc_rtc_device);
> +
> + device_init_wakeup(&olpc_rtc_device.dev, 1);
... do the init_wakeup before registering the device, so
there can never be confusion about whether a probe() will
see that part of device config ...
> +
> + return 0;
> +}
> +fs_initcall(olpc_rtc_init);
... and try to register platform devices in arch_initcall().
Just to avoid potential confusion; that's where it's normally
done, and I don't think you had a need to do it elsewhere.
- Dave
> +#endif /* CONFIG_RTC_DRV_CMOS */
> +
> static void olpc_pm_exit(void)
> {
> /* Clear any pending events, and disable them */
>
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: [PATCH] OLPC rtc-cmos support
2007-07-08 19:10 ` David Brownell
@ 2007-07-08 20:17 ` Marcelo Tosatti
2007-07-08 20:17 ` Marcelo Tosatti
1 sibling, 0 replies; 126+ messages in thread
From: Marcelo Tosatti @ 2007-07-08 20:17 UTC (permalink / raw)
To: David Brownell; +Cc: linux-pm, devel, linux-acpi
On Sun, Jul 08, 2007 at 12:10:50PM -0700, David Brownell wrote:
> On Sunday 08 July 2007, Marcelo Tosatti wrote:
>
> > Like this?
>
> Not quite ...
>
>
> > +struct resource rtc_platform_irq = {
> > + .flags = IORESOURCE_IRQ,
> > + .start = 8,
> > + .end = 8,
> > +};
>
> Unused, right?
>
>
> > +static int olpc_rtc_init(void)
>
> ... should be marked __init ...
>
> > +{
> > + rtc_info.rtc_day_alarm = 0;
> > + rtc_info.rtc_mon_alarm = 0;
> > + rtc_info.rtc_century = 0;
> > + rtc_info.wake_on = rtc_wake_on;
> > + rtc_info.wake_off = rtc_wake_off;
>
> ... that can all just be static init ...
>
> > +
> > + (void)platform_device_register(&olpc_rtc_device);
> > +
> > + device_init_wakeup(&olpc_rtc_device.dev, 1);
>
> ... do the init_wakeup before registering the device, so
> there can never be confusion about whether a probe() will
> see that part of device config ...
For some reason doing things in that order causes wake_on/wake_off
to not be called...
Thanks again for the comments.
diff --git a/arch/i386/kernel/olpc-pm.c b/arch/i386/kernel/olpc-pm.c
index 9599dbe..474be1a 100644
--- a/arch/i386/kernel/olpc-pm.c
+++ b/arch/i386/kernel/olpc-pm.c
@@ -11,6 +11,9 @@ #include <linux/delay.h>
#include <linux/input.h>
#include <linux/suspend.h>
#include <linux/bootmem.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+#include <linux/mc146818rtc.h>
#include <asm/io.h>
#include <asm/olpc.h>
@@ -272,6 +275,8 @@ static int olpc_pm_enter(suspend_state_t
return 0;
}
+static u16 olpc_wakeup_mask = CS5536_PM_PWRBTN;
+
int asmlinkage olpc_do_sleep(u8 sleep_state)
{
void *pgd_addr = __va(read_cr3());
@@ -282,7 +287,7 @@ int asmlinkage olpc_do_sleep(u8 sleep_st
/* FIXME: Set any other SCI events that we might want here */
- outl((CS5536_PM_PWRBTN << 16) | 0xFFFF, acpi_base + PM1_STS);
+ outl((olpc_wakeup_mask << 16) | 0xFFFF, acpi_base + PM1_STS);
/* If we are in test mode, then just return (simulate a successful
suspend/resume). Otherwise, if we are doing the real thing,
@@ -549,6 +554,59 @@ static int __init olpc_pm_init(void)
return 0;
}
+
+#if defined (CONFIG_RTC_DRV_CMOS) || defined (CONFIG_RTC_DRV_CMOS_MODULE)
+struct resource rtc_platform_resource[2] = {
+ {
+ .flags = IORESOURCE_IO,
+ .start = RTC_PORT(0),
+ .end = RTC_PORT(0) + RTC_IO_EXTENT
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ .start = 8,
+ .end = 8,
+ },
+};
+
+
+static void rtc_wake_on(struct device *dev)
+{
+ olpc_wakeup_mask |= CS5536_PM_RTC;
+}
+
+static void rtc_wake_off(struct device *dev)
+{
+ olpc_wakeup_mask &= ~(CS5536_PM_RTC);
+}
+
+static struct cmos_rtc_board_info rtc_info = {
+ .rtc_day_alarm = 0,
+ .rtc_mon_alarm = 0,
+ .rtc_century = 0,
+ .wake_on = rtc_wake_on,
+ .wake_off = rtc_wake_off,
+};
+
+struct platform_device olpc_rtc_device = {
+ .name = "rtc_cmos",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(rtc_platform_resource),
+ .dev.platform_data = &rtc_info,
+ .resource = rtc_platform_resource,
+};
+
+static int __init olpc_rtc_init(void)
+{
+ (void)platform_device_register(&olpc_rtc_device);
+
+ device_init_wakeup(&olpc_rtc_device.dev, 1);
+
+ return 0;
+}
+arch_initcall(olpc_rtc_init);
+#endif /* CONFIG_RTC_DRV_CMOS */
+
static void olpc_pm_exit(void)
{
/* Clear any pending events, and disable them */
^ permalink raw reply related [flat|nested] 126+ messages in thread* Re: [PATCH] OLPC rtc-cmos support
2007-07-08 19:10 ` David Brownell
2007-07-08 20:17 ` Marcelo Tosatti
@ 2007-07-08 20:17 ` Marcelo Tosatti
2007-07-08 20:47 ` David Brownell
2007-07-08 20:47 ` David Brownell
1 sibling, 2 replies; 126+ messages in thread
From: Marcelo Tosatti @ 2007-07-08 20:17 UTC (permalink / raw)
To: David Brownell; +Cc: linux-pm, devel, linux-acpi
On Sun, Jul 08, 2007 at 12:10:50PM -0700, David Brownell wrote:
> On Sunday 08 July 2007, Marcelo Tosatti wrote:
>
> > Like this?
>
> Not quite ...
>
>
> > +struct resource rtc_platform_irq = {
> > + .flags = IORESOURCE_IRQ,
> > + .start = 8,
> > + .end = 8,
> > +};
>
> Unused, right?
>
>
> > +static int olpc_rtc_init(void)
>
> ... should be marked __init ...
>
> > +{
> > + rtc_info.rtc_day_alarm = 0;
> > + rtc_info.rtc_mon_alarm = 0;
> > + rtc_info.rtc_century = 0;
> > + rtc_info.wake_on = rtc_wake_on;
> > + rtc_info.wake_off = rtc_wake_off;
>
> ... that can all just be static init ...
>
> > +
> > + (void)platform_device_register(&olpc_rtc_device);
> > +
> > + device_init_wakeup(&olpc_rtc_device.dev, 1);
>
> ... do the init_wakeup before registering the device, so
> there can never be confusion about whether a probe() will
> see that part of device config ...
For some reason doing things in that order causes wake_on/wake_off
to not be called...
Thanks again for the comments.
diff --git a/arch/i386/kernel/olpc-pm.c b/arch/i386/kernel/olpc-pm.c
index 9599dbe..474be1a 100644
--- a/arch/i386/kernel/olpc-pm.c
+++ b/arch/i386/kernel/olpc-pm.c
@@ -11,6 +11,9 @@ #include <linux/delay.h>
#include <linux/input.h>
#include <linux/suspend.h>
#include <linux/bootmem.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+#include <linux/mc146818rtc.h>
#include <asm/io.h>
#include <asm/olpc.h>
@@ -272,6 +275,8 @@ static int olpc_pm_enter(suspend_state_t
return 0;
}
+static u16 olpc_wakeup_mask = CS5536_PM_PWRBTN;
+
int asmlinkage olpc_do_sleep(u8 sleep_state)
{
void *pgd_addr = __va(read_cr3());
@@ -282,7 +287,7 @@ int asmlinkage olpc_do_sleep(u8 sleep_st
/* FIXME: Set any other SCI events that we might want here */
- outl((CS5536_PM_PWRBTN << 16) | 0xFFFF, acpi_base + PM1_STS);
+ outl((olpc_wakeup_mask << 16) | 0xFFFF, acpi_base + PM1_STS);
/* If we are in test mode, then just return (simulate a successful
suspend/resume). Otherwise, if we are doing the real thing,
@@ -549,6 +554,59 @@ static int __init olpc_pm_init(void)
return 0;
}
+
+#if defined (CONFIG_RTC_DRV_CMOS) || defined (CONFIG_RTC_DRV_CMOS_MODULE)
+struct resource rtc_platform_resource[2] = {
+ {
+ .flags = IORESOURCE_IO,
+ .start = RTC_PORT(0),
+ .end = RTC_PORT(0) + RTC_IO_EXTENT
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ .start = 8,
+ .end = 8,
+ },
+};
+
+
+static void rtc_wake_on(struct device *dev)
+{
+ olpc_wakeup_mask |= CS5536_PM_RTC;
+}
+
+static void rtc_wake_off(struct device *dev)
+{
+ olpc_wakeup_mask &= ~(CS5536_PM_RTC);
+}
+
+static struct cmos_rtc_board_info rtc_info = {
+ .rtc_day_alarm = 0,
+ .rtc_mon_alarm = 0,
+ .rtc_century = 0,
+ .wake_on = rtc_wake_on,
+ .wake_off = rtc_wake_off,
+};
+
+struct platform_device olpc_rtc_device = {
+ .name = "rtc_cmos",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(rtc_platform_resource),
+ .dev.platform_data = &rtc_info,
+ .resource = rtc_platform_resource,
+};
+
+static int __init olpc_rtc_init(void)
+{
+ (void)platform_device_register(&olpc_rtc_device);
+
+ device_init_wakeup(&olpc_rtc_device.dev, 1);
+
+ return 0;
+}
+arch_initcall(olpc_rtc_init);
+#endif /* CONFIG_RTC_DRV_CMOS */
+
static void olpc_pm_exit(void)
{
/* Clear any pending events, and disable them */
^ permalink raw reply related [flat|nested] 126+ messages in thread* Re: [PATCH] OLPC rtc-cmos support
2007-07-08 20:17 ` Marcelo Tosatti
@ 2007-07-08 20:47 ` David Brownell
2007-07-08 20:47 ` David Brownell
1 sibling, 0 replies; 126+ messages in thread
From: David Brownell @ 2007-07-08 20:47 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Jordan Crouse, linux-acpi, linux-pm, devel
> > > + (void)platform_device_register(&olpc_rtc_device);
> > > +
> > > + device_init_wakeup(&olpc_rtc_device.dev, 1);
> >
> > ... do the init_wakeup before registering the device, so
> > there can never be confusion about whether a probe() will
> > see that part of device config ...
>
> For some reason doing things in that order causes wake_on/wake_off
> to not be called...
I see ... because platform_device_register() will device_initialize()
which clobbers that state, before doing platform_device_add(). I
wonder what bugs are lurking thereby. :(
> Thanks again for the comments.
This last version looks clean and OK, so long as the driver registers
after that arch_initcall().
Really, no day field in the alarm for that particular southbridge?
Too bad. And a bit surprising ... I thought current versions of
ACPI required the up-to-one-month enhancement to mc146818.
- Dave
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [PATCH] OLPC rtc-cmos support
2007-07-08 20:17 ` Marcelo Tosatti
2007-07-08 20:47 ` David Brownell
@ 2007-07-08 20:47 ` David Brownell
1 sibling, 0 replies; 126+ messages in thread
From: David Brownell @ 2007-07-08 20:47 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-pm, devel, linux-acpi
> > > + (void)platform_device_register(&olpc_rtc_device);
> > > +
> > > + device_init_wakeup(&olpc_rtc_device.dev, 1);
> >
> > ... do the init_wakeup before registering the device, so
> > there can never be confusion about whether a probe() will
> > see that part of device config ...
>
> For some reason doing things in that order causes wake_on/wake_off
> to not be called...
I see ... because platform_device_register() will device_initialize()
which clobbers that state, before doing platform_device_add(). I
wonder what bugs are lurking thereby. :(
> Thanks again for the comments.
This last version looks clean and OK, so long as the driver registers
after that arch_initcall().
Really, no day field in the alarm for that particular southbridge?
Too bad. And a bit surprising ... I thought current versions of
ACPI required the up-to-one-month enhancement to mc146818.
- Dave
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [PATCH] OLPC rtc-cmos support
2007-07-08 5:13 ` David Brownell
2007-07-08 18:40 ` Marcelo Tosatti
@ 2007-07-08 18:40 ` Marcelo Tosatti
1 sibling, 0 replies; 126+ messages in thread
From: Marcelo Tosatti @ 2007-07-08 18:40 UTC (permalink / raw)
To: David Brownell; +Cc: linux-pm, devel, linux-acpi
On Sat, Jul 07, 2007 at 10:13:40PM -0700, David Brownell wrote:
> On Saturday 07 July 2007, Marcelo Tosatti wrote:
> >
> > Hi,
> >
> > The following patch implements the hooks necessary for OLPC to use the
> > rtc-cmos driver. This is necessary since we do not want CONFIG_PNP.
> >
> > This makes it possible to control rtc wakeup via
> > /sys/devices/platform/rtc_cmos/power/wakeup.
> >
> > Comments?
>
> Looks almost right ... though I'd have expected the RTC to
> support alarms more than just 24 hours into the future!
>
> It's more complicated than necessary. It'd be much simpler
> to just declare a static platform_device with pre-initted
> platform_data. Then call device_init_wakeup() on that before
> calling the usual platform_device_register() routine.
>
> That way you wouldn't need to have two different init sections
> just to set up one device, where one of them is spending most
> of its time working around the possibility that the other one
> failed. And you'd also pretty much eliminate the possibility
> that the (now) single init section fails. :)
David,
Like this?
diff --git a/arch/i386/kernel/olpc-pm.c b/arch/i386/kernel/olpc-pm.c
index 9599dbe..8072e68 100644
--- a/arch/i386/kernel/olpc-pm.c
+++ b/arch/i386/kernel/olpc-pm.c
@@ -11,6 +11,9 @@ #include <linux/delay.h>
#include <linux/input.h>
#include <linux/suspend.h>
#include <linux/bootmem.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+#include <linux/mc146818rtc.h>
#include <asm/io.h>
#include <asm/olpc.h>
@@ -272,6 +275,8 @@ static int olpc_pm_enter(suspend_state_t
return 0;
}
+static u16 olpc_wakeup_mask = CS5536_PM_PWRBTN;
+
int asmlinkage olpc_do_sleep(u8 sleep_state)
{
void *pgd_addr = __va(read_cr3());
@@ -282,7 +287,7 @@ int asmlinkage olpc_do_sleep(u8 sleep_st
/* FIXME: Set any other SCI events that we might want here */
- outl((CS5536_PM_PWRBTN << 16) | 0xFFFF, acpi_base + PM1_STS);
+ outl((olpc_wakeup_mask << 16) | 0xFFFF, acpi_base + PM1_STS);
/* If we are in test mode, then just return (simulate a successful
suspend/resume). Otherwise, if we are doing the real thing,
@@ -549,6 +554,65 @@ static int __init olpc_pm_init(void)
return 0;
}
+
+#if defined (CONFIG_RTC_DRV_CMOS) || defined (CONFIG_RTC_DRV_CMOS_MODULE)
+struct resource rtc_platform_resource[2] = {
+ {
+ .flags = IORESOURCE_IO,
+ .start = RTC_PORT(0),
+ .end = RTC_PORT(0) + RTC_IO_EXTENT
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ .start = 8,
+ .end = 8,
+ },
+};
+
+
+static struct cmos_rtc_board_info rtc_info;
+
+struct platform_device olpc_rtc_device = {
+ .name = "rtc_cmos",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(rtc_platform_resource),
+ .dev.platform_data = &rtc_info,
+ .resource = rtc_platform_resource,
+};
+
+struct resource rtc_platform_irq = {
+ .flags = IORESOURCE_IRQ,
+ .start = 8,
+ .end = 8,
+};
+
+static void rtc_wake_on(struct device *dev)
+{
+ olpc_wakeup_mask |= CS5536_PM_RTC;
+}
+
+static void rtc_wake_off(struct device *dev)
+{
+ olpc_wakeup_mask &= ~(CS5536_PM_RTC);
+}
+
+static int olpc_rtc_init(void)
+{
+ rtc_info.rtc_day_alarm = 0;
+ rtc_info.rtc_mon_alarm = 0;
+ rtc_info.rtc_century = 0;
+ rtc_info.wake_on = rtc_wake_on;
+ rtc_info.wake_off = rtc_wake_off;
+
+ (void)platform_device_register(&olpc_rtc_device);
+
+ device_init_wakeup(&olpc_rtc_device.dev, 1);
+
+ return 0;
+}
+fs_initcall(olpc_rtc_init);
+#endif /* CONFIG_RTC_DRV_CMOS */
+
static void olpc_pm_exit(void)
{
/* Clear any pending events, and disable them */
^ permalink raw reply related [flat|nested] 126+ messages in thread
* Re: [PATCH] OLPC rtc-cmos support
2007-07-08 3:55 ` [PATCH] OLPC rtc-cmos support Marcelo Tosatti
2007-07-08 5:13 ` David Brownell
@ 2007-07-08 5:13 ` David Brownell
1 sibling, 0 replies; 126+ messages in thread
From: David Brownell @ 2007-07-08 5:13 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-pm, devel, linux-acpi
On Saturday 07 July 2007, Marcelo Tosatti wrote:
>
> Hi,
>
> The following patch implements the hooks necessary for OLPC to use the
> rtc-cmos driver. This is necessary since we do not want CONFIG_PNP.
>
> This makes it possible to control rtc wakeup via
> /sys/devices/platform/rtc_cmos/power/wakeup.
>
> Comments?
Looks almost right ... though I'd have expected the RTC to
support alarms more than just 24 hours into the future!
It's more complicated than necessary. It'd be much simpler
to just declare a static platform_device with pre-initted
platform_data. Then call device_init_wakeup() on that before
calling the usual platform_device_register() routine.
That way you wouldn't need to have two different init sections
just to set up one device, where one of them is spending most
of its time working around the possibility that the other one
failed. And you'd also pretty much eliminate the possibility
that the (now) single init section fails. :)
- Dave
^ permalink raw reply [flat|nested] 126+ messages in thread
* [PATCH] OLPC rtc-cmos support
2007-04-02 16:55 ` Jordan Crouse
` (6 preceding siblings ...)
2007-07-08 3:55 ` [PATCH] OLPC rtc-cmos support Marcelo Tosatti
@ 2007-07-08 3:55 ` Marcelo Tosatti
7 siblings, 0 replies; 126+ messages in thread
From: Marcelo Tosatti @ 2007-07-08 3:55 UTC (permalink / raw)
To: David Brownell; +Cc: linux-pm, devel, linux-acpi
Hi,
The following patch implements the hooks necessary for OLPC to use the
rtc-cmos driver. This is necessary since we do not want CONFIG_PNP.
This makes it possible to control rtc wakeup via
/sys/devices/platform/rtc_cmos/power/wakeup.
Comments?
diff --git a/arch/i386/kernel/olpc-pm.c b/arch/i386/kernel/olpc-pm.c
index 9599dbe..d92c54a 100644
--- a/arch/i386/kernel/olpc-pm.c
+++ b/arch/i386/kernel/olpc-pm.c
@@ -11,6 +11,9 @@ #include <linux/delay.h>
#include <linux/input.h>
#include <linux/suspend.h>
#include <linux/bootmem.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+#include <linux/mc146818rtc.h>
#include <asm/io.h>
#include <asm/olpc.h>
@@ -272,6 +275,8 @@ static int olpc_pm_enter(suspend_state_t
return 0;
}
+static u16 olpc_wakeup_mask = CS5536_PM_PWRBTN;
+
int asmlinkage olpc_do_sleep(u8 sleep_state)
{
void *pgd_addr = __va(read_cr3());
@@ -282,7 +287,7 @@ int asmlinkage olpc_do_sleep(u8 sleep_st
/* FIXME: Set any other SCI events that we might want here */
- outl((CS5536_PM_PWRBTN << 16) | 0xFFFF, acpi_base + PM1_STS);
+ outl((olpc_wakeup_mask << 16) | 0xFFFF, acpi_base + PM1_STS);
/* If we are in test mode, then just return (simulate a successful
suspend/resume). Otherwise, if we are doing the real thing,
@@ -549,6 +554,92 @@ static int __init olpc_pm_init(void)
return 0;
}
+
+#if defined (CONFIG_RTC_DRV_CMOS) || defined (CONFIG_RTC_DRV_CMOS_MODULE)
+struct resource rtc_platform_resource[2] = {
+ {
+ .flags = IORESOURCE_IO,
+ .start = RTC_PORT(0),
+ .end = RTC_PORT(0) + RTC_IO_EXTENT
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ .start = 8,
+ .end = 8,
+ },
+};
+
+struct resource rtc_platform_irq = {
+ .flags = IORESOURCE_IRQ,
+ .start = 8,
+ .end = 8,
+};
+
+static int olpc_add_rtc(void)
+{
+ struct platform_device *pd;
+
+ pd = platform_device_register_simple("rtc_cmos", -1,
+ rtc_platform_resource, 2);
+ if (IS_ERR(pd))
+ return PTR_ERR(pd);
+
+ /* rtc-cmos only supports 24-hr mode */
+ CMOS_WRITE(CMOS_READ(RTC_CONTROL) | RTC_24H, RTC_CONTROL);
+
+ return 0;
+}
+arch_initcall(olpc_add_rtc);
+
+static struct cmos_rtc_board_info rtc_info;
+
+static void rtc_wake_on(struct device *dev)
+{
+ olpc_wakeup_mask |= CS5536_PM_RTC;
+}
+
+static void rtc_wake_off(struct device *dev)
+{
+ olpc_wakeup_mask &= ~(CS5536_PM_RTC);
+}
+
+static int rtc_match(struct device *dev, void *data)
+{
+ static const char *devname = { "rtc_cmos" };
+ struct rtc_device *rtcdev = to_rtc_device(dev);
+
+ if (!strcmp(devname, rtcdev->name))
+ return 1;
+
+ return 0;
+}
+
+static struct device * get_rtc_dev(void)
+{
+ return bus_find_device(&platform_bus_type, NULL, NULL, rtc_match);
+}
+
+static int olpc_rtc_init(void)
+{
+ struct device *dev = get_rtc_dev();
+
+ if (dev) {
+ rtc_info.rtc_day_alarm = 0;
+ rtc_info.rtc_mon_alarm = 0;
+ rtc_info.rtc_century = 0;
+ rtc_info.wake_on = rtc_wake_on;
+ rtc_info.wake_off = rtc_wake_off;
+
+ dev->platform_data = &rtc_info;
+
+ device_init_wakeup(dev, 1);
+ } else
+ printk(KERN_ERR "no rtc\n");
+ return 0;
+}
+fs_initcall(olpc_rtc_init);
+#endif /* CONFIG_RTC_DRV_CMOS */
+
static void olpc_pm_exit(void)
{
/* Clear any pending events, and disable them */
^ permalink raw reply related [flat|nested] 126+ messages in thread