On Thu 2007-01-25 18:12:20, Len Brown wrote:
On Thursday 25 January 2007 14:47, Pavel Machek wrote:
Hi!
Note that a few RTCs ignore rtc_wkalrm.enabled when setting alarms, or
aren't set up correctly, so they won't yet behave with this attribute.
Signed-off-by: David Brownell
Hi!
Note that a few RTCs ignore rtc_wkalrm.enabled when setting alarms, or
aren't set up correctly, so they won't yet behave with this attribute.
Signed-off-by: David Brownell [EMAIL PROTECTED]
How do I ask to wake up as soon as possible?
If you want to wake up ASAP, don't go to
On Thursday 25 January 2007 14:47, Pavel Machek wrote:
Hi!
Note that a few RTCs ignore rtc_wkalrm.enabled when setting alarms, or
aren't set up correctly, so they won't yet behave with this attribute.
Signed-off-by: David Brownell [EMAIL PROTECTED]
How do I ask to wake up as
Hi.
On Thu, 2007-01-25 at 18:12 -0500, Len Brown wrote:
On Thursday 25 January 2007 14:47, Pavel Machek wrote:
Hi!
Note that a few RTCs ignore rtc_wkalrm.enabled when setting alarms, or
aren't set up correctly, so they won't yet behave with this attribute.
Signed-off-by:
On Sunday 07 January 2007 22:44, David Brownell wrote:
On Sunday 07 January 2007 3:19 am, Pavel Machek wrote:
Create /sys/power/alarm.
The way it works is exactly the same as /proc/acpi/alarm.
I.e. #echo -mm-dd hh-mm-ss /sys/power/alarm supports existing
absolute time.
And
On Sun, Jan 07, 2007 at 06:31:17PM -0800, David Brownell wrote:
On Saturday 06 January 2007 9:57 pm, Matthew Garrett wrote:
Especially since /proc/acpi/alarm is just banging on the RTC registers
- the only ACPI thing about it is that the FADT can expose whether or
not the extended
Thanks for your attention.
On Sun, 2007-01-07 at 18:31 -0800, David Brownell wrote:
On Saturday 06 January 2007 9:57 pm, Matthew Garrett wrote:
On Sat, Jan 06, 2007 at 02:42:22PM -0800, David Brownell wrote:
On Saturday 06 January 2007 3:35 am, Zhang Rui wrote:
Create
Hi!
Create /sys/power/alarm.
The way it works is exactly the same as /proc/acpi/alarm.
I.e. #echo -mm-dd hh-mm-ss /sys/power/alarm supports existing
absolute time.
And #echo +-mm-dd hh-mm-ss /sys/power/alarm supports a duration.
NAK. /proc/acpi/alarm is a mess, and
On Monday 08 January 2007 3:36 am, Pavel Machek wrote:
What about periodic alarms?
So far as I'm concerned they're not part of the API. The periodicity notion
of the alarm on PC RTCs is pretty bizarre if you look at it ... not portable
to much non-PC hardware (without extremely ugly hacks
The FADT also exposes whether the RTC can wake from S4. You may have
noticed that my rtc-cmos patch #3 exported the relevant FADT info
to the RTC device using platform_data, but the S4 wake capability flag
isn't useful for anything on today's Linux.
Isn't useful in what way? It'd be
On Mon, Jan 08, 2007 at 12:39:08PM -0800, David Brownell wrote:
In that current API there's no way to tell anything at all about the
target system state inside a driver's suspend() method. So if there
were some characteristic of S4 (or S3 etc) that mattered to the driver
(it should test for
On Monday 08 January 2007 2:13 am, Zhang Rui wrote:
Errr, I never met this multiple RTCs situation before and it's true
that /sys/power/alarm can not handle multiple RTCs.
I don't know why they are needed, maybe for the embedded system?
Yes.
Could you provide me more details about this
On Monday 08 January 2007 12:43 pm, Matthew Garrett wrote:
On Mon, Jan 08, 2007 at 12:39:08PM -0800, David Brownell wrote:
In that current API there's no way to tell anything at all about the
target system state inside a driver's suspend() method. So if there
were some characteristic of
Hi!
Create /sys/power/alarm.
The way it works is exactly the same as /proc/acpi/alarm.
I.e. #echo -mm-dd hh-mm-ss /sys/power/alarm supports existing absolute
time.
And #echo +-mm-dd hh-mm-ss /sys/power/alarm supports a duration.
NAK. /proc/acpi/alarm is a mess, and this just moves
On Saturday 06 January 2007 9:57 pm, Matthew Garrett wrote:
On Sat, Jan 06, 2007 at 02:42:22PM -0800, David Brownell wrote:
On Saturday 06 January 2007 3:35 am, Zhang Rui wrote:
Create /sys/power/alarm.
Urg. This doesn't work with the RTC framework, which accepts the reality
that
On Sunday 07 January 2007 3:19 am, Pavel Machek wrote:
Create /sys/power/alarm.
The way it works is exactly the same as /proc/acpi/alarm.
I.e. #echo -mm-dd hh-mm-ss /sys/power/alarm supports existing
absolute time.
And #echo +-mm-dd hh-mm-ss /sys/power/alarm supports a
On Saturday 06 January 2007 3:35 am, Zhang Rui wrote:
Create /sys/power/alarm.
Urg. This doesn't work with the RTC framework, which accepts the reality
that some systems have multiple RTCs ... /sys/class/rtc/rtcN/alarm is a
much more appropriate location for that RTC's alarm.
(How to handle
On Sat, Jan 06, 2007 at 02:42:22PM -0800, David Brownell wrote:
On Saturday 06 January 2007 3:35 am, Zhang Rui wrote:
Create /sys/power/alarm.
Urg. This doesn't work with the RTC framework, which accepts the reality
that some systems have multiple RTCs ... /sys/class/rtc/rtcN/alarm is a
18 matches
Mail list logo
