2019-05-27 14:55:01 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
/*
|
|
|
|
* RTC class driver for "CMOS RTC": PCs, ACPI, etc
|
|
|
|
*
|
|
|
|
* Copyright (C) 1996 Paul Gortmaker (drivers/char/rtc.c)
|
|
|
|
* Copyright (C) 2006 David Brownell (convert to new framework)
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The original "cmos clock" chip was an MC146818 chip, now obsolete.
|
|
|
|
* That defined the register interface now provided by all PCs, some
|
|
|
|
* non-PC systems, and incorporated into ACPI. Modern PC chipsets
|
|
|
|
* integrate an MC146818 clone in their southbridge, and boards use
|
|
|
|
* that instead of discrete clones like the DS12887 or M48T86. There
|
|
|
|
* are also clones that connect using the LPC bus.
|
|
|
|
*
|
|
|
|
* That register API is also used directly by various other drivers
|
|
|
|
* (notably for integrated NVRAM), infrastructure (x86 has code to
|
|
|
|
* bypass the RTC framework, directly reading the RTC during boot
|
|
|
|
* and updating minutes/seconds for systems using NTP synch) and
|
|
|
|
* utilities (like userspace 'hwclock', if no /dev node exists).
|
|
|
|
*
|
|
|
|
* So **ALL** calls to CMOS_READ and CMOS_WRITE must be done with
|
|
|
|
* interrupts disabled, holding the global rtc_lock, to exclude those
|
|
|
|
* other drivers and utilities on correctly configured systems.
|
|
|
|
*/
|
2015-04-17 03:46:14 +08:00
|
|
|
|
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/interrupt.h>
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/platform_device.h>
|
2009-01-07 06:42:12 +08:00
|
|
|
#include <linux/log2.h>
|
2011-01-13 09:00:07 +08:00
|
|
|
#include <linux/pm.h>
|
2011-02-23 04:07:46 +08:00
|
|
|
#include <linux/of.h>
|
|
|
|
#include <linux/of_platform.h>
|
2017-03-18 21:45:49 +08:00
|
|
|
#ifdef CONFIG_X86
|
|
|
|
#include <asm/i8259.h>
|
2018-03-26 21:58:03 +08:00
|
|
|
#include <asm/processor.h>
|
|
|
|
#include <linux/dmi.h>
|
2017-03-18 21:45:49 +08:00
|
|
|
#endif
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
|
|
|
/* this is for "generic access to PC-style RTC" using CMOS_READ/CMOS_WRITE */
|
2016-05-31 02:57:50 +08:00
|
|
|
#include <linux/mc146818rtc.h>
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
2018-10-02 09:09:05 +08:00
|
|
|
#ifdef CONFIG_ACPI
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
/*
|
|
|
|
* Use ACPI SCI to replace HPET interrupt for RTC Alarm event
|
|
|
|
*
|
|
|
|
* If cleared, ACPI SCI is only used to wake up the system from suspend
|
|
|
|
*
|
|
|
|
* If set, ACPI SCI is used to handle UIE/AIE and system wakeup
|
|
|
|
*/
|
|
|
|
|
|
|
|
static bool use_acpi_alarm;
|
|
|
|
module_param(use_acpi_alarm, bool, 0444);
|
|
|
|
|
2018-10-02 09:09:05 +08:00
|
|
|
static inline int cmos_use_acpi_alarm(void)
|
|
|
|
{
|
|
|
|
return use_acpi_alarm;
|
|
|
|
}
|
|
|
|
#else /* !CONFIG_ACPI */
|
|
|
|
|
|
|
|
static inline int cmos_use_acpi_alarm(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
struct cmos_rtc {
|
|
|
|
struct rtc_device *rtc;
|
|
|
|
struct device *dev;
|
|
|
|
int irq;
|
|
|
|
struct resource *iomem;
|
rtc: cmos: Cancel alarm timer if alarm time is equal to now+1 seconds
Steps to reproduce the problem:
1) Enable RTC wake-up option in BIOS Setup
2) Issue one of these commands in the OS: "poweroff"
or "shutdown -h now"
3) System will shut down and then reboot automatically
Root-cause of the issue:
1) During the shutdown process, the hwclock utility is used
to save the system clock to hardware clock (RTC).
2) The hwclock utility invokes ioctl() with RTC_UIE_ON. The
kernel configures the RTC alarm for the periodic interrupt
(every 1 second).
3) The hwclock uitlity closes the /dev/rtc0 device, and the
kernel disables the RTC alarm irq (AIE bit of Register B)
via ioctl() with RTC_UIE_OFF. But, the configured alarm
time is the current_time + 1.
4) After the next 1 second is elapsed, the AF (alarm
interrupt flag) of Register C is set.
5) The S5 handler in BIOS is invoked to configure alarm
registers (enable AIE bit and configure alarm date/time).
But, BIOS does not clear the previous interrupt status
during alarm configuration. Therefore, "AF=AIE=1" causes
the rtc device to trigger an interrupt.
6) So, the machine reboots automatically right after shutdown.
This patch cancels the alarm timer if the following condictions are
met (suggested by Alexandre):
1) The configured alarm time is equal to current_time + 1
seconds.
2) The AIE timer is not in use.
The member 'alarm_expires' is introduced in struct cmos_rtc because
of the following reasons:
1) The configured alarm time can be retrieved from
cmos_read_alarm(), but we need to take the 'wrapped
timestamp' and 'time rollover' into consideration. The
function __rtc_read_alarm() eliminates the concerns. To
avoid the duplicated code in the lower level RTC driver,
invoking __rtc_read_alarm from the lower level RTC driver
is not encouraged. Moreover, the compilation error 'the
undefined __rtc_read_alarm" is observed if the lower level
RTC driver is compiled as a kernel module.
2) The uie_rtctimer.node.expires and aie_timer.node.expires can
be retrieved for the configured alarm time. But, the problem
is that either of them might configure the CMOS alarm time.
We cannot make sure UIE timer or AIE tiemr configured the
CMOS alarm time before. (uie_rtctimer or aie_timer is enabled
and then is disabled).
3) The patch introduces the member 'alarm_expires' to keep the
newly configured alarm time, so the above-mentioned concerns
can be eliminated.
The issue goes away after 20-time shutdown tests.
Signed-off-by: Adrian Huang <ahuang12@lenovo.com>
Tested-by: Egbert Eich <eich@suse.de>
Tested-by: Diego Ercolani <diego.ercolani@gmail.com>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2015-07-06 12:19:12 +08:00
|
|
|
time64_t alarm_expires;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
rtc-cmos wakeup interface
I finally got around to testing the updated wakeup event hooks for rtc-cmos,
and they follow in two patches:
- Interface update ... when a simple enable_irq_wake() doesn't suffice,
the platform data can hold suspend/resume callback hooks.
- ACPI implementation ... provides callback hooks to do ACPI magic, and
eliminate the legacy /proc/acpi/alarm file.
The interface update could go into 2.6.21, but that's not essential; they
will be NOPs on most PCs, without the ACPI stuff.
I suspect the ACPI folk may have opinions about how to merge that second
patch, and how to obsolete that legacy procfs file. I'd like to see that
merge into 2.6.22 if possible...
As for how to kick it in ... two ways:
- The appended "rtcwake" program; updated since the last time it was
posted, it deals much better with timezones and DST.
- Write the /sys/class/rtc/.../wakealarm file, then go to sleep.
For some reason RTC wake from "swsusp" stopped working on a system where
it previously worked; the alarm setting appears to get clobbered. But
on the bright side, RTC wake from "standby" worked on a system that had
never been able to resume from that state before ... IDEACPI is my guess
as to why it finally started to work. It's the old "two steps forward,
one step back" dance, I guess.
- Dave
/* gcc -Wall -Os -o rtcwake rtcwake.c */
#include <stdio.h>
#include <getopt.h>
#include <fcntl.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <time.h>
#include <sys/ioctl.h>
#include <sys/time.h>
#include <sys/types.h>
#include <linux/rtc.h>
/* constants from legacy PC/AT hardware */
#define RTC_PF 0x40
#define RTC_AF 0x20
#define RTC_UF 0x10
/*
* rtcwake -- enter a system sleep state until specified wakeup time.
*
* This uses cross-platform Linux interfaces to enter a system sleep state,
* and leave it no later than a specified time. It uses any RTC framework
* driver that supports standard driver model wakeup flags.
*
* This is normally used like the old "apmsleep" utility, to wake from a
* suspend state like ACPI S1 (standby) or S3 (suspend-to-RAM). Most
* platforms can implement those without analogues of BIOS, APM, or ACPI.
*
* On some systems, this can also be used like "nvram-wakeup", waking
* from states like ACPI S4 (suspend to disk). Not all systems have
* persistent media that are appropriate for such suspend modes.
*
* The best way to set the system's RTC is so that it holds the current
* time in UTC. Use the "-l" flag to tell this program that the system
* RTC uses a local timezone instead (maybe you dual-boot MS-Windows).
*/
static char *progname;
#ifdef DEBUG
#define VERSION "1.0 dev (" __DATE__ " " __TIME__ ")"
#else
#define VERSION "0.9"
#endif
static unsigned verbose;
static int rtc_is_utc = -1;
static int may_wakeup(const char *devname)
{
char buf[128], *s;
FILE *f;
snprintf(buf, sizeof buf, "/sys/class/rtc/%s/device/power/wakeup",
devname);
f = fopen(buf, "r");
if (!f) {
perror(buf);
return 0;
}
fgets(buf, sizeof buf, f);
fclose(f);
s = strchr(buf, '\n');
if (!s)
return 0;
*s = 0;
/* wakeup events could be disabled or not supported */
return strcmp(buf, "enabled") == 0;
}
/* all times should be in UTC */
static time_t sys_time;
static time_t rtc_time;
static int get_basetimes(int fd)
{
struct tm tm;
struct rtc_time rtc;
/* this process works in RTC time, except when working
* with the system clock (which always uses UTC).
*/
if (rtc_is_utc)
setenv("TZ", "UTC", 1);
tzset();
/* read rtc and system clocks "at the same time", or as
* precisely (+/- a second) as we can read them.
*/
if (ioctl(fd, RTC_RD_TIME, &rtc) < 0) {
perror("read rtc time");
return 0;
}
sys_time = time(0);
if (sys_time == (time_t)-1) {
perror("read system time");
return 0;
}
/* convert rtc_time to normal arithmetic-friendly form,
* updating tm.tm_wday as used by asctime().
*/
memset(&tm, 0, sizeof tm);
tm.tm_sec = rtc.tm_sec;
tm.tm_min = rtc.tm_min;
tm.tm_hour = rtc.tm_hour;
tm.tm_mday = rtc.tm_mday;
tm.tm_mon = rtc.tm_mon;
tm.tm_year = rtc.tm_year;
tm.tm_isdst = rtc.tm_isdst; /* stays unspecified? */
rtc_time = mktime(&tm);
if (rtc_time == (time_t)-1) {
perror("convert rtc time");
return 0;
}
if (verbose) {
if (!rtc_is_utc) {
printf("\ttzone = %ld\n", timezone);
printf("\ttzname = %s\n", tzname[daylight]);
gmtime_r(&rtc_time, &tm);
}
printf("\tsystime = %ld, (UTC) %s",
(long) sys_time, asctime(gmtime(&sys_time)));
printf("\trtctime = %ld, (UTC) %s",
(long) rtc_time, asctime(&tm));
}
return 1;
}
static int setup_alarm(int fd, time_t *wakeup)
{
struct tm *tm;
struct rtc_wkalrm wake;
tm = gmtime(wakeup);
wake.time.tm_sec = tm->tm_sec;
wake.time.tm_min = tm->tm_min;
wake.time.tm_hour = tm->tm_hour;
wake.time.tm_mday = tm->tm_mday;
wake.time.tm_mon = tm->tm_mon;
wake.time.tm_year = tm->tm_year;
wake.time.tm_wday = tm->tm_wday;
wake.time.tm_yday = tm->tm_yday;
wake.time.tm_isdst = tm->tm_isdst;
/* many rtc alarms only support up to 24 hours from 'now' ... */
if ((rtc_time + (24 * 60 * 60)) > *wakeup) {
if (ioctl(fd, RTC_ALM_SET, &wake.time) < 0) {
perror("set rtc alarm");
return 0;
}
if (ioctl(fd, RTC_AIE_ON, 0) < 0) {
perror("enable rtc alarm");
return 0;
}
/* ... so use the "more than 24 hours" request only if we must */
} else {
/* avoid an extra AIE_ON call */
wake.enabled = 1;
if (ioctl(fd, RTC_WKALM_SET, &wake) < 0) {
perror("set rtc wake alarm");
return 0;
}
}
return 1;
}
static void suspend_system(const char *suspend)
{
FILE *f = fopen("/sys/power/state", "w");
if (!f) {
perror("/sys/power/state");
return;
}
fprintf(f, "%s\n", suspend);
fflush(f);
/* this executes after wake from suspend */
fclose(f);
}
int main(int argc, char **argv)
{
static char *devname = "rtc0";
static unsigned seconds = 0;
static char *suspend = "standby";
int t;
int fd;
time_t alarm = 0;
progname = strrchr(argv[0], '/');
if (progname)
progname++;
else
progname = argv[0];
if (chdir("/dev/") < 0) {
perror("chdir /dev");
return 1;
}
while ((t = getopt(argc, argv, "d:lm:s:t:uVv")) != EOF) {
switch (t) {
case 'd':
devname = optarg;
break;
case 'l':
rtc_is_utc = 0;
break;
/* what system power mode to use? for now handle only
* standardized mode names; eventually when systems define
* their own state names, parse /sys/power/state.
*
* "on" is used just to test the RTC alarm mechanism,
* bypassing all the wakeup-from-sleep infrastructure.
*/
case 'm':
if (strcmp(optarg, "standby") == 0
|| strcmp(optarg, "mem") == 0
|| strcmp(optarg, "disk") == 0
|| strcmp(optarg, "on") == 0
) {
suspend = optarg;
break;
}
printf("%s: unrecognized suspend state '%s'\n",
progname, optarg);
goto usage;
/* alarm time, seconds-to-sleep (relative) */
case 's':
t = atoi(optarg);
if (t < 0) {
printf("%s: illegal interval %s seconds\n",
progname, optarg);
goto usage;
}
seconds = t;
break;
/* alarm time, time_t (absolute, seconds since 1/1 1970 UTC) */
case 't':
t = atoi(optarg);
if (t < 0) {
printf("%s: illegal time_t value %s\n",
progname, optarg);
goto usage;
}
alarm = t;
break;
case 'u':
rtc_is_utc = 1;
break;
case 'v':
verbose++;
break;
case 'V':
printf("%s: version %s\n", progname, VERSION);
break;
default:
usage:
printf("usage: %s [options]"
"\n\t"
"-d rtc0|rtc1|...\t(select rtc)"
"\n\t"
"-l\t\t\t(RTC uses local timezone)"
"\n\t"
"-m standby|mem|...\t(sleep mode)"
"\n\t"
"-s seconds\t\t(seconds to sleep)"
"\n\t"
"-t time_t\t\t(time to wake)"
"\n\t"
"-u\t\t\t(RTC uses UTC)"
"\n\t"
"-v\t\t\t(verbose messages)"
"\n\t"
"-V\t\t\t(show version)"
"\n",
progname);
return 1;
}
}
if (!alarm && !seconds) {
printf("%s: must provide wake time\n", progname);
goto usage;
}
/* REVISIT: if /etc/adjtime exists, read it to see what
* the util-linux version of hwclock assumes.
*/
if (rtc_is_utc == -1) {
printf("%s: assuming RTC uses UTC ...\n", progname);
rtc_is_utc = 1;
}
/* this RTC must exist and (if we'll sleep) be wakeup-enabled */
fd = open(devname, O_RDONLY);
if (fd < 0) {
perror(devname);
return 1;
}
if (strcmp(suspend, "on") != 0 && !may_wakeup(devname)) {
printf("%s: %s not enabled for wakeup events\n",
progname, devname);
return 1;
}
/* relative or absolute alarm time, normalized to time_t */
if (!get_basetimes(fd))
return 1;
if (verbose)
printf("alarm %ld, sys_time %ld, rtc_time %ld, seconds %u\n",
alarm, sys_time, rtc_time, seconds);
if (alarm) {
if (alarm < sys_time) {
printf("%s: time doesn't go backward to %s",
progname, ctime(&alarm));
return 1;
}
alarm += sys_time - rtc_time;
} else
alarm = rtc_time + seconds + 1;
if (setup_alarm(fd, &alarm) < 0)
return 1;
sync();
printf("%s: wakeup from \"%s\" using %s at %s",
progname, suspend, devname,
ctime(&alarm));
fflush(stdout);
usleep(10 * 1000);
if (strcmp(suspend, "on") != 0)
suspend_system(suspend);
else {
unsigned long data;
do {
t = read(fd, &data, sizeof data);
if (t < 0) {
perror("rtc read");
break;
}
if (verbose)
printf("... %s: %03lx\n", devname, data);
} while (!(data & RTC_AF));
}
if (ioctl(fd, RTC_AIE_OFF, 0) < 0)
perror("disable rtc alarm interrupt");
close(fd);
return 0;
}
This patch:
Make rtc-cmos do the relevant magic so this RTC can wake the system from a
sleep state. That magic comes in two basic flavors:
- Straightforward: enable_irq_wake(), the way it'd work on most SOC chips;
or generally with system sleep states which don't disable core IRQ logic.
- Roundabout, using non-IRQ platform hooks. This is needed with ACPI and
one almost-clone chip which uses a special wakeup-only alarm. (That's
the RTC used on Footbridge boards, FWIW, which don't do PM in Linux.)
A separate patch implements those hooks for ACPI platforms, so that rtc_cmos
can issue system wakeup events (and its sysfs "wakealarm" attribute works on
at least some systems).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-08 15:34:00 +08:00
|
|
|
void (*wake_on)(struct device *);
|
|
|
|
void (*wake_off)(struct device *);
|
|
|
|
|
|
|
|
u8 enabled_wake;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
u8 suspend_ctrl;
|
|
|
|
|
|
|
|
/* newer hardware extends the original register set */
|
|
|
|
u8 day_alrm;
|
|
|
|
u8 mon_alrm;
|
|
|
|
u8 century;
|
2016-09-20 07:12:44 +08:00
|
|
|
|
|
|
|
struct rtc_wkalrm saved_wkalrm;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/* both platform and pnp busses use negative numbers for invalid irqs */
|
2009-01-07 06:42:11 +08:00
|
|
|
#define is_valid_irq(n) ((n) > 0)
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
|
|
|
static const char driver_name[] = "rtc_cmos";
|
|
|
|
|
2007-04-02 14:49:47 +08:00
|
|
|
/* The RTC_INTR register may have e.g. RTC_PF set even if RTC_PIE is clear;
|
|
|
|
* always mask it against the irq enable bits in RTC_CONTROL. Bit values
|
|
|
|
* are the same: PF==PIE, AF=AIE, UF=UIE; so RTC_IRQMASK works with both.
|
|
|
|
*/
|
|
|
|
#define RTC_IRQMASK (RTC_PF | RTC_AF | RTC_UF)
|
|
|
|
|
|
|
|
static inline int is_intr(u8 rtc_intr)
|
|
|
|
{
|
|
|
|
if (!(rtc_intr & RTC_IRQF))
|
|
|
|
return 0;
|
|
|
|
return rtc_intr & RTC_IRQMASK;
|
|
|
|
}
|
|
|
|
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
/*----------------------------------------------------------------*/
|
|
|
|
|
2008-07-24 12:30:43 +08:00
|
|
|
/* Much modern x86 hardware has HPETs (10+ MHz timers) which, because
|
|
|
|
* many BIOS programmers don't set up "sane mode" IRQ routing, are mostly
|
|
|
|
* used in a broken "legacy replacement" mode. The breakage includes
|
|
|
|
* HPET #1 hijacking the IRQ for this RTC, and being unavailable for
|
|
|
|
* other (better) use.
|
|
|
|
*
|
|
|
|
* When that broken mode is in use, platform glue provides a partial
|
|
|
|
* emulation of hardware RTC IRQ facilities using HPET #1. We don't
|
|
|
|
* want to use HPET for anything except those IRQs though...
|
|
|
|
*/
|
|
|
|
#ifdef CONFIG_HPET_EMULATE_RTC
|
|
|
|
#include <asm/hpet.h>
|
|
|
|
#else
|
|
|
|
|
|
|
|
static inline int is_hpet_enabled(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int hpet_mask_rtc_irq_bit(unsigned long mask)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int hpet_set_rtc_irq_bit(unsigned long mask)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
hpet_set_alarm_time(unsigned char hrs, unsigned char min, unsigned char sec)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int hpet_set_periodic_freq(unsigned long freq)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int hpet_rtc_dropped_irq(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int hpet_rtc_timer_init(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
extern irq_handler_t hpet_rtc_interrupt;
|
|
|
|
|
|
|
|
static inline int hpet_register_irq_handler(irq_handler_t handler)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int hpet_unregister_irq_handler(irq_handler_t handler)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
/* Don't use HPET for RTC Alarm event if ACPI Fixed event is used */
|
2018-10-02 09:08:49 +08:00
|
|
|
static inline int use_hpet_alarm(void)
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
{
|
2018-10-02 09:09:05 +08:00
|
|
|
return is_hpet_enabled() && !cmos_use_acpi_alarm();
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
}
|
|
|
|
|
2008-07-24 12:30:43 +08:00
|
|
|
/*----------------------------------------------------------------*/
|
|
|
|
|
2008-10-19 11:27:47 +08:00
|
|
|
#ifdef RTC_PORT
|
|
|
|
|
|
|
|
/* Most newer x86 systems have two register banks, the first used
|
|
|
|
* for RTC and NVRAM and the second only for NVRAM. Caller must
|
|
|
|
* own rtc_lock ... and we won't worry about access during NMI.
|
|
|
|
*/
|
|
|
|
#define can_bank2 true
|
|
|
|
|
|
|
|
static inline unsigned char cmos_read_bank2(unsigned char addr)
|
|
|
|
{
|
|
|
|
outb(addr, RTC_PORT(2));
|
|
|
|
return inb(RTC_PORT(3));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void cmos_write_bank2(unsigned char val, unsigned char addr)
|
|
|
|
{
|
|
|
|
outb(addr, RTC_PORT(2));
|
2012-01-11 07:10:26 +08:00
|
|
|
outb(val, RTC_PORT(3));
|
2008-10-19 11:27:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
#define can_bank2 false
|
|
|
|
|
|
|
|
static inline unsigned char cmos_read_bank2(unsigned char addr)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void cmos_write_bank2(unsigned char val, unsigned char addr)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*----------------------------------------------------------------*/
|
|
|
|
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
static int cmos_read_time(struct device *dev, struct rtc_time *t)
|
|
|
|
{
|
2021-12-11 04:01:25 +08:00
|
|
|
int ret;
|
|
|
|
|
2016-11-29 06:35:19 +08:00
|
|
|
/*
|
|
|
|
* If pm_trace abused the RTC for storage, set the timespec to 0,
|
|
|
|
* which tells the caller that this RTC value is unusable.
|
|
|
|
*/
|
|
|
|
if (!pm_trace_rtc_valid())
|
|
|
|
return -EIO;
|
|
|
|
|
2021-12-11 04:01:25 +08:00
|
|
|
ret = mc146818_get_time(t);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err_ratelimited(dev, "unable to read current time\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int cmos_set_time(struct device *dev, struct rtc_time *t)
|
|
|
|
{
|
2021-07-17 05:04:37 +08:00
|
|
|
/* NOTE: this ignores the issue whereby updating the seconds
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
* takes effect exactly 500ms after we write the register.
|
|
|
|
* (Also queueing and other delays before we get this far.)
|
|
|
|
*/
|
2016-05-31 02:57:50 +08:00
|
|
|
return mc146818_set_time(t);
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
}
|
|
|
|
|
2021-12-11 04:01:30 +08:00
|
|
|
struct cmos_read_alarm_callback_param {
|
|
|
|
struct cmos_rtc *cmos;
|
|
|
|
struct rtc_time *time;
|
|
|
|
unsigned char rtc_control;
|
|
|
|
};
|
|
|
|
|
|
|
|
static void cmos_read_alarm_callback(unsigned char __always_unused seconds,
|
|
|
|
void *param_in)
|
|
|
|
{
|
|
|
|
struct cmos_read_alarm_callback_param *p =
|
|
|
|
(struct cmos_read_alarm_callback_param *)param_in;
|
|
|
|
struct rtc_time *time = p->time;
|
|
|
|
|
|
|
|
time->tm_sec = CMOS_READ(RTC_SECONDS_ALARM);
|
|
|
|
time->tm_min = CMOS_READ(RTC_MINUTES_ALARM);
|
|
|
|
time->tm_hour = CMOS_READ(RTC_HOURS_ALARM);
|
|
|
|
|
|
|
|
if (p->cmos->day_alrm) {
|
|
|
|
/* ignore upper bits on readback per ACPI spec */
|
|
|
|
time->tm_mday = CMOS_READ(p->cmos->day_alrm) & 0x3f;
|
|
|
|
if (!time->tm_mday)
|
|
|
|
time->tm_mday = -1;
|
|
|
|
|
|
|
|
if (p->cmos->mon_alrm) {
|
|
|
|
time->tm_mon = CMOS_READ(p->cmos->mon_alrm);
|
|
|
|
if (!time->tm_mon)
|
|
|
|
time->tm_mon = -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
p->rtc_control = CMOS_READ(RTC_CONTROL);
|
|
|
|
}
|
|
|
|
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
static int cmos_read_alarm(struct device *dev, struct rtc_wkalrm *t)
|
|
|
|
{
|
|
|
|
struct cmos_rtc *cmos = dev_get_drvdata(dev);
|
2021-12-11 04:01:30 +08:00
|
|
|
struct cmos_read_alarm_callback_param p = {
|
|
|
|
.cmos = cmos,
|
|
|
|
.time = &t->time,
|
|
|
|
};
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
2018-09-04 22:51:29 +08:00
|
|
|
/* This not only a rtc_op, but also called directly */
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
if (!is_valid_irq(cmos->irq))
|
|
|
|
return -EIO;
|
|
|
|
|
|
|
|
/* Basic alarms only support hour, minute, and seconds fields.
|
|
|
|
* Some also support day and month, for alarms up to a year in
|
|
|
|
* the future.
|
|
|
|
*/
|
|
|
|
|
2021-12-11 04:01:30 +08:00
|
|
|
/* Some Intel chipsets disconnect the alarm registers when the clock
|
|
|
|
* update is in progress - during this time reads return bogus values
|
|
|
|
* and writes may fail silently. See for example "7th Generation Intel®
|
|
|
|
* Processor Family I/O for U/Y Platforms [...] Datasheet", section
|
|
|
|
* 27.7.1
|
|
|
|
*
|
|
|
|
* Use the mc146818_avoid_UIP() function to avoid this.
|
|
|
|
*/
|
|
|
|
if (!mc146818_avoid_UIP(cmos_read_alarm_callback, &p))
|
|
|
|
return -EIO;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
2021-12-11 04:01:30 +08:00
|
|
|
if (!(p.rtc_control & RTC_DM_BINARY) || RTC_ALWAYS_BCD) {
|
2010-04-29 17:58:44 +08:00
|
|
|
if (((unsigned)t->time.tm_sec) < 0x60)
|
|
|
|
t->time.tm_sec = bcd2bin(t->time.tm_sec);
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
else
|
2010-04-29 17:58:44 +08:00
|
|
|
t->time.tm_sec = -1;
|
|
|
|
if (((unsigned)t->time.tm_min) < 0x60)
|
|
|
|
t->time.tm_min = bcd2bin(t->time.tm_min);
|
|
|
|
else
|
|
|
|
t->time.tm_min = -1;
|
|
|
|
if (((unsigned)t->time.tm_hour) < 0x24)
|
|
|
|
t->time.tm_hour = bcd2bin(t->time.tm_hour);
|
|
|
|
else
|
|
|
|
t->time.tm_hour = -1;
|
|
|
|
|
|
|
|
if (cmos->day_alrm) {
|
|
|
|
if (((unsigned)t->time.tm_mday) <= 0x31)
|
|
|
|
t->time.tm_mday = bcd2bin(t->time.tm_mday);
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
else
|
2010-04-29 17:58:44 +08:00
|
|
|
t->time.tm_mday = -1;
|
|
|
|
|
|
|
|
if (cmos->mon_alrm) {
|
|
|
|
if (((unsigned)t->time.tm_mon) <= 0x12)
|
|
|
|
t->time.tm_mon = bcd2bin(t->time.tm_mon)-1;
|
|
|
|
else
|
|
|
|
t->time.tm_mon = -1;
|
|
|
|
}
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-12-11 04:01:30 +08:00
|
|
|
t->enabled = !!(p.rtc_control & RTC_AIE);
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
t->pending = 0;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-07-24 12:30:47 +08:00
|
|
|
static void cmos_checkintr(struct cmos_rtc *cmos, unsigned char rtc_control)
|
|
|
|
{
|
|
|
|
unsigned char rtc_intr;
|
|
|
|
|
|
|
|
/* NOTE after changing RTC_xIE bits we always read INTR_FLAGS;
|
|
|
|
* allegedly some older rtcs need that to handle irqs properly
|
|
|
|
*/
|
|
|
|
rtc_intr = CMOS_READ(RTC_INTR_FLAGS);
|
|
|
|
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
if (use_hpet_alarm())
|
2008-07-24 12:30:47 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
rtc_intr &= (rtc_control & RTC_IRQMASK) | RTC_IRQF;
|
|
|
|
if (is_intr(rtc_intr))
|
|
|
|
rtc_update_irq(cmos->rtc, 1, rtc_intr);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void cmos_irq_enable(struct cmos_rtc *cmos, unsigned char mask)
|
|
|
|
{
|
|
|
|
unsigned char rtc_control;
|
|
|
|
|
|
|
|
/* flush any pending IRQ status, notably for update irqs,
|
|
|
|
* before we enable new IRQs
|
|
|
|
*/
|
|
|
|
rtc_control = CMOS_READ(RTC_CONTROL);
|
|
|
|
cmos_checkintr(cmos, rtc_control);
|
|
|
|
|
|
|
|
rtc_control |= mask;
|
|
|
|
CMOS_WRITE(rtc_control, RTC_CONTROL);
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
if (use_hpet_alarm())
|
|
|
|
hpet_set_rtc_irq_bit(mask);
|
|
|
|
|
2018-10-02 09:09:05 +08:00
|
|
|
if ((mask & RTC_AIE) && cmos_use_acpi_alarm()) {
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
if (cmos->wake_on)
|
|
|
|
cmos->wake_on(cmos->dev);
|
|
|
|
}
|
2008-07-24 12:30:47 +08:00
|
|
|
|
|
|
|
cmos_checkintr(cmos, rtc_control);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void cmos_irq_disable(struct cmos_rtc *cmos, unsigned char mask)
|
|
|
|
{
|
|
|
|
unsigned char rtc_control;
|
|
|
|
|
|
|
|
rtc_control = CMOS_READ(RTC_CONTROL);
|
|
|
|
rtc_control &= ~mask;
|
|
|
|
CMOS_WRITE(rtc_control, RTC_CONTROL);
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
if (use_hpet_alarm())
|
|
|
|
hpet_mask_rtc_irq_bit(mask);
|
|
|
|
|
2018-10-02 09:09:05 +08:00
|
|
|
if ((mask & RTC_AIE) && cmos_use_acpi_alarm()) {
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
if (cmos->wake_off)
|
|
|
|
cmos->wake_off(cmos->dev);
|
|
|
|
}
|
2008-07-24 12:30:47 +08:00
|
|
|
|
|
|
|
cmos_checkintr(cmos, rtc_control);
|
|
|
|
}
|
|
|
|
|
2016-10-04 06:50:28 +08:00
|
|
|
static int cmos_validate_alarm(struct device *dev, struct rtc_wkalrm *t)
|
|
|
|
{
|
|
|
|
struct cmos_rtc *cmos = dev_get_drvdata(dev);
|
|
|
|
struct rtc_time now;
|
|
|
|
|
|
|
|
cmos_read_time(dev, &now);
|
|
|
|
|
|
|
|
if (!cmos->day_alrm) {
|
|
|
|
time64_t t_max_date;
|
|
|
|
time64_t t_alrm;
|
|
|
|
|
|
|
|
t_max_date = rtc_tm_to_time64(&now);
|
|
|
|
t_max_date += 24 * 60 * 60 - 1;
|
|
|
|
t_alrm = rtc_tm_to_time64(&t->time);
|
|
|
|
if (t_alrm > t_max_date) {
|
|
|
|
dev_err(dev,
|
|
|
|
"Alarms can be up to one day in the future\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
} else if (!cmos->mon_alrm) {
|
|
|
|
struct rtc_time max_date = now;
|
|
|
|
time64_t t_max_date;
|
|
|
|
time64_t t_alrm;
|
|
|
|
int max_mday;
|
|
|
|
|
|
|
|
if (max_date.tm_mon == 11) {
|
|
|
|
max_date.tm_mon = 0;
|
|
|
|
max_date.tm_year += 1;
|
|
|
|
} else {
|
|
|
|
max_date.tm_mon += 1;
|
|
|
|
}
|
|
|
|
max_mday = rtc_month_days(max_date.tm_mon, max_date.tm_year);
|
|
|
|
if (max_date.tm_mday > max_mday)
|
|
|
|
max_date.tm_mday = max_mday;
|
|
|
|
|
|
|
|
t_max_date = rtc_tm_to_time64(&max_date);
|
|
|
|
t_max_date -= 1;
|
|
|
|
t_alrm = rtc_tm_to_time64(&t->time);
|
|
|
|
if (t_alrm > t_max_date) {
|
|
|
|
dev_err(dev,
|
|
|
|
"Alarms can be up to one month in the future\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
struct rtc_time max_date = now;
|
|
|
|
time64_t t_max_date;
|
|
|
|
time64_t t_alrm;
|
|
|
|
int max_mday;
|
|
|
|
|
|
|
|
max_date.tm_year += 1;
|
|
|
|
max_mday = rtc_month_days(max_date.tm_mon, max_date.tm_year);
|
|
|
|
if (max_date.tm_mday > max_mday)
|
|
|
|
max_date.tm_mday = max_mday;
|
|
|
|
|
|
|
|
t_max_date = rtc_tm_to_time64(&max_date);
|
|
|
|
t_max_date -= 1;
|
|
|
|
t_alrm = rtc_tm_to_time64(&t->time);
|
|
|
|
if (t_alrm > t_max_date) {
|
|
|
|
dev_err(dev,
|
|
|
|
"Alarms can be up to one year in the future\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-12-11 04:01:31 +08:00
|
|
|
struct cmos_set_alarm_callback_param {
|
|
|
|
struct cmos_rtc *cmos;
|
|
|
|
unsigned char mon, mday, hrs, min, sec;
|
|
|
|
struct rtc_wkalrm *t;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Note: this function may be executed by mc146818_avoid_UIP() more then
|
|
|
|
* once
|
|
|
|
*/
|
|
|
|
static void cmos_set_alarm_callback(unsigned char __always_unused seconds,
|
|
|
|
void *param_in)
|
|
|
|
{
|
|
|
|
struct cmos_set_alarm_callback_param *p =
|
|
|
|
(struct cmos_set_alarm_callback_param *)param_in;
|
|
|
|
|
|
|
|
/* next rtc irq must not be from previous alarm setting */
|
|
|
|
cmos_irq_disable(p->cmos, RTC_AIE);
|
|
|
|
|
|
|
|
/* update alarm */
|
|
|
|
CMOS_WRITE(p->hrs, RTC_HOURS_ALARM);
|
|
|
|
CMOS_WRITE(p->min, RTC_MINUTES_ALARM);
|
|
|
|
CMOS_WRITE(p->sec, RTC_SECONDS_ALARM);
|
|
|
|
|
|
|
|
/* the system may support an "enhanced" alarm */
|
|
|
|
if (p->cmos->day_alrm) {
|
|
|
|
CMOS_WRITE(p->mday, p->cmos->day_alrm);
|
|
|
|
if (p->cmos->mon_alrm)
|
|
|
|
CMOS_WRITE(p->mon, p->cmos->mon_alrm);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (use_hpet_alarm()) {
|
|
|
|
/*
|
|
|
|
* FIXME the HPET alarm glue currently ignores day_alrm
|
|
|
|
* and mon_alrm ...
|
|
|
|
*/
|
|
|
|
hpet_set_alarm_time(p->t->time.tm_hour, p->t->time.tm_min,
|
|
|
|
p->t->time.tm_sec);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (p->t->enabled)
|
|
|
|
cmos_irq_enable(p->cmos, RTC_AIE);
|
|
|
|
}
|
|
|
|
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
static int cmos_set_alarm(struct device *dev, struct rtc_wkalrm *t)
|
|
|
|
{
|
|
|
|
struct cmos_rtc *cmos = dev_get_drvdata(dev);
|
2021-12-11 04:01:31 +08:00
|
|
|
struct cmos_set_alarm_callback_param p = {
|
|
|
|
.cmos = cmos,
|
|
|
|
.t = t
|
|
|
|
};
|
|
|
|
unsigned char rtc_control;
|
2016-10-04 06:50:28 +08:00
|
|
|
int ret;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
2018-09-04 22:51:29 +08:00
|
|
|
/* This not only a rtc_op, but also called directly */
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
if (!is_valid_irq(cmos->irq))
|
|
|
|
return -EIO;
|
|
|
|
|
2016-10-04 06:50:28 +08:00
|
|
|
ret = cmos_validate_alarm(dev, t);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
2021-12-11 04:01:31 +08:00
|
|
|
p.mon = t->time.tm_mon + 1;
|
|
|
|
p.mday = t->time.tm_mday;
|
|
|
|
p.hrs = t->time.tm_hour;
|
|
|
|
p.min = t->time.tm_min;
|
|
|
|
p.sec = t->time.tm_sec;
|
2010-04-29 17:58:44 +08:00
|
|
|
|
2021-12-11 04:01:23 +08:00
|
|
|
spin_lock_irq(&rtc_lock);
|
2010-04-29 17:58:44 +08:00
|
|
|
rtc_control = CMOS_READ(RTC_CONTROL);
|
2021-12-11 04:01:23 +08:00
|
|
|
spin_unlock_irq(&rtc_lock);
|
|
|
|
|
2010-04-29 17:58:44 +08:00
|
|
|
if (!(rtc_control & RTC_DM_BINARY) || RTC_ALWAYS_BCD) {
|
|
|
|
/* Writing 0xff means "don't care" or "match all". */
|
2021-12-11 04:01:31 +08:00
|
|
|
p.mon = (p.mon <= 12) ? bin2bcd(p.mon) : 0xff;
|
|
|
|
p.mday = (p.mday >= 1 && p.mday <= 31) ? bin2bcd(p.mday) : 0xff;
|
|
|
|
p.hrs = (p.hrs < 24) ? bin2bcd(p.hrs) : 0xff;
|
|
|
|
p.min = (p.min < 60) ? bin2bcd(p.min) : 0xff;
|
|
|
|
p.sec = (p.sec < 60) ? bin2bcd(p.sec) : 0xff;
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
}
|
2008-07-24 12:30:43 +08:00
|
|
|
|
2021-12-11 04:01:31 +08:00
|
|
|
/*
|
|
|
|
* Some Intel chipsets disconnect the alarm registers when the clock
|
|
|
|
* update is in progress - during this time writes fail silently.
|
|
|
|
*
|
|
|
|
* Use mc146818_avoid_UIP() to avoid this.
|
|
|
|
*/
|
|
|
|
if (!mc146818_avoid_UIP(cmos_set_alarm_callback, &p))
|
|
|
|
return -EIO;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
rtc: cmos: Cancel alarm timer if alarm time is equal to now+1 seconds
Steps to reproduce the problem:
1) Enable RTC wake-up option in BIOS Setup
2) Issue one of these commands in the OS: "poweroff"
or "shutdown -h now"
3) System will shut down and then reboot automatically
Root-cause of the issue:
1) During the shutdown process, the hwclock utility is used
to save the system clock to hardware clock (RTC).
2) The hwclock utility invokes ioctl() with RTC_UIE_ON. The
kernel configures the RTC alarm for the periodic interrupt
(every 1 second).
3) The hwclock uitlity closes the /dev/rtc0 device, and the
kernel disables the RTC alarm irq (AIE bit of Register B)
via ioctl() with RTC_UIE_OFF. But, the configured alarm
time is the current_time + 1.
4) After the next 1 second is elapsed, the AF (alarm
interrupt flag) of Register C is set.
5) The S5 handler in BIOS is invoked to configure alarm
registers (enable AIE bit and configure alarm date/time).
But, BIOS does not clear the previous interrupt status
during alarm configuration. Therefore, "AF=AIE=1" causes
the rtc device to trigger an interrupt.
6) So, the machine reboots automatically right after shutdown.
This patch cancels the alarm timer if the following condictions are
met (suggested by Alexandre):
1) The configured alarm time is equal to current_time + 1
seconds.
2) The AIE timer is not in use.
The member 'alarm_expires' is introduced in struct cmos_rtc because
of the following reasons:
1) The configured alarm time can be retrieved from
cmos_read_alarm(), but we need to take the 'wrapped
timestamp' and 'time rollover' into consideration. The
function __rtc_read_alarm() eliminates the concerns. To
avoid the duplicated code in the lower level RTC driver,
invoking __rtc_read_alarm from the lower level RTC driver
is not encouraged. Moreover, the compilation error 'the
undefined __rtc_read_alarm" is observed if the lower level
RTC driver is compiled as a kernel module.
2) The uie_rtctimer.node.expires and aie_timer.node.expires can
be retrieved for the configured alarm time. But, the problem
is that either of them might configure the CMOS alarm time.
We cannot make sure UIE timer or AIE tiemr configured the
CMOS alarm time before. (uie_rtctimer or aie_timer is enabled
and then is disabled).
3) The patch introduces the member 'alarm_expires' to keep the
newly configured alarm time, so the above-mentioned concerns
can be eliminated.
The issue goes away after 20-time shutdown tests.
Signed-off-by: Adrian Huang <ahuang12@lenovo.com>
Tested-by: Egbert Eich <eich@suse.de>
Tested-by: Diego Ercolani <diego.ercolani@gmail.com>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2015-07-06 12:19:12 +08:00
|
|
|
cmos->alarm_expires = rtc_tm_to_time64(&t->time);
|
|
|
|
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-12-16 08:45:56 +08:00
|
|
|
static int cmos_alarm_irq_enable(struct device *dev, unsigned int enabled)
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
{
|
|
|
|
struct cmos_rtc *cmos = dev_get_drvdata(dev);
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&rtc_lock, flags);
|
2009-12-16 08:45:56 +08:00
|
|
|
|
|
|
|
if (enabled)
|
2008-07-24 12:30:47 +08:00
|
|
|
cmos_irq_enable(cmos, RTC_AIE);
|
2009-12-16 08:45:56 +08:00
|
|
|
else
|
|
|
|
cmos_irq_disable(cmos, RTC_AIE);
|
|
|
|
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
spin_unlock_irqrestore(&rtc_lock, flags);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-04-27 06:17:35 +08:00
|
|
|
#if IS_ENABLED(CONFIG_RTC_INTF_PROC)
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
|
|
|
static int cmos_procfs(struct device *dev, struct seq_file *seq)
|
|
|
|
{
|
|
|
|
struct cmos_rtc *cmos = dev_get_drvdata(dev);
|
|
|
|
unsigned char rtc_control, valid;
|
|
|
|
|
|
|
|
spin_lock_irq(&rtc_lock);
|
|
|
|
rtc_control = CMOS_READ(RTC_CONTROL);
|
|
|
|
valid = CMOS_READ(RTC_VALID);
|
|
|
|
spin_unlock_irq(&rtc_lock);
|
|
|
|
|
|
|
|
/* NOTE: at least ICH6 reports battery status using a different
|
|
|
|
* (non-RTC) bit; and SQWE is ignored on many current systems.
|
|
|
|
*/
|
2015-04-16 07:17:51 +08:00
|
|
|
seq_printf(seq,
|
|
|
|
"periodic_IRQ\t: %s\n"
|
|
|
|
"update_IRQ\t: %s\n"
|
|
|
|
"HPET_emulated\t: %s\n"
|
|
|
|
// "square_wave\t: %s\n"
|
|
|
|
"BCD\t\t: %s\n"
|
|
|
|
"DST_enable\t: %s\n"
|
|
|
|
"periodic_freq\t: %d\n"
|
|
|
|
"batt_status\t: %s\n",
|
|
|
|
(rtc_control & RTC_PIE) ? "yes" : "no",
|
|
|
|
(rtc_control & RTC_UIE) ? "yes" : "no",
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
use_hpet_alarm() ? "yes" : "no",
|
2015-04-16 07:17:51 +08:00
|
|
|
// (rtc_control & RTC_SQWE) ? "yes" : "no",
|
|
|
|
(rtc_control & RTC_DM_BINARY) ? "no" : "yes",
|
|
|
|
(rtc_control & RTC_DST_EN) ? "yes" : "no",
|
|
|
|
cmos->rtc->irq_freq,
|
|
|
|
(valid & RTC_VRT) ? "okay" : "dead");
|
|
|
|
|
|
|
|
return 0;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
#else
|
|
|
|
#define cmos_procfs NULL
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static const struct rtc_class_ops cmos_rtc_ops = {
|
2009-12-16 08:45:56 +08:00
|
|
|
.read_time = cmos_read_time,
|
|
|
|
.set_time = cmos_set_time,
|
|
|
|
.read_alarm = cmos_read_alarm,
|
|
|
|
.set_alarm = cmos_set_alarm,
|
|
|
|
.proc = cmos_procfs,
|
|
|
|
.alarm_irq_enable = cmos_alarm_irq_enable,
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/*----------------------------------------------------------------*/
|
|
|
|
|
2008-02-06 17:38:43 +08:00
|
|
|
/*
|
|
|
|
* All these chips have at least 64 bytes of address space, shared by
|
|
|
|
* RTC registers and NVRAM. Most of those bytes of NVRAM are used
|
|
|
|
* by boot firmware. Modern chips have 128 or 256 bytes.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define NVRAM_OFFSET (RTC_REG_D + 1)
|
|
|
|
|
2018-02-13 06:47:46 +08:00
|
|
|
static int cmos_nvram_read(void *priv, unsigned int off, void *val,
|
|
|
|
size_t count)
|
2008-02-06 17:38:43 +08:00
|
|
|
{
|
2018-02-13 06:47:46 +08:00
|
|
|
unsigned char *buf = val;
|
2008-02-06 17:38:43 +08:00
|
|
|
int retval;
|
|
|
|
|
2008-10-19 11:27:47 +08:00
|
|
|
off += NVRAM_OFFSET;
|
2008-02-06 17:38:43 +08:00
|
|
|
spin_lock_irq(&rtc_lock);
|
2008-10-19 11:27:47 +08:00
|
|
|
for (retval = 0; count; count--, off++, retval++) {
|
|
|
|
if (off < 128)
|
|
|
|
*buf++ = CMOS_READ(off);
|
|
|
|
else if (can_bank2)
|
|
|
|
*buf++ = cmos_read_bank2(off);
|
|
|
|
else
|
|
|
|
break;
|
|
|
|
}
|
2008-02-06 17:38:43 +08:00
|
|
|
spin_unlock_irq(&rtc_lock);
|
|
|
|
|
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
2018-02-13 06:47:46 +08:00
|
|
|
static int cmos_nvram_write(void *priv, unsigned int off, void *val,
|
|
|
|
size_t count)
|
2008-02-06 17:38:43 +08:00
|
|
|
{
|
2018-02-13 06:47:46 +08:00
|
|
|
struct cmos_rtc *cmos = priv;
|
|
|
|
unsigned char *buf = val;
|
2008-02-06 17:38:43 +08:00
|
|
|
int retval;
|
|
|
|
|
|
|
|
/* NOTE: on at least PCs and Ataris, the boot firmware uses a
|
|
|
|
* checksum on part of the NVRAM data. That's currently ignored
|
|
|
|
* here. If userspace is smart enough to know what fields of
|
|
|
|
* NVRAM to update, updating checksums is also part of its job.
|
|
|
|
*/
|
2008-10-19 11:27:47 +08:00
|
|
|
off += NVRAM_OFFSET;
|
2008-02-06 17:38:43 +08:00
|
|
|
spin_lock_irq(&rtc_lock);
|
2008-10-19 11:27:47 +08:00
|
|
|
for (retval = 0; count; count--, off++, retval++) {
|
2008-02-06 17:38:43 +08:00
|
|
|
/* don't trash RTC registers */
|
|
|
|
if (off == cmos->day_alrm
|
|
|
|
|| off == cmos->mon_alrm
|
|
|
|
|| off == cmos->century)
|
|
|
|
buf++;
|
2008-10-19 11:27:47 +08:00
|
|
|
else if (off < 128)
|
2008-02-06 17:38:43 +08:00
|
|
|
CMOS_WRITE(*buf++, off);
|
2008-10-19 11:27:47 +08:00
|
|
|
else if (can_bank2)
|
|
|
|
cmos_write_bank2(*buf++, off);
|
|
|
|
else
|
|
|
|
break;
|
2008-02-06 17:38:43 +08:00
|
|
|
}
|
|
|
|
spin_unlock_irq(&rtc_lock);
|
|
|
|
|
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*----------------------------------------------------------------*/
|
|
|
|
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
static struct cmos_rtc cmos_rtc;
|
|
|
|
|
|
|
|
static irqreturn_t cmos_interrupt(int irq, void *p)
|
|
|
|
{
|
|
|
|
u8 irqstat;
|
2008-02-06 17:38:45 +08:00
|
|
|
u8 rtc_control;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
2021-02-03 20:39:36 +08:00
|
|
|
spin_lock(&rtc_lock);
|
2008-07-24 12:30:43 +08:00
|
|
|
|
|
|
|
/* When the HPET interrupt handler calls us, the interrupt
|
|
|
|
* status is passed as arg1 instead of the irq number. But
|
|
|
|
* always clear irq status, even when HPET is in the way.
|
|
|
|
*
|
|
|
|
* Note that HPET and RTC are almost certainly out of phase,
|
|
|
|
* giving different IRQ status ...
|
2008-02-06 17:38:52 +08:00
|
|
|
*/
|
2008-07-24 12:30:43 +08:00
|
|
|
irqstat = CMOS_READ(RTC_INTR_FLAGS);
|
|
|
|
rtc_control = CMOS_READ(RTC_CONTROL);
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
if (use_hpet_alarm())
|
2008-02-06 17:38:52 +08:00
|
|
|
irqstat = (unsigned long)irq & 0xF0;
|
2013-07-04 06:07:54 +08:00
|
|
|
|
|
|
|
/* If we were suspended, RTC_CONTROL may not be accurate since the
|
|
|
|
* bios may have cleared it.
|
|
|
|
*/
|
|
|
|
if (!cmos_rtc.suspend_ctrl)
|
|
|
|
irqstat &= (rtc_control & RTC_IRQMASK) | RTC_IRQF;
|
|
|
|
else
|
|
|
|
irqstat &= (cmos_rtc.suspend_ctrl & RTC_IRQMASK) | RTC_IRQF;
|
2008-02-06 17:38:45 +08:00
|
|
|
|
|
|
|
/* All Linux RTC alarms should be treated as if they were oneshot.
|
|
|
|
* Similar code may be needed in system wakeup paths, in case the
|
|
|
|
* alarm woke the system.
|
|
|
|
*/
|
|
|
|
if (irqstat & RTC_AIE) {
|
2013-07-04 06:07:54 +08:00
|
|
|
cmos_rtc.suspend_ctrl &= ~RTC_AIE;
|
2008-02-06 17:38:45 +08:00
|
|
|
rtc_control &= ~RTC_AIE;
|
|
|
|
CMOS_WRITE(rtc_control, RTC_CONTROL);
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
if (use_hpet_alarm())
|
|
|
|
hpet_mask_rtc_irq_bit(RTC_AIE);
|
2008-02-06 17:38:45 +08:00
|
|
|
CMOS_READ(RTC_INTR_FLAGS);
|
|
|
|
}
|
2021-02-03 20:39:36 +08:00
|
|
|
spin_unlock(&rtc_lock);
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
2007-04-02 14:49:47 +08:00
|
|
|
if (is_intr(irqstat)) {
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
rtc_update_irq(p, 1, irqstat);
|
|
|
|
return IRQ_HANDLED;
|
|
|
|
} else
|
|
|
|
return IRQ_NONE;
|
|
|
|
}
|
|
|
|
|
2007-05-08 15:34:09 +08:00
|
|
|
#ifdef CONFIG_PNP
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
#define INITSECTION
|
|
|
|
|
|
|
|
#else
|
|
|
|
#define INITSECTION __init
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static int INITSECTION
|
|
|
|
cmos_do_probe(struct device *dev, struct resource *ports, int rtc_irq)
|
|
|
|
{
|
2013-11-13 07:10:38 +08:00
|
|
|
struct cmos_rtc_board_info *info = dev_get_platdata(dev);
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
int retval = 0;
|
|
|
|
unsigned char rtc_control;
|
2008-02-06 17:38:43 +08:00
|
|
|
unsigned address_space;
|
drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-07 05:35:49 +08:00
|
|
|
u32 flags = 0;
|
2018-02-13 06:47:46 +08:00
|
|
|
struct nvmem_config nvmem_cfg = {
|
|
|
|
.name = "cmos_nvram",
|
|
|
|
.word_size = 1,
|
|
|
|
.stride = 1,
|
|
|
|
.reg_read = cmos_nvram_read,
|
|
|
|
.reg_write = cmos_nvram_write,
|
|
|
|
.priv = &cmos_rtc,
|
|
|
|
};
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
|
|
|
/* there can be only one ... */
|
|
|
|
if (cmos_rtc.dev)
|
|
|
|
return -EBUSY;
|
|
|
|
|
|
|
|
if (!ports)
|
|
|
|
return -ENODEV;
|
|
|
|
|
2007-10-16 16:28:21 +08:00
|
|
|
/* Claim I/O ports ASAP, minimizing conflict with legacy driver.
|
|
|
|
*
|
|
|
|
* REVISIT non-x86 systems may instead use memory space resources
|
|
|
|
* (needing ioremap etc), not i/o space resources like this ...
|
|
|
|
*/
|
drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-07 05:35:49 +08:00
|
|
|
if (RTC_IOMAPPED)
|
|
|
|
ports = request_region(ports->start, resource_size(ports),
|
|
|
|
driver_name);
|
|
|
|
else
|
|
|
|
ports = request_mem_region(ports->start, resource_size(ports),
|
|
|
|
driver_name);
|
2007-10-16 16:28:21 +08:00
|
|
|
if (!ports) {
|
|
|
|
dev_dbg(dev, "i/o registers already in use\n");
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
cmos_rtc.irq = rtc_irq;
|
|
|
|
cmos_rtc.iomem = ports;
|
|
|
|
|
2008-02-06 17:38:43 +08:00
|
|
|
/* Heuristic to deduce NVRAM size ... do what the legacy NVRAM
|
|
|
|
* driver did, but don't reject unknown configs. Old hardware
|
2008-10-19 11:27:47 +08:00
|
|
|
* won't address 128 bytes. Newer chips have multiple banks,
|
|
|
|
* though they may not be listed in one I/O resource.
|
2008-02-06 17:38:43 +08:00
|
|
|
*/
|
|
|
|
#if defined(CONFIG_ATARI)
|
|
|
|
address_space = 64;
|
2009-11-05 09:21:54 +08:00
|
|
|
#elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) \
|
2010-10-14 12:03:35 +08:00
|
|
|
|| defined(__sparc__) || defined(__mips__) \
|
2018-03-08 17:48:46 +08:00
|
|
|
|| defined(__powerpc__)
|
2008-02-06 17:38:43 +08:00
|
|
|
address_space = 128;
|
|
|
|
#else
|
|
|
|
#warning Assuming 128 bytes of RTC+NVRAM address space, not 64 bytes.
|
|
|
|
address_space = 128;
|
|
|
|
#endif
|
2008-10-19 11:27:47 +08:00
|
|
|
if (can_bank2 && ports->end > (ports->start + 1))
|
|
|
|
address_space = 256;
|
2008-02-06 17:38:43 +08:00
|
|
|
|
rtc-cmos wakeup interface
I finally got around to testing the updated wakeup event hooks for rtc-cmos,
and they follow in two patches:
- Interface update ... when a simple enable_irq_wake() doesn't suffice,
the platform data can hold suspend/resume callback hooks.
- ACPI implementation ... provides callback hooks to do ACPI magic, and
eliminate the legacy /proc/acpi/alarm file.
The interface update could go into 2.6.21, but that's not essential; they
will be NOPs on most PCs, without the ACPI stuff.
I suspect the ACPI folk may have opinions about how to merge that second
patch, and how to obsolete that legacy procfs file. I'd like to see that
merge into 2.6.22 if possible...
As for how to kick it in ... two ways:
- The appended "rtcwake" program; updated since the last time it was
posted, it deals much better with timezones and DST.
- Write the /sys/class/rtc/.../wakealarm file, then go to sleep.
For some reason RTC wake from "swsusp" stopped working on a system where
it previously worked; the alarm setting appears to get clobbered. But
on the bright side, RTC wake from "standby" worked on a system that had
never been able to resume from that state before ... IDEACPI is my guess
as to why it finally started to work. It's the old "two steps forward,
one step back" dance, I guess.
- Dave
/* gcc -Wall -Os -o rtcwake rtcwake.c */
#include <stdio.h>
#include <getopt.h>
#include <fcntl.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <time.h>
#include <sys/ioctl.h>
#include <sys/time.h>
#include <sys/types.h>
#include <linux/rtc.h>
/* constants from legacy PC/AT hardware */
#define RTC_PF 0x40
#define RTC_AF 0x20
#define RTC_UF 0x10
/*
* rtcwake -- enter a system sleep state until specified wakeup time.
*
* This uses cross-platform Linux interfaces to enter a system sleep state,
* and leave it no later than a specified time. It uses any RTC framework
* driver that supports standard driver model wakeup flags.
*
* This is normally used like the old "apmsleep" utility, to wake from a
* suspend state like ACPI S1 (standby) or S3 (suspend-to-RAM). Most
* platforms can implement those without analogues of BIOS, APM, or ACPI.
*
* On some systems, this can also be used like "nvram-wakeup", waking
* from states like ACPI S4 (suspend to disk). Not all systems have
* persistent media that are appropriate for such suspend modes.
*
* The best way to set the system's RTC is so that it holds the current
* time in UTC. Use the "-l" flag to tell this program that the system
* RTC uses a local timezone instead (maybe you dual-boot MS-Windows).
*/
static char *progname;
#ifdef DEBUG
#define VERSION "1.0 dev (" __DATE__ " " __TIME__ ")"
#else
#define VERSION "0.9"
#endif
static unsigned verbose;
static int rtc_is_utc = -1;
static int may_wakeup(const char *devname)
{
char buf[128], *s;
FILE *f;
snprintf(buf, sizeof buf, "/sys/class/rtc/%s/device/power/wakeup",
devname);
f = fopen(buf, "r");
if (!f) {
perror(buf);
return 0;
}
fgets(buf, sizeof buf, f);
fclose(f);
s = strchr(buf, '\n');
if (!s)
return 0;
*s = 0;
/* wakeup events could be disabled or not supported */
return strcmp(buf, "enabled") == 0;
}
/* all times should be in UTC */
static time_t sys_time;
static time_t rtc_time;
static int get_basetimes(int fd)
{
struct tm tm;
struct rtc_time rtc;
/* this process works in RTC time, except when working
* with the system clock (which always uses UTC).
*/
if (rtc_is_utc)
setenv("TZ", "UTC", 1);
tzset();
/* read rtc and system clocks "at the same time", or as
* precisely (+/- a second) as we can read them.
*/
if (ioctl(fd, RTC_RD_TIME, &rtc) < 0) {
perror("read rtc time");
return 0;
}
sys_time = time(0);
if (sys_time == (time_t)-1) {
perror("read system time");
return 0;
}
/* convert rtc_time to normal arithmetic-friendly form,
* updating tm.tm_wday as used by asctime().
*/
memset(&tm, 0, sizeof tm);
tm.tm_sec = rtc.tm_sec;
tm.tm_min = rtc.tm_min;
tm.tm_hour = rtc.tm_hour;
tm.tm_mday = rtc.tm_mday;
tm.tm_mon = rtc.tm_mon;
tm.tm_year = rtc.tm_year;
tm.tm_isdst = rtc.tm_isdst; /* stays unspecified? */
rtc_time = mktime(&tm);
if (rtc_time == (time_t)-1) {
perror("convert rtc time");
return 0;
}
if (verbose) {
if (!rtc_is_utc) {
printf("\ttzone = %ld\n", timezone);
printf("\ttzname = %s\n", tzname[daylight]);
gmtime_r(&rtc_time, &tm);
}
printf("\tsystime = %ld, (UTC) %s",
(long) sys_time, asctime(gmtime(&sys_time)));
printf("\trtctime = %ld, (UTC) %s",
(long) rtc_time, asctime(&tm));
}
return 1;
}
static int setup_alarm(int fd, time_t *wakeup)
{
struct tm *tm;
struct rtc_wkalrm wake;
tm = gmtime(wakeup);
wake.time.tm_sec = tm->tm_sec;
wake.time.tm_min = tm->tm_min;
wake.time.tm_hour = tm->tm_hour;
wake.time.tm_mday = tm->tm_mday;
wake.time.tm_mon = tm->tm_mon;
wake.time.tm_year = tm->tm_year;
wake.time.tm_wday = tm->tm_wday;
wake.time.tm_yday = tm->tm_yday;
wake.time.tm_isdst = tm->tm_isdst;
/* many rtc alarms only support up to 24 hours from 'now' ... */
if ((rtc_time + (24 * 60 * 60)) > *wakeup) {
if (ioctl(fd, RTC_ALM_SET, &wake.time) < 0) {
perror("set rtc alarm");
return 0;
}
if (ioctl(fd, RTC_AIE_ON, 0) < 0) {
perror("enable rtc alarm");
return 0;
}
/* ... so use the "more than 24 hours" request only if we must */
} else {
/* avoid an extra AIE_ON call */
wake.enabled = 1;
if (ioctl(fd, RTC_WKALM_SET, &wake) < 0) {
perror("set rtc wake alarm");
return 0;
}
}
return 1;
}
static void suspend_system(const char *suspend)
{
FILE *f = fopen("/sys/power/state", "w");
if (!f) {
perror("/sys/power/state");
return;
}
fprintf(f, "%s\n", suspend);
fflush(f);
/* this executes after wake from suspend */
fclose(f);
}
int main(int argc, char **argv)
{
static char *devname = "rtc0";
static unsigned seconds = 0;
static char *suspend = "standby";
int t;
int fd;
time_t alarm = 0;
progname = strrchr(argv[0], '/');
if (progname)
progname++;
else
progname = argv[0];
if (chdir("/dev/") < 0) {
perror("chdir /dev");
return 1;
}
while ((t = getopt(argc, argv, "d:lm:s:t:uVv")) != EOF) {
switch (t) {
case 'd':
devname = optarg;
break;
case 'l':
rtc_is_utc = 0;
break;
/* what system power mode to use? for now handle only
* standardized mode names; eventually when systems define
* their own state names, parse /sys/power/state.
*
* "on" is used just to test the RTC alarm mechanism,
* bypassing all the wakeup-from-sleep infrastructure.
*/
case 'm':
if (strcmp(optarg, "standby") == 0
|| strcmp(optarg, "mem") == 0
|| strcmp(optarg, "disk") == 0
|| strcmp(optarg, "on") == 0
) {
suspend = optarg;
break;
}
printf("%s: unrecognized suspend state '%s'\n",
progname, optarg);
goto usage;
/* alarm time, seconds-to-sleep (relative) */
case 's':
t = atoi(optarg);
if (t < 0) {
printf("%s: illegal interval %s seconds\n",
progname, optarg);
goto usage;
}
seconds = t;
break;
/* alarm time, time_t (absolute, seconds since 1/1 1970 UTC) */
case 't':
t = atoi(optarg);
if (t < 0) {
printf("%s: illegal time_t value %s\n",
progname, optarg);
goto usage;
}
alarm = t;
break;
case 'u':
rtc_is_utc = 1;
break;
case 'v':
verbose++;
break;
case 'V':
printf("%s: version %s\n", progname, VERSION);
break;
default:
usage:
printf("usage: %s [options]"
"\n\t"
"-d rtc0|rtc1|...\t(select rtc)"
"\n\t"
"-l\t\t\t(RTC uses local timezone)"
"\n\t"
"-m standby|mem|...\t(sleep mode)"
"\n\t"
"-s seconds\t\t(seconds to sleep)"
"\n\t"
"-t time_t\t\t(time to wake)"
"\n\t"
"-u\t\t\t(RTC uses UTC)"
"\n\t"
"-v\t\t\t(verbose messages)"
"\n\t"
"-V\t\t\t(show version)"
"\n",
progname);
return 1;
}
}
if (!alarm && !seconds) {
printf("%s: must provide wake time\n", progname);
goto usage;
}
/* REVISIT: if /etc/adjtime exists, read it to see what
* the util-linux version of hwclock assumes.
*/
if (rtc_is_utc == -1) {
printf("%s: assuming RTC uses UTC ...\n", progname);
rtc_is_utc = 1;
}
/* this RTC must exist and (if we'll sleep) be wakeup-enabled */
fd = open(devname, O_RDONLY);
if (fd < 0) {
perror(devname);
return 1;
}
if (strcmp(suspend, "on") != 0 && !may_wakeup(devname)) {
printf("%s: %s not enabled for wakeup events\n",
progname, devname);
return 1;
}
/* relative or absolute alarm time, normalized to time_t */
if (!get_basetimes(fd))
return 1;
if (verbose)
printf("alarm %ld, sys_time %ld, rtc_time %ld, seconds %u\n",
alarm, sys_time, rtc_time, seconds);
if (alarm) {
if (alarm < sys_time) {
printf("%s: time doesn't go backward to %s",
progname, ctime(&alarm));
return 1;
}
alarm += sys_time - rtc_time;
} else
alarm = rtc_time + seconds + 1;
if (setup_alarm(fd, &alarm) < 0)
return 1;
sync();
printf("%s: wakeup from \"%s\" using %s at %s",
progname, suspend, devname,
ctime(&alarm));
fflush(stdout);
usleep(10 * 1000);
if (strcmp(suspend, "on") != 0)
suspend_system(suspend);
else {
unsigned long data;
do {
t = read(fd, &data, sizeof data);
if (t < 0) {
perror("rtc read");
break;
}
if (verbose)
printf("... %s: %03lx\n", devname, data);
} while (!(data & RTC_AF));
}
if (ioctl(fd, RTC_AIE_OFF, 0) < 0)
perror("disable rtc alarm interrupt");
close(fd);
return 0;
}
This patch:
Make rtc-cmos do the relevant magic so this RTC can wake the system from a
sleep state. That magic comes in two basic flavors:
- Straightforward: enable_irq_wake(), the way it'd work on most SOC chips;
or generally with system sleep states which don't disable core IRQ logic.
- Roundabout, using non-IRQ platform hooks. This is needed with ACPI and
one almost-clone chip which uses a special wakeup-only alarm. (That's
the RTC used on Footbridge boards, FWIW, which don't do PM in Linux.)
A separate patch implements those hooks for ACPI platforms, so that rtc_cmos
can issue system wakeup events (and its sysfs "wakealarm" attribute works on
at least some systems).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-08 15:34:00 +08:00
|
|
|
/* For ACPI systems extension info comes from the FADT. On others,
|
|
|
|
* board specific setup provides it as appropriate. Systems where
|
|
|
|
* the alarm IRQ isn't automatically a wakeup IRQ (like ACPI, and
|
|
|
|
* some almost-clones) can provide hooks to make that behave.
|
2008-02-06 17:38:43 +08:00
|
|
|
*
|
|
|
|
* Note that ACPI doesn't preclude putting these registers into
|
|
|
|
* "extended" areas of the chip, including some that we won't yet
|
|
|
|
* expect CMOS_READ and friends to handle.
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
*/
|
|
|
|
if (info) {
|
drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-07 05:35:49 +08:00
|
|
|
if (info->flags)
|
|
|
|
flags = info->flags;
|
|
|
|
if (info->address_space)
|
|
|
|
address_space = info->address_space;
|
|
|
|
|
2008-02-06 17:38:43 +08:00
|
|
|
if (info->rtc_day_alarm && info->rtc_day_alarm < 128)
|
|
|
|
cmos_rtc.day_alrm = info->rtc_day_alarm;
|
|
|
|
if (info->rtc_mon_alarm && info->rtc_mon_alarm < 128)
|
|
|
|
cmos_rtc.mon_alrm = info->rtc_mon_alarm;
|
|
|
|
if (info->rtc_century && info->rtc_century < 128)
|
|
|
|
cmos_rtc.century = info->rtc_century;
|
rtc-cmos wakeup interface
I finally got around to testing the updated wakeup event hooks for rtc-cmos,
and they follow in two patches:
- Interface update ... when a simple enable_irq_wake() doesn't suffice,
the platform data can hold suspend/resume callback hooks.
- ACPI implementation ... provides callback hooks to do ACPI magic, and
eliminate the legacy /proc/acpi/alarm file.
The interface update could go into 2.6.21, but that's not essential; they
will be NOPs on most PCs, without the ACPI stuff.
I suspect the ACPI folk may have opinions about how to merge that second
patch, and how to obsolete that legacy procfs file. I'd like to see that
merge into 2.6.22 if possible...
As for how to kick it in ... two ways:
- The appended "rtcwake" program; updated since the last time it was
posted, it deals much better with timezones and DST.
- Write the /sys/class/rtc/.../wakealarm file, then go to sleep.
For some reason RTC wake from "swsusp" stopped working on a system where
it previously worked; the alarm setting appears to get clobbered. But
on the bright side, RTC wake from "standby" worked on a system that had
never been able to resume from that state before ... IDEACPI is my guess
as to why it finally started to work. It's the old "two steps forward,
one step back" dance, I guess.
- Dave
/* gcc -Wall -Os -o rtcwake rtcwake.c */
#include <stdio.h>
#include <getopt.h>
#include <fcntl.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <time.h>
#include <sys/ioctl.h>
#include <sys/time.h>
#include <sys/types.h>
#include <linux/rtc.h>
/* constants from legacy PC/AT hardware */
#define RTC_PF 0x40
#define RTC_AF 0x20
#define RTC_UF 0x10
/*
* rtcwake -- enter a system sleep state until specified wakeup time.
*
* This uses cross-platform Linux interfaces to enter a system sleep state,
* and leave it no later than a specified time. It uses any RTC framework
* driver that supports standard driver model wakeup flags.
*
* This is normally used like the old "apmsleep" utility, to wake from a
* suspend state like ACPI S1 (standby) or S3 (suspend-to-RAM). Most
* platforms can implement those without analogues of BIOS, APM, or ACPI.
*
* On some systems, this can also be used like "nvram-wakeup", waking
* from states like ACPI S4 (suspend to disk). Not all systems have
* persistent media that are appropriate for such suspend modes.
*
* The best way to set the system's RTC is so that it holds the current
* time in UTC. Use the "-l" flag to tell this program that the system
* RTC uses a local timezone instead (maybe you dual-boot MS-Windows).
*/
static char *progname;
#ifdef DEBUG
#define VERSION "1.0 dev (" __DATE__ " " __TIME__ ")"
#else
#define VERSION "0.9"
#endif
static unsigned verbose;
static int rtc_is_utc = -1;
static int may_wakeup(const char *devname)
{
char buf[128], *s;
FILE *f;
snprintf(buf, sizeof buf, "/sys/class/rtc/%s/device/power/wakeup",
devname);
f = fopen(buf, "r");
if (!f) {
perror(buf);
return 0;
}
fgets(buf, sizeof buf, f);
fclose(f);
s = strchr(buf, '\n');
if (!s)
return 0;
*s = 0;
/* wakeup events could be disabled or not supported */
return strcmp(buf, "enabled") == 0;
}
/* all times should be in UTC */
static time_t sys_time;
static time_t rtc_time;
static int get_basetimes(int fd)
{
struct tm tm;
struct rtc_time rtc;
/* this process works in RTC time, except when working
* with the system clock (which always uses UTC).
*/
if (rtc_is_utc)
setenv("TZ", "UTC", 1);
tzset();
/* read rtc and system clocks "at the same time", or as
* precisely (+/- a second) as we can read them.
*/
if (ioctl(fd, RTC_RD_TIME, &rtc) < 0) {
perror("read rtc time");
return 0;
}
sys_time = time(0);
if (sys_time == (time_t)-1) {
perror("read system time");
return 0;
}
/* convert rtc_time to normal arithmetic-friendly form,
* updating tm.tm_wday as used by asctime().
*/
memset(&tm, 0, sizeof tm);
tm.tm_sec = rtc.tm_sec;
tm.tm_min = rtc.tm_min;
tm.tm_hour = rtc.tm_hour;
tm.tm_mday = rtc.tm_mday;
tm.tm_mon = rtc.tm_mon;
tm.tm_year = rtc.tm_year;
tm.tm_isdst = rtc.tm_isdst; /* stays unspecified? */
rtc_time = mktime(&tm);
if (rtc_time == (time_t)-1) {
perror("convert rtc time");
return 0;
}
if (verbose) {
if (!rtc_is_utc) {
printf("\ttzone = %ld\n", timezone);
printf("\ttzname = %s\n", tzname[daylight]);
gmtime_r(&rtc_time, &tm);
}
printf("\tsystime = %ld, (UTC) %s",
(long) sys_time, asctime(gmtime(&sys_time)));
printf("\trtctime = %ld, (UTC) %s",
(long) rtc_time, asctime(&tm));
}
return 1;
}
static int setup_alarm(int fd, time_t *wakeup)
{
struct tm *tm;
struct rtc_wkalrm wake;
tm = gmtime(wakeup);
wake.time.tm_sec = tm->tm_sec;
wake.time.tm_min = tm->tm_min;
wake.time.tm_hour = tm->tm_hour;
wake.time.tm_mday = tm->tm_mday;
wake.time.tm_mon = tm->tm_mon;
wake.time.tm_year = tm->tm_year;
wake.time.tm_wday = tm->tm_wday;
wake.time.tm_yday = tm->tm_yday;
wake.time.tm_isdst = tm->tm_isdst;
/* many rtc alarms only support up to 24 hours from 'now' ... */
if ((rtc_time + (24 * 60 * 60)) > *wakeup) {
if (ioctl(fd, RTC_ALM_SET, &wake.time) < 0) {
perror("set rtc alarm");
return 0;
}
if (ioctl(fd, RTC_AIE_ON, 0) < 0) {
perror("enable rtc alarm");
return 0;
}
/* ... so use the "more than 24 hours" request only if we must */
} else {
/* avoid an extra AIE_ON call */
wake.enabled = 1;
if (ioctl(fd, RTC_WKALM_SET, &wake) < 0) {
perror("set rtc wake alarm");
return 0;
}
}
return 1;
}
static void suspend_system(const char *suspend)
{
FILE *f = fopen("/sys/power/state", "w");
if (!f) {
perror("/sys/power/state");
return;
}
fprintf(f, "%s\n", suspend);
fflush(f);
/* this executes after wake from suspend */
fclose(f);
}
int main(int argc, char **argv)
{
static char *devname = "rtc0";
static unsigned seconds = 0;
static char *suspend = "standby";
int t;
int fd;
time_t alarm = 0;
progname = strrchr(argv[0], '/');
if (progname)
progname++;
else
progname = argv[0];
if (chdir("/dev/") < 0) {
perror("chdir /dev");
return 1;
}
while ((t = getopt(argc, argv, "d:lm:s:t:uVv")) != EOF) {
switch (t) {
case 'd':
devname = optarg;
break;
case 'l':
rtc_is_utc = 0;
break;
/* what system power mode to use? for now handle only
* standardized mode names; eventually when systems define
* their own state names, parse /sys/power/state.
*
* "on" is used just to test the RTC alarm mechanism,
* bypassing all the wakeup-from-sleep infrastructure.
*/
case 'm':
if (strcmp(optarg, "standby") == 0
|| strcmp(optarg, "mem") == 0
|| strcmp(optarg, "disk") == 0
|| strcmp(optarg, "on") == 0
) {
suspend = optarg;
break;
}
printf("%s: unrecognized suspend state '%s'\n",
progname, optarg);
goto usage;
/* alarm time, seconds-to-sleep (relative) */
case 's':
t = atoi(optarg);
if (t < 0) {
printf("%s: illegal interval %s seconds\n",
progname, optarg);
goto usage;
}
seconds = t;
break;
/* alarm time, time_t (absolute, seconds since 1/1 1970 UTC) */
case 't':
t = atoi(optarg);
if (t < 0) {
printf("%s: illegal time_t value %s\n",
progname, optarg);
goto usage;
}
alarm = t;
break;
case 'u':
rtc_is_utc = 1;
break;
case 'v':
verbose++;
break;
case 'V':
printf("%s: version %s\n", progname, VERSION);
break;
default:
usage:
printf("usage: %s [options]"
"\n\t"
"-d rtc0|rtc1|...\t(select rtc)"
"\n\t"
"-l\t\t\t(RTC uses local timezone)"
"\n\t"
"-m standby|mem|...\t(sleep mode)"
"\n\t"
"-s seconds\t\t(seconds to sleep)"
"\n\t"
"-t time_t\t\t(time to wake)"
"\n\t"
"-u\t\t\t(RTC uses UTC)"
"\n\t"
"-v\t\t\t(verbose messages)"
"\n\t"
"-V\t\t\t(show version)"
"\n",
progname);
return 1;
}
}
if (!alarm && !seconds) {
printf("%s: must provide wake time\n", progname);
goto usage;
}
/* REVISIT: if /etc/adjtime exists, read it to see what
* the util-linux version of hwclock assumes.
*/
if (rtc_is_utc == -1) {
printf("%s: assuming RTC uses UTC ...\n", progname);
rtc_is_utc = 1;
}
/* this RTC must exist and (if we'll sleep) be wakeup-enabled */
fd = open(devname, O_RDONLY);
if (fd < 0) {
perror(devname);
return 1;
}
if (strcmp(suspend, "on") != 0 && !may_wakeup(devname)) {
printf("%s: %s not enabled for wakeup events\n",
progname, devname);
return 1;
}
/* relative or absolute alarm time, normalized to time_t */
if (!get_basetimes(fd))
return 1;
if (verbose)
printf("alarm %ld, sys_time %ld, rtc_time %ld, seconds %u\n",
alarm, sys_time, rtc_time, seconds);
if (alarm) {
if (alarm < sys_time) {
printf("%s: time doesn't go backward to %s",
progname, ctime(&alarm));
return 1;
}
alarm += sys_time - rtc_time;
} else
alarm = rtc_time + seconds + 1;
if (setup_alarm(fd, &alarm) < 0)
return 1;
sync();
printf("%s: wakeup from \"%s\" using %s at %s",
progname, suspend, devname,
ctime(&alarm));
fflush(stdout);
usleep(10 * 1000);
if (strcmp(suspend, "on") != 0)
suspend_system(suspend);
else {
unsigned long data;
do {
t = read(fd, &data, sizeof data);
if (t < 0) {
perror("rtc read");
break;
}
if (verbose)
printf("... %s: %03lx\n", devname, data);
} while (!(data & RTC_AF));
}
if (ioctl(fd, RTC_AIE_OFF, 0) < 0)
perror("disable rtc alarm interrupt");
close(fd);
return 0;
}
This patch:
Make rtc-cmos do the relevant magic so this RTC can wake the system from a
sleep state. That magic comes in two basic flavors:
- Straightforward: enable_irq_wake(), the way it'd work on most SOC chips;
or generally with system sleep states which don't disable core IRQ logic.
- Roundabout, using non-IRQ platform hooks. This is needed with ACPI and
one almost-clone chip which uses a special wakeup-only alarm. (That's
the RTC used on Footbridge boards, FWIW, which don't do PM in Linux.)
A separate patch implements those hooks for ACPI platforms, so that rtc_cmos
can issue system wakeup events (and its sysfs "wakealarm" attribute works on
at least some systems).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-08 15:34:00 +08:00
|
|
|
|
|
|
|
if (info->wake_on && info->wake_off) {
|
|
|
|
cmos_rtc.wake_on = info->wake_on;
|
|
|
|
cmos_rtc.wake_off = info->wake_off;
|
|
|
|
}
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
}
|
|
|
|
|
2010-05-25 05:33:49 +08:00
|
|
|
cmos_rtc.dev = dev;
|
|
|
|
dev_set_drvdata(dev, &cmos_rtc);
|
|
|
|
|
2018-02-13 06:47:45 +08:00
|
|
|
cmos_rtc.rtc = devm_rtc_allocate_device(dev);
|
2007-10-16 16:28:21 +08:00
|
|
|
if (IS_ERR(cmos_rtc.rtc)) {
|
|
|
|
retval = PTR_ERR(cmos_rtc.rtc);
|
|
|
|
goto cleanup0;
|
|
|
|
}
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
2009-01-07 06:42:11 +08:00
|
|
|
rename_region(ports, dev_name(&cmos_rtc.rtc->dev));
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
rtc: mc146818-lib: fix RTC presence check
To prevent an infinite loop in mc146818_get_time(),
commit 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs")
added a check for RTC availability. Together with a later fix, it
checked if bit 6 in register 0x0d is cleared.
This, however, caused a false negative on a motherboard with an AMD
SB710 southbridge; according to the specification [1], bit 6 of register
0x0d of this chipset is a scratchbit. This caused a regression in Linux
5.11 - the RTC was determined broken by the kernel and not used by
rtc-cmos.c [3]. This problem was also reported in Fedora [4].
As a better alternative, check whether the UIP ("Update-in-progress")
bit is set for longer then 10ms. If that is the case, then apparently
the RTC is either absent (and all register reads return 0xff) or broken.
Also limit the number of loop iterations in mc146818_get_time() to 10 to
prevent an infinite loop there.
The functions mc146818_get_time() and mc146818_does_rtc_work() will be
refactored later in this patch series, in order to fix a separate
problem with reading / setting the RTC alarm time. This is done so to
avoid a confusion about what is being fixed when.
In a previous approach to this problem, I implemented a check whether
the RTC_HOURS register contains a value <= 24. This, however, sometimes
did not work correctly on my Intel Kaby Lake laptop. According to
Intel's documentation [2], "the time and date RAM locations (0-9) are
disconnected from the external bus" during the update cycle so reading
this register without checking the UIP bit is incorrect.
[1] AMD SB700/710/750 Register Reference Guide, page 308,
https://developer.amd.com/wordpress/media/2012/10/43009_sb7xx_rrg_pub_1.00.pdf
[2] 7th Generation Intel ® Processor Family I/O for U/Y Platforms [...] Datasheet
Volume 1 of 2, page 209
Intel's Document Number: 334658-006,
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/7th-and-8th-gen-core-family-mobile-u-y-processor-lines-i-o-datasheet-vol-1.pdf
[3] Functions in arch/x86/kernel/rtc.c apparently were using it.
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1936688
Fixes: 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs")
Fixes: ebb22a059436 ("rtc: mc146818: Dont test for bit 0-5 in Register D")
Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20211210200131.153887-5-mat.jonczyk@o2.pl
2021-12-11 04:01:26 +08:00
|
|
|
if (!mc146818_does_rtc_work()) {
|
|
|
|
dev_warn(dev, "broken or not accessible\n");
|
2021-01-27 01:02:11 +08:00
|
|
|
retval = -ENXIO;
|
|
|
|
goto cleanup1;
|
|
|
|
}
|
|
|
|
|
rtc: mc146818-lib: fix RTC presence check
To prevent an infinite loop in mc146818_get_time(),
commit 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs")
added a check for RTC availability. Together with a later fix, it
checked if bit 6 in register 0x0d is cleared.
This, however, caused a false negative on a motherboard with an AMD
SB710 southbridge; according to the specification [1], bit 6 of register
0x0d of this chipset is a scratchbit. This caused a regression in Linux
5.11 - the RTC was determined broken by the kernel and not used by
rtc-cmos.c [3]. This problem was also reported in Fedora [4].
As a better alternative, check whether the UIP ("Update-in-progress")
bit is set for longer then 10ms. If that is the case, then apparently
the RTC is either absent (and all register reads return 0xff) or broken.
Also limit the number of loop iterations in mc146818_get_time() to 10 to
prevent an infinite loop there.
The functions mc146818_get_time() and mc146818_does_rtc_work() will be
refactored later in this patch series, in order to fix a separate
problem with reading / setting the RTC alarm time. This is done so to
avoid a confusion about what is being fixed when.
In a previous approach to this problem, I implemented a check whether
the RTC_HOURS register contains a value <= 24. This, however, sometimes
did not work correctly on my Intel Kaby Lake laptop. According to
Intel's documentation [2], "the time and date RAM locations (0-9) are
disconnected from the external bus" during the update cycle so reading
this register without checking the UIP bit is incorrect.
[1] AMD SB700/710/750 Register Reference Guide, page 308,
https://developer.amd.com/wordpress/media/2012/10/43009_sb7xx_rrg_pub_1.00.pdf
[2] 7th Generation Intel ® Processor Family I/O for U/Y Platforms [...] Datasheet
Volume 1 of 2, page 209
Intel's Document Number: 334658-006,
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/7th-and-8th-gen-core-family-mobile-u-y-processor-lines-i-o-datasheet-vol-1.pdf
[3] Functions in arch/x86/kernel/rtc.c apparently were using it.
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1936688
Fixes: 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs")
Fixes: ebb22a059436 ("rtc: mc146818: Dont test for bit 0-5 in Register D")
Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20211210200131.153887-5-mat.jonczyk@o2.pl
2021-12-11 04:01:26 +08:00
|
|
|
spin_lock_irq(&rtc_lock);
|
|
|
|
|
drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-07 05:35:49 +08:00
|
|
|
if (!(flags & CMOS_RTC_FLAGS_NOFREQ)) {
|
|
|
|
/* force periodic irq to CMOS reset default of 1024Hz;
|
|
|
|
*
|
|
|
|
* REVISIT it's been reported that at least one x86_64 ALI
|
|
|
|
* mobo doesn't use 32KHz here ... for portability we might
|
|
|
|
* need to do something about other clock frequencies.
|
|
|
|
*/
|
|
|
|
cmos_rtc.rtc->irq_freq = 1024;
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
if (use_hpet_alarm())
|
|
|
|
hpet_set_periodic_freq(cmos_rtc.rtc->irq_freq);
|
drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-07 05:35:49 +08:00
|
|
|
CMOS_WRITE(RTC_REF_CLCK_32KHZ | 0x06, RTC_FREQ_SELECT);
|
|
|
|
}
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
2008-07-24 12:30:47 +08:00
|
|
|
/* disable irqs */
|
drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-07 05:35:49 +08:00
|
|
|
if (is_valid_irq(rtc_irq))
|
|
|
|
cmos_irq_disable(&cmos_rtc, RTC_PIE | RTC_AIE | RTC_UIE);
|
2008-07-24 12:30:43 +08:00
|
|
|
|
2008-07-24 12:30:47 +08:00
|
|
|
rtc_control = CMOS_READ(RTC_CONTROL);
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
|
|
|
spin_unlock_irq(&rtc_lock);
|
|
|
|
|
2013-07-04 06:05:45 +08:00
|
|
|
if (is_valid_irq(rtc_irq) && !(rtc_control & RTC_24H)) {
|
2010-04-29 17:58:44 +08:00
|
|
|
dev_warn(dev, "only 24-hr supported\n");
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
retval = -ENXIO;
|
|
|
|
goto cleanup1;
|
|
|
|
}
|
|
|
|
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
if (use_hpet_alarm())
|
|
|
|
hpet_rtc_timer_init();
|
2016-09-15 12:08:16 +08:00
|
|
|
|
2008-02-06 17:38:52 +08:00
|
|
|
if (is_valid_irq(rtc_irq)) {
|
|
|
|
irq_handler_t rtc_cmos_int_handler;
|
|
|
|
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
if (use_hpet_alarm()) {
|
2008-02-06 17:38:52 +08:00
|
|
|
rtc_cmos_int_handler = hpet_rtc_interrupt;
|
2014-01-24 07:55:15 +08:00
|
|
|
retval = hpet_register_irq_handler(cmos_interrupt);
|
|
|
|
if (retval) {
|
2016-09-15 12:08:16 +08:00
|
|
|
hpet_mask_rtc_irq_bit(RTC_IRQMASK);
|
2013-02-22 08:45:34 +08:00
|
|
|
dev_warn(dev, "hpet_register_irq_handler "
|
2008-02-06 17:38:52 +08:00
|
|
|
" failed in rtc_init().");
|
|
|
|
goto cleanup1;
|
|
|
|
}
|
|
|
|
} else
|
|
|
|
rtc_cmos_int_handler = cmos_interrupt;
|
|
|
|
|
|
|
|
retval = request_irq(rtc_irq, rtc_cmos_int_handler,
|
rtc: cmos: Stop using shared IRQ
As reported by Guilherme G. Piccoli:
---8<---8<---8<---
The rtc-cmos interrupt setting was changed in the commit 079062b28fb4
("rtc: cmos: prevent kernel warning on IRQ flags mismatch") in order
to allow shared interrupts; according to that commit's description,
some machine got kernel warnings due to the interrupt line being shared
between rtc-cmos and other hardware, and rtc-cmos didn't allow IRQ sharing
that time.
After the aforementioned commit though it was observed a huge increase
in lost HPET interrupts in some systems, observed through the following
kernel message:
[...] hpet1: lost 35 rtc interrupts
After investigation, it was narrowed down to the shared interrupts
usage when having the kernel option "irqpoll" enabled. In this case,
all IRQ handlers are called for non-timer interrupts, if such handlers
are setup in shared IRQ lines. The rtc-cmos IRQ handler could be set to
hpet_rtc_interrupt(), which will produce the kernel "lost interrupts"
message after doing work - lots of readl/writel to HPET registers, which
are known to be slow.
Although "irqpoll" is not a default kernel option, it's used in some contexts,
one being the kdump kernel (which is an already "impaired" kernel usually
running with 1 CPU available), so the performance burden could be considerable.
Also, the same issue would happen (in a shorter extent though) when using
"irqfixup" kernel option.
In a quick experiment, a virtual machine with uptime of 2 minutes produced
>300 calls to hpet_rtc_interrupt() when "irqpoll" was set, whereas without
sharing interrupts this number reduced to 1 interrupt. Machines with more
hardware than a VM should generate even more unnecessary HPET interrupts
in this scenario.
---8<---8<---8<---
After looking into the rtc-cmos driver history and DSDT table from
the Microsoft Surface 3, we may notice that Hans de Goede submitted
a correct fix (see dependency below). Thus, we simply revert
the culprit commit.
Fixes: 079062b28fb4 ("rtc: cmos: prevent kernel warning on IRQ flags mismatch")
Depends-on: a1e23a42f1bd ("rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqs")
Reported-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200123131437.28157-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2020-01-23 21:14:35 +08:00
|
|
|
0, dev_name(&cmos_rtc.rtc->dev),
|
2007-05-08 15:33:30 +08:00
|
|
|
cmos_rtc.rtc);
|
2008-02-06 17:38:52 +08:00
|
|
|
if (retval < 0) {
|
|
|
|
dev_dbg(dev, "IRQ %d is already in use\n", rtc_irq);
|
|
|
|
goto cleanup1;
|
|
|
|
}
|
2018-09-04 22:51:29 +08:00
|
|
|
} else {
|
2021-01-11 07:17:39 +08:00
|
|
|
clear_bit(RTC_FEATURE_ALARM, cmos_rtc.rtc->features);
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
}
|
|
|
|
|
2021-01-11 07:17:39 +08:00
|
|
|
cmos_rtc.rtc->ops = &cmos_rtc_ops;
|
|
|
|
|
2020-11-10 00:34:08 +08:00
|
|
|
retval = devm_rtc_register_device(cmos_rtc.rtc);
|
2018-02-13 06:47:45 +08:00
|
|
|
if (retval)
|
2008-02-06 17:38:43 +08:00
|
|
|
goto cleanup2;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
2020-12-07 05:46:16 +08:00
|
|
|
/* Set the sync offset for the periodic 11min update correct */
|
2020-12-07 05:46:20 +08:00
|
|
|
cmos_rtc.rtc->set_offset_nsec = NSEC_PER_SEC / 2;
|
2020-12-07 05:46:16 +08:00
|
|
|
|
2018-02-13 06:47:46 +08:00
|
|
|
/* export at least the first block of NVRAM */
|
|
|
|
nvmem_cfg.size = address_space - NVRAM_OFFSET;
|
2020-11-10 00:34:07 +08:00
|
|
|
devm_rtc_nvmem_register(cmos_rtc.rtc, &nvmem_cfg);
|
2018-02-13 06:47:46 +08:00
|
|
|
|
|
|
|
dev_info(dev, "%s%s, %d bytes nvram%s\n",
|
|
|
|
!is_valid_irq(rtc_irq) ? "no alarms" :
|
|
|
|
cmos_rtc.mon_alrm ? "alarms up to one year" :
|
|
|
|
cmos_rtc.day_alrm ? "alarms up to one month" :
|
|
|
|
"alarms up to one day",
|
|
|
|
cmos_rtc.century ? ", y3k" : "",
|
|
|
|
nvmem_cfg.size,
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
use_hpet_alarm() ? ", hpet irqs" : "");
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
2008-02-06 17:38:43 +08:00
|
|
|
cleanup2:
|
|
|
|
if (is_valid_irq(rtc_irq))
|
|
|
|
free_irq(rtc_irq, cmos_rtc.rtc);
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
cleanup1:
|
2007-10-16 16:28:21 +08:00
|
|
|
cmos_rtc.dev = NULL;
|
|
|
|
cleanup0:
|
drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-07 05:35:49 +08:00
|
|
|
if (RTC_IOMAPPED)
|
|
|
|
release_region(ports->start, resource_size(ports));
|
|
|
|
else
|
|
|
|
release_mem_region(ports->start, resource_size(ports));
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-07 05:35:49 +08:00
|
|
|
static void cmos_do_shutdown(int rtc_irq)
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
{
|
|
|
|
spin_lock_irq(&rtc_lock);
|
drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-07 05:35:49 +08:00
|
|
|
if (is_valid_irq(rtc_irq))
|
|
|
|
cmos_irq_disable(&cmos_rtc, RTC_IRQMASK);
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
spin_unlock_irq(&rtc_lock);
|
|
|
|
}
|
|
|
|
|
2016-10-18 22:39:54 +08:00
|
|
|
static void cmos_do_remove(struct device *dev)
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
{
|
|
|
|
struct cmos_rtc *cmos = dev_get_drvdata(dev);
|
2007-10-16 16:28:21 +08:00
|
|
|
struct resource *ports;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-07 05:35:49 +08:00
|
|
|
cmos_do_shutdown(cmos->irq);
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
2008-02-06 17:38:52 +08:00
|
|
|
if (is_valid_irq(cmos->irq)) {
|
2007-10-16 16:28:21 +08:00
|
|
|
free_irq(cmos->irq, cmos->rtc);
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
if (use_hpet_alarm())
|
|
|
|
hpet_unregister_irq_handler(cmos_interrupt);
|
2008-02-06 17:38:52 +08:00
|
|
|
}
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
2007-10-16 16:28:21 +08:00
|
|
|
cmos->rtc = NULL;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
2007-10-16 16:28:21 +08:00
|
|
|
ports = cmos->iomem;
|
drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-07 05:35:49 +08:00
|
|
|
if (RTC_IOMAPPED)
|
|
|
|
release_region(ports->start, resource_size(ports));
|
|
|
|
else
|
|
|
|
release_mem_region(ports->start, resource_size(ports));
|
2007-10-16 16:28:21 +08:00
|
|
|
cmos->iomem = NULL;
|
|
|
|
|
|
|
|
cmos->dev = NULL;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
}
|
|
|
|
|
rtc: cmos: Cancel alarm timer if alarm time is equal to now+1 seconds
Steps to reproduce the problem:
1) Enable RTC wake-up option in BIOS Setup
2) Issue one of these commands in the OS: "poweroff"
or "shutdown -h now"
3) System will shut down and then reboot automatically
Root-cause of the issue:
1) During the shutdown process, the hwclock utility is used
to save the system clock to hardware clock (RTC).
2) The hwclock utility invokes ioctl() with RTC_UIE_ON. The
kernel configures the RTC alarm for the periodic interrupt
(every 1 second).
3) The hwclock uitlity closes the /dev/rtc0 device, and the
kernel disables the RTC alarm irq (AIE bit of Register B)
via ioctl() with RTC_UIE_OFF. But, the configured alarm
time is the current_time + 1.
4) After the next 1 second is elapsed, the AF (alarm
interrupt flag) of Register C is set.
5) The S5 handler in BIOS is invoked to configure alarm
registers (enable AIE bit and configure alarm date/time).
But, BIOS does not clear the previous interrupt status
during alarm configuration. Therefore, "AF=AIE=1" causes
the rtc device to trigger an interrupt.
6) So, the machine reboots automatically right after shutdown.
This patch cancels the alarm timer if the following condictions are
met (suggested by Alexandre):
1) The configured alarm time is equal to current_time + 1
seconds.
2) The AIE timer is not in use.
The member 'alarm_expires' is introduced in struct cmos_rtc because
of the following reasons:
1) The configured alarm time can be retrieved from
cmos_read_alarm(), but we need to take the 'wrapped
timestamp' and 'time rollover' into consideration. The
function __rtc_read_alarm() eliminates the concerns. To
avoid the duplicated code in the lower level RTC driver,
invoking __rtc_read_alarm from the lower level RTC driver
is not encouraged. Moreover, the compilation error 'the
undefined __rtc_read_alarm" is observed if the lower level
RTC driver is compiled as a kernel module.
2) The uie_rtctimer.node.expires and aie_timer.node.expires can
be retrieved for the configured alarm time. But, the problem
is that either of them might configure the CMOS alarm time.
We cannot make sure UIE timer or AIE tiemr configured the
CMOS alarm time before. (uie_rtctimer or aie_timer is enabled
and then is disabled).
3) The patch introduces the member 'alarm_expires' to keep the
newly configured alarm time, so the above-mentioned concerns
can be eliminated.
The issue goes away after 20-time shutdown tests.
Signed-off-by: Adrian Huang <ahuang12@lenovo.com>
Tested-by: Egbert Eich <eich@suse.de>
Tested-by: Diego Ercolani <diego.ercolani@gmail.com>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2015-07-06 12:19:12 +08:00
|
|
|
static int cmos_aie_poweroff(struct device *dev)
|
|
|
|
{
|
|
|
|
struct cmos_rtc *cmos = dev_get_drvdata(dev);
|
|
|
|
struct rtc_time now;
|
|
|
|
time64_t t_now;
|
|
|
|
int retval = 0;
|
|
|
|
unsigned char rtc_control;
|
|
|
|
|
|
|
|
if (!cmos->alarm_expires)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
spin_lock_irq(&rtc_lock);
|
|
|
|
rtc_control = CMOS_READ(RTC_CONTROL);
|
|
|
|
spin_unlock_irq(&rtc_lock);
|
|
|
|
|
|
|
|
/* We only care about the situation where AIE is disabled. */
|
|
|
|
if (rtc_control & RTC_AIE)
|
|
|
|
return -EBUSY;
|
|
|
|
|
|
|
|
cmos_read_time(dev, &now);
|
|
|
|
t_now = rtc_tm_to_time64(&now);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When enabling "RTC wake-up" in BIOS setup, the machine reboots
|
|
|
|
* automatically right after shutdown on some buggy boxes.
|
|
|
|
* This automatic rebooting issue won't happen when the alarm
|
|
|
|
* time is larger than now+1 seconds.
|
|
|
|
*
|
|
|
|
* If the alarm time is equal to now+1 seconds, the issue can be
|
|
|
|
* prevented by cancelling the alarm.
|
|
|
|
*/
|
|
|
|
if (cmos->alarm_expires == t_now + 1) {
|
|
|
|
struct rtc_wkalrm alarm;
|
|
|
|
|
|
|
|
/* Cancel the AIE timer by configuring the past time. */
|
|
|
|
rtc_time64_to_tm(t_now - 1, &alarm.time);
|
|
|
|
alarm.enabled = 0;
|
|
|
|
retval = cmos_set_alarm(dev, &alarm);
|
|
|
|
} else if (cmos->alarm_expires > t_now + 1) {
|
|
|
|
retval = -EBUSY;
|
|
|
|
}
|
|
|
|
|
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
2011-01-13 09:00:07 +08:00
|
|
|
static int cmos_suspend(struct device *dev)
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
{
|
|
|
|
struct cmos_rtc *cmos = dev_get_drvdata(dev);
|
2007-04-02 14:49:47 +08:00
|
|
|
unsigned char tmp;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
|
|
|
/* only the alarm might be a wakeup event source */
|
|
|
|
spin_lock_irq(&rtc_lock);
|
|
|
|
cmos->suspend_ctrl = tmp = CMOS_READ(RTC_CONTROL);
|
|
|
|
if (tmp & (RTC_PIE|RTC_AIE|RTC_UIE)) {
|
2008-07-24 12:30:43 +08:00
|
|
|
unsigned char mask;
|
2007-04-02 14:49:47 +08:00
|
|
|
|
2008-09-03 05:36:11 +08:00
|
|
|
if (device_may_wakeup(dev))
|
2008-07-24 12:30:43 +08:00
|
|
|
mask = RTC_IRQMASK & ~RTC_AIE;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
else
|
2008-07-24 12:30:43 +08:00
|
|
|
mask = RTC_IRQMASK;
|
|
|
|
tmp &= ~mask;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
CMOS_WRITE(tmp, RTC_CONTROL);
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
if (use_hpet_alarm())
|
|
|
|
hpet_mask_rtc_irq_bit(mask);
|
2008-07-24 12:30:47 +08:00
|
|
|
cmos_checkintr(cmos, tmp);
|
2007-04-02 14:49:47 +08:00
|
|
|
}
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
spin_unlock_irq(&rtc_lock);
|
|
|
|
|
2018-10-02 09:09:05 +08:00
|
|
|
if ((tmp & RTC_AIE) && !cmos_use_acpi_alarm()) {
|
rtc-cmos wakeup interface
I finally got around to testing the updated wakeup event hooks for rtc-cmos,
and they follow in two patches:
- Interface update ... when a simple enable_irq_wake() doesn't suffice,
the platform data can hold suspend/resume callback hooks.
- ACPI implementation ... provides callback hooks to do ACPI magic, and
eliminate the legacy /proc/acpi/alarm file.
The interface update could go into 2.6.21, but that's not essential; they
will be NOPs on most PCs, without the ACPI stuff.
I suspect the ACPI folk may have opinions about how to merge that second
patch, and how to obsolete that legacy procfs file. I'd like to see that
merge into 2.6.22 if possible...
As for how to kick it in ... two ways:
- The appended "rtcwake" program; updated since the last time it was
posted, it deals much better with timezones and DST.
- Write the /sys/class/rtc/.../wakealarm file, then go to sleep.
For some reason RTC wake from "swsusp" stopped working on a system where
it previously worked; the alarm setting appears to get clobbered. But
on the bright side, RTC wake from "standby" worked on a system that had
never been able to resume from that state before ... IDEACPI is my guess
as to why it finally started to work. It's the old "two steps forward,
one step back" dance, I guess.
- Dave
/* gcc -Wall -Os -o rtcwake rtcwake.c */
#include <stdio.h>
#include <getopt.h>
#include <fcntl.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <time.h>
#include <sys/ioctl.h>
#include <sys/time.h>
#include <sys/types.h>
#include <linux/rtc.h>
/* constants from legacy PC/AT hardware */
#define RTC_PF 0x40
#define RTC_AF 0x20
#define RTC_UF 0x10
/*
* rtcwake -- enter a system sleep state until specified wakeup time.
*
* This uses cross-platform Linux interfaces to enter a system sleep state,
* and leave it no later than a specified time. It uses any RTC framework
* driver that supports standard driver model wakeup flags.
*
* This is normally used like the old "apmsleep" utility, to wake from a
* suspend state like ACPI S1 (standby) or S3 (suspend-to-RAM). Most
* platforms can implement those without analogues of BIOS, APM, or ACPI.
*
* On some systems, this can also be used like "nvram-wakeup", waking
* from states like ACPI S4 (suspend to disk). Not all systems have
* persistent media that are appropriate for such suspend modes.
*
* The best way to set the system's RTC is so that it holds the current
* time in UTC. Use the "-l" flag to tell this program that the system
* RTC uses a local timezone instead (maybe you dual-boot MS-Windows).
*/
static char *progname;
#ifdef DEBUG
#define VERSION "1.0 dev (" __DATE__ " " __TIME__ ")"
#else
#define VERSION "0.9"
#endif
static unsigned verbose;
static int rtc_is_utc = -1;
static int may_wakeup(const char *devname)
{
char buf[128], *s;
FILE *f;
snprintf(buf, sizeof buf, "/sys/class/rtc/%s/device/power/wakeup",
devname);
f = fopen(buf, "r");
if (!f) {
perror(buf);
return 0;
}
fgets(buf, sizeof buf, f);
fclose(f);
s = strchr(buf, '\n');
if (!s)
return 0;
*s = 0;
/* wakeup events could be disabled or not supported */
return strcmp(buf, "enabled") == 0;
}
/* all times should be in UTC */
static time_t sys_time;
static time_t rtc_time;
static int get_basetimes(int fd)
{
struct tm tm;
struct rtc_time rtc;
/* this process works in RTC time, except when working
* with the system clock (which always uses UTC).
*/
if (rtc_is_utc)
setenv("TZ", "UTC", 1);
tzset();
/* read rtc and system clocks "at the same time", or as
* precisely (+/- a second) as we can read them.
*/
if (ioctl(fd, RTC_RD_TIME, &rtc) < 0) {
perror("read rtc time");
return 0;
}
sys_time = time(0);
if (sys_time == (time_t)-1) {
perror("read system time");
return 0;
}
/* convert rtc_time to normal arithmetic-friendly form,
* updating tm.tm_wday as used by asctime().
*/
memset(&tm, 0, sizeof tm);
tm.tm_sec = rtc.tm_sec;
tm.tm_min = rtc.tm_min;
tm.tm_hour = rtc.tm_hour;
tm.tm_mday = rtc.tm_mday;
tm.tm_mon = rtc.tm_mon;
tm.tm_year = rtc.tm_year;
tm.tm_isdst = rtc.tm_isdst; /* stays unspecified? */
rtc_time = mktime(&tm);
if (rtc_time == (time_t)-1) {
perror("convert rtc time");
return 0;
}
if (verbose) {
if (!rtc_is_utc) {
printf("\ttzone = %ld\n", timezone);
printf("\ttzname = %s\n", tzname[daylight]);
gmtime_r(&rtc_time, &tm);
}
printf("\tsystime = %ld, (UTC) %s",
(long) sys_time, asctime(gmtime(&sys_time)));
printf("\trtctime = %ld, (UTC) %s",
(long) rtc_time, asctime(&tm));
}
return 1;
}
static int setup_alarm(int fd, time_t *wakeup)
{
struct tm *tm;
struct rtc_wkalrm wake;
tm = gmtime(wakeup);
wake.time.tm_sec = tm->tm_sec;
wake.time.tm_min = tm->tm_min;
wake.time.tm_hour = tm->tm_hour;
wake.time.tm_mday = tm->tm_mday;
wake.time.tm_mon = tm->tm_mon;
wake.time.tm_year = tm->tm_year;
wake.time.tm_wday = tm->tm_wday;
wake.time.tm_yday = tm->tm_yday;
wake.time.tm_isdst = tm->tm_isdst;
/* many rtc alarms only support up to 24 hours from 'now' ... */
if ((rtc_time + (24 * 60 * 60)) > *wakeup) {
if (ioctl(fd, RTC_ALM_SET, &wake.time) < 0) {
perror("set rtc alarm");
return 0;
}
if (ioctl(fd, RTC_AIE_ON, 0) < 0) {
perror("enable rtc alarm");
return 0;
}
/* ... so use the "more than 24 hours" request only if we must */
} else {
/* avoid an extra AIE_ON call */
wake.enabled = 1;
if (ioctl(fd, RTC_WKALM_SET, &wake) < 0) {
perror("set rtc wake alarm");
return 0;
}
}
return 1;
}
static void suspend_system(const char *suspend)
{
FILE *f = fopen("/sys/power/state", "w");
if (!f) {
perror("/sys/power/state");
return;
}
fprintf(f, "%s\n", suspend);
fflush(f);
/* this executes after wake from suspend */
fclose(f);
}
int main(int argc, char **argv)
{
static char *devname = "rtc0";
static unsigned seconds = 0;
static char *suspend = "standby";
int t;
int fd;
time_t alarm = 0;
progname = strrchr(argv[0], '/');
if (progname)
progname++;
else
progname = argv[0];
if (chdir("/dev/") < 0) {
perror("chdir /dev");
return 1;
}
while ((t = getopt(argc, argv, "d:lm:s:t:uVv")) != EOF) {
switch (t) {
case 'd':
devname = optarg;
break;
case 'l':
rtc_is_utc = 0;
break;
/* what system power mode to use? for now handle only
* standardized mode names; eventually when systems define
* their own state names, parse /sys/power/state.
*
* "on" is used just to test the RTC alarm mechanism,
* bypassing all the wakeup-from-sleep infrastructure.
*/
case 'm':
if (strcmp(optarg, "standby") == 0
|| strcmp(optarg, "mem") == 0
|| strcmp(optarg, "disk") == 0
|| strcmp(optarg, "on") == 0
) {
suspend = optarg;
break;
}
printf("%s: unrecognized suspend state '%s'\n",
progname, optarg);
goto usage;
/* alarm time, seconds-to-sleep (relative) */
case 's':
t = atoi(optarg);
if (t < 0) {
printf("%s: illegal interval %s seconds\n",
progname, optarg);
goto usage;
}
seconds = t;
break;
/* alarm time, time_t (absolute, seconds since 1/1 1970 UTC) */
case 't':
t = atoi(optarg);
if (t < 0) {
printf("%s: illegal time_t value %s\n",
progname, optarg);
goto usage;
}
alarm = t;
break;
case 'u':
rtc_is_utc = 1;
break;
case 'v':
verbose++;
break;
case 'V':
printf("%s: version %s\n", progname, VERSION);
break;
default:
usage:
printf("usage: %s [options]"
"\n\t"
"-d rtc0|rtc1|...\t(select rtc)"
"\n\t"
"-l\t\t\t(RTC uses local timezone)"
"\n\t"
"-m standby|mem|...\t(sleep mode)"
"\n\t"
"-s seconds\t\t(seconds to sleep)"
"\n\t"
"-t time_t\t\t(time to wake)"
"\n\t"
"-u\t\t\t(RTC uses UTC)"
"\n\t"
"-v\t\t\t(verbose messages)"
"\n\t"
"-V\t\t\t(show version)"
"\n",
progname);
return 1;
}
}
if (!alarm && !seconds) {
printf("%s: must provide wake time\n", progname);
goto usage;
}
/* REVISIT: if /etc/adjtime exists, read it to see what
* the util-linux version of hwclock assumes.
*/
if (rtc_is_utc == -1) {
printf("%s: assuming RTC uses UTC ...\n", progname);
rtc_is_utc = 1;
}
/* this RTC must exist and (if we'll sleep) be wakeup-enabled */
fd = open(devname, O_RDONLY);
if (fd < 0) {
perror(devname);
return 1;
}
if (strcmp(suspend, "on") != 0 && !may_wakeup(devname)) {
printf("%s: %s not enabled for wakeup events\n",
progname, devname);
return 1;
}
/* relative or absolute alarm time, normalized to time_t */
if (!get_basetimes(fd))
return 1;
if (verbose)
printf("alarm %ld, sys_time %ld, rtc_time %ld, seconds %u\n",
alarm, sys_time, rtc_time, seconds);
if (alarm) {
if (alarm < sys_time) {
printf("%s: time doesn't go backward to %s",
progname, ctime(&alarm));
return 1;
}
alarm += sys_time - rtc_time;
} else
alarm = rtc_time + seconds + 1;
if (setup_alarm(fd, &alarm) < 0)
return 1;
sync();
printf("%s: wakeup from \"%s\" using %s at %s",
progname, suspend, devname,
ctime(&alarm));
fflush(stdout);
usleep(10 * 1000);
if (strcmp(suspend, "on") != 0)
suspend_system(suspend);
else {
unsigned long data;
do {
t = read(fd, &data, sizeof data);
if (t < 0) {
perror("rtc read");
break;
}
if (verbose)
printf("... %s: %03lx\n", devname, data);
} while (!(data & RTC_AF));
}
if (ioctl(fd, RTC_AIE_OFF, 0) < 0)
perror("disable rtc alarm interrupt");
close(fd);
return 0;
}
This patch:
Make rtc-cmos do the relevant magic so this RTC can wake the system from a
sleep state. That magic comes in two basic flavors:
- Straightforward: enable_irq_wake(), the way it'd work on most SOC chips;
or generally with system sleep states which don't disable core IRQ logic.
- Roundabout, using non-IRQ platform hooks. This is needed with ACPI and
one almost-clone chip which uses a special wakeup-only alarm. (That's
the RTC used on Footbridge boards, FWIW, which don't do PM in Linux.)
A separate patch implements those hooks for ACPI platforms, so that rtc_cmos
can issue system wakeup events (and its sysfs "wakealarm" attribute works on
at least some systems).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-08 15:34:00 +08:00
|
|
|
cmos->enabled_wake = 1;
|
|
|
|
if (cmos->wake_on)
|
|
|
|
cmos->wake_on(dev);
|
|
|
|
else
|
|
|
|
enable_irq_wake(cmos->irq);
|
|
|
|
}
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
2020-08-14 17:17:30 +08:00
|
|
|
memset(&cmos->saved_wkalrm, 0, sizeof(struct rtc_wkalrm));
|
2016-09-20 07:12:44 +08:00
|
|
|
cmos_read_alarm(dev, &cmos->saved_wkalrm);
|
|
|
|
|
2013-02-22 08:45:34 +08:00
|
|
|
dev_dbg(dev, "suspend%s, ctrl %02x\n",
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
(tmp & RTC_AIE) ? ", alarm may wake" : "",
|
|
|
|
tmp);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-09-03 05:36:11 +08:00
|
|
|
/* We want RTC alarms to wake us from e.g. ACPI G2/S5 "soft off", even
|
|
|
|
* after a detour through G3 "mechanical off", although the ACPI spec
|
|
|
|
* says wakeup should only work from G1/S4 "hibernate". To most users,
|
|
|
|
* distinctions between S4 and S5 are pointless. So when the hardware
|
|
|
|
* allows, don't draw that distinction.
|
|
|
|
*/
|
|
|
|
static inline int cmos_poweroff(struct device *dev)
|
|
|
|
{
|
2016-09-22 17:48:00 +08:00
|
|
|
if (!IS_ENABLED(CONFIG_PM))
|
|
|
|
return -ENOSYS;
|
|
|
|
|
2011-01-13 09:00:07 +08:00
|
|
|
return cmos_suspend(dev);
|
2008-09-03 05:36:11 +08:00
|
|
|
}
|
|
|
|
|
2016-09-20 07:12:44 +08:00
|
|
|
static void cmos_check_wkalrm(struct device *dev)
|
|
|
|
{
|
|
|
|
struct cmos_rtc *cmos = dev_get_drvdata(dev);
|
|
|
|
struct rtc_wkalrm current_alarm;
|
rtc: cmos: acknowledge ACPI driven wake alarms upon resume
Previously, the RTC alarm is acknowledged either by the cmos rtc irq
handler, or by the hpet rtc irq handler.
When using ACPI RTC Fixed event as the RTC alarm, the RTC alarm is
acknowledged by the ACPI RTC event handler, as addressed in the previous
patch.
But, when resume from suspend-to-ram (ACPI S3), the ACPI SCI is cleared
right after resume, thus the ACPI RTC event handler is not invoked at all,
results in the RTC Alarm unacknowledged.
Handle this by comparing the current time and the RTC Alarm time in the
rtc_cmos driver .resume() callback
1. Assume the wakeup event has already been fired if the RTC Alarm time
is earlier than/equal to the current time, and ACK the RTC Alarm.
2. Assume the wakeup event has not been fired if the RTC Alarm time
is later than current time, and re-arm it if needed.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:02 +08:00
|
|
|
time64_t t_now;
|
2016-09-20 07:12:44 +08:00
|
|
|
time64_t t_current_expires;
|
|
|
|
time64_t t_saved_expires;
|
rtc: cmos: acknowledge ACPI driven wake alarms upon resume
Previously, the RTC alarm is acknowledged either by the cmos rtc irq
handler, or by the hpet rtc irq handler.
When using ACPI RTC Fixed event as the RTC alarm, the RTC alarm is
acknowledged by the ACPI RTC event handler, as addressed in the previous
patch.
But, when resume from suspend-to-ram (ACPI S3), the ACPI SCI is cleared
right after resume, thus the ACPI RTC event handler is not invoked at all,
results in the RTC Alarm unacknowledged.
Handle this by comparing the current time and the RTC Alarm time in the
rtc_cmos driver .resume() callback
1. Assume the wakeup event has already been fired if the RTC Alarm time
is earlier than/equal to the current time, and ACK the RTC Alarm.
2. Assume the wakeup event has not been fired if the RTC Alarm time
is later than current time, and re-arm it if needed.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:02 +08:00
|
|
|
struct rtc_time now;
|
|
|
|
|
|
|
|
/* Check if we have RTC Alarm armed */
|
|
|
|
if (!(cmos->suspend_ctrl & RTC_AIE))
|
|
|
|
return;
|
|
|
|
|
|
|
|
cmos_read_time(dev, &now);
|
|
|
|
t_now = rtc_tm_to_time64(&now);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ACPI RTC wake event is cleared after resume from STR,
|
|
|
|
* ACK the rtc irq here
|
|
|
|
*/
|
2018-10-02 09:09:05 +08:00
|
|
|
if (t_now >= cmos->alarm_expires && cmos_use_acpi_alarm()) {
|
2021-03-05 20:21:40 +08:00
|
|
|
local_irq_disable();
|
rtc: cmos: acknowledge ACPI driven wake alarms upon resume
Previously, the RTC alarm is acknowledged either by the cmos rtc irq
handler, or by the hpet rtc irq handler.
When using ACPI RTC Fixed event as the RTC alarm, the RTC alarm is
acknowledged by the ACPI RTC event handler, as addressed in the previous
patch.
But, when resume from suspend-to-ram (ACPI S3), the ACPI SCI is cleared
right after resume, thus the ACPI RTC event handler is not invoked at all,
results in the RTC Alarm unacknowledged.
Handle this by comparing the current time and the RTC Alarm time in the
rtc_cmos driver .resume() callback
1. Assume the wakeup event has already been fired if the RTC Alarm time
is earlier than/equal to the current time, and ACK the RTC Alarm.
2. Assume the wakeup event has not been fired if the RTC Alarm time
is later than current time, and re-arm it if needed.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:02 +08:00
|
|
|
cmos_interrupt(0, (void *)cmos->rtc);
|
2021-03-05 20:21:40 +08:00
|
|
|
local_irq_enable();
|
rtc: cmos: acknowledge ACPI driven wake alarms upon resume
Previously, the RTC alarm is acknowledged either by the cmos rtc irq
handler, or by the hpet rtc irq handler.
When using ACPI RTC Fixed event as the RTC alarm, the RTC alarm is
acknowledged by the ACPI RTC event handler, as addressed in the previous
patch.
But, when resume from suspend-to-ram (ACPI S3), the ACPI SCI is cleared
right after resume, thus the ACPI RTC event handler is not invoked at all,
results in the RTC Alarm unacknowledged.
Handle this by comparing the current time and the RTC Alarm time in the
rtc_cmos driver .resume() callback
1. Assume the wakeup event has already been fired if the RTC Alarm time
is earlier than/equal to the current time, and ACK the RTC Alarm.
2. Assume the wakeup event has not been fired if the RTC Alarm time
is later than current time, and re-arm it if needed.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:02 +08:00
|
|
|
return;
|
|
|
|
}
|
2016-09-20 07:12:44 +08:00
|
|
|
|
2020-08-14 17:17:30 +08:00
|
|
|
memset(¤t_alarm, 0, sizeof(struct rtc_wkalrm));
|
2016-09-20 07:12:44 +08:00
|
|
|
cmos_read_alarm(dev, ¤t_alarm);
|
|
|
|
t_current_expires = rtc_tm_to_time64(¤t_alarm.time);
|
|
|
|
t_saved_expires = rtc_tm_to_time64(&cmos->saved_wkalrm.time);
|
|
|
|
if (t_current_expires != t_saved_expires ||
|
|
|
|
cmos->saved_wkalrm.enabled != current_alarm.enabled) {
|
|
|
|
cmos_set_alarm(dev, &cmos->saved_wkalrm);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-09-20 07:12:43 +08:00
|
|
|
static void cmos_check_acpi_rtc_status(struct device *dev,
|
|
|
|
unsigned char *rtc_control);
|
|
|
|
|
2016-09-22 17:48:00 +08:00
|
|
|
static int __maybe_unused cmos_resume(struct device *dev)
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
{
|
|
|
|
struct cmos_rtc *cmos = dev_get_drvdata(dev);
|
2013-07-04 06:07:54 +08:00
|
|
|
unsigned char tmp;
|
|
|
|
|
2018-10-02 09:09:05 +08:00
|
|
|
if (cmos->enabled_wake && !cmos_use_acpi_alarm()) {
|
2013-07-04 06:07:54 +08:00
|
|
|
if (cmos->wake_off)
|
|
|
|
cmos->wake_off(dev);
|
|
|
|
else
|
|
|
|
disable_irq_wake(cmos->irq);
|
|
|
|
cmos->enabled_wake = 0;
|
|
|
|
}
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
2016-09-20 07:12:44 +08:00
|
|
|
/* The BIOS might have changed the alarm, restore it */
|
|
|
|
cmos_check_wkalrm(dev);
|
|
|
|
|
2013-07-04 06:07:54 +08:00
|
|
|
spin_lock_irq(&rtc_lock);
|
|
|
|
tmp = cmos->suspend_ctrl;
|
|
|
|
cmos->suspend_ctrl = 0;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
/* re-enable any irqs previously active */
|
2008-07-24 12:30:43 +08:00
|
|
|
if (tmp & RTC_IRQMASK) {
|
|
|
|
unsigned char mask;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
if (device_may_wakeup(dev) && use_hpet_alarm())
|
2013-06-13 05:04:45 +08:00
|
|
|
hpet_rtc_timer_init();
|
|
|
|
|
2008-07-24 12:30:43 +08:00
|
|
|
do {
|
|
|
|
CMOS_WRITE(tmp, RTC_CONTROL);
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
if (use_hpet_alarm())
|
|
|
|
hpet_set_rtc_irq_bit(tmp & RTC_IRQMASK);
|
2008-07-24 12:30:43 +08:00
|
|
|
|
|
|
|
mask = CMOS_READ(RTC_INTR_FLAGS);
|
|
|
|
mask &= (tmp & RTC_IRQMASK) | RTC_IRQF;
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
if (!use_hpet_alarm() || !is_intr(mask))
|
2008-07-24 12:30:43 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
/* force one-shot behavior if HPET blocked
|
|
|
|
* the wake alarm's irq
|
|
|
|
*/
|
|
|
|
rtc_update_irq(cmos->rtc, 1, mask);
|
|
|
|
tmp &= ~RTC_AIE;
|
|
|
|
hpet_mask_rtc_irq_bit(RTC_AIE);
|
|
|
|
} while (mask & RTC_AIE);
|
2016-09-20 07:12:43 +08:00
|
|
|
|
|
|
|
if (tmp & RTC_AIE)
|
|
|
|
cmos_check_acpi_rtc_status(dev, &tmp);
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
}
|
2013-07-04 06:07:54 +08:00
|
|
|
spin_unlock_irq(&rtc_lock);
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
2013-02-22 08:45:34 +08:00
|
|
|
dev_dbg(dev, "resume, ctrl %02x\n", tmp);
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-04-04 05:50:05 +08:00
|
|
|
static SIMPLE_DEV_PM_OPS(cmos_pm_ops, cmos_suspend, cmos_resume);
|
|
|
|
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
/*----------------------------------------------------------------*/
|
|
|
|
|
2008-02-06 17:38:43 +08:00
|
|
|
/* On non-x86 systems, a "CMOS" RTC lives most naturally on platform_bus.
|
|
|
|
* ACPI systems always list these as PNPACPI devices, and pre-ACPI PCs
|
|
|
|
* probably list them in similar PNPBIOS tables; so PNP is more common.
|
|
|
|
*
|
|
|
|
* We don't use legacy "poke at the hardware" probing. Ancient PCs that
|
|
|
|
* predate even PNPBIOS should set up platform_bus devices.
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
*/
|
|
|
|
|
2008-10-15 03:50:21 +08:00
|
|
|
#ifdef CONFIG_ACPI
|
|
|
|
|
|
|
|
#include <linux/acpi.h>
|
|
|
|
|
|
|
|
static u32 rtc_handler(void *context)
|
|
|
|
{
|
2012-05-19 04:59:41 +08:00
|
|
|
struct device *dev = context;
|
2016-09-20 07:12:43 +08:00
|
|
|
struct cmos_rtc *cmos = dev_get_drvdata(dev);
|
|
|
|
unsigned char rtc_control = 0;
|
|
|
|
unsigned char rtc_intr;
|
2016-10-20 02:02:04 +08:00
|
|
|
unsigned long flags;
|
2016-09-20 07:12:43 +08:00
|
|
|
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Always update rtc irq when ACPI is used as RTC Alarm.
|
|
|
|
* Or else, ACPI SCI is enabled during suspend/resume only,
|
|
|
|
* update rtc irq in that case.
|
|
|
|
*/
|
2018-10-02 09:09:05 +08:00
|
|
|
if (cmos_use_acpi_alarm())
|
rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-26 21:58:01 +08:00
|
|
|
cmos_interrupt(0, (void *)cmos->rtc);
|
|
|
|
else {
|
|
|
|
/* Fix me: can we use cmos_interrupt() here as well? */
|
|
|
|
spin_lock_irqsave(&rtc_lock, flags);
|
|
|
|
if (cmos_rtc.suspend_ctrl)
|
|
|
|
rtc_control = CMOS_READ(RTC_CONTROL);
|
|
|
|
if (rtc_control & RTC_AIE) {
|
|
|
|
cmos_rtc.suspend_ctrl &= ~RTC_AIE;
|
|
|
|
CMOS_WRITE(rtc_control, RTC_CONTROL);
|
|
|
|
rtc_intr = CMOS_READ(RTC_INTR_FLAGS);
|
|
|
|
rtc_update_irq(cmos->rtc, 1, rtc_intr);
|
|
|
|
}
|
|
|
|
spin_unlock_irqrestore(&rtc_lock, flags);
|
2016-09-20 07:12:43 +08:00
|
|
|
}
|
2012-05-19 04:59:41 +08:00
|
|
|
|
2017-05-14 08:23:12 +08:00
|
|
|
pm_wakeup_hard_event(dev);
|
2008-10-15 03:50:21 +08:00
|
|
|
acpi_clear_event(ACPI_EVENT_RTC);
|
|
|
|
acpi_disable_event(ACPI_EVENT_RTC, 0);
|
|
|
|
return ACPI_INTERRUPT_HANDLED;
|
|
|
|
}
|
|
|
|
|
2012-05-19 04:59:41 +08:00
|
|
|
static inline void rtc_wake_setup(struct device *dev)
|
2008-10-15 03:50:21 +08:00
|
|
|
{
|
2022-10-19 00:09:31 +08:00
|
|
|
if (acpi_disabled)
|
|
|
|
return;
|
|
|
|
|
2012-05-19 04:59:41 +08:00
|
|
|
acpi_install_fixed_event_handler(ACPI_EVENT_RTC, rtc_handler, dev);
|
2008-10-15 03:50:21 +08:00
|
|
|
/*
|
|
|
|
* After the RTC handler is installed, the Fixed_RTC event should
|
|
|
|
* be disabled. Only when the RTC alarm is set will it be enabled.
|
|
|
|
*/
|
|
|
|
acpi_clear_event(ACPI_EVENT_RTC);
|
|
|
|
acpi_disable_event(ACPI_EVENT_RTC, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rtc_wake_on(struct device *dev)
|
|
|
|
{
|
|
|
|
acpi_clear_event(ACPI_EVENT_RTC);
|
|
|
|
acpi_enable_event(ACPI_EVENT_RTC, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rtc_wake_off(struct device *dev)
|
|
|
|
{
|
|
|
|
acpi_disable_event(ACPI_EVENT_RTC, 0);
|
|
|
|
}
|
|
|
|
|
2018-03-26 21:58:03 +08:00
|
|
|
#ifdef CONFIG_X86
|
|
|
|
/* Enable use_acpi_alarm mode for Intel platforms no earlier than 2015 */
|
|
|
|
static void use_acpi_alarm_quirks(void)
|
|
|
|
{
|
|
|
|
if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!is_hpet_enabled())
|
|
|
|
return;
|
|
|
|
|
2020-01-23 21:14:37 +08:00
|
|
|
if (dmi_get_bios_year() < 2015)
|
|
|
|
return;
|
|
|
|
|
|
|
|
use_acpi_alarm = true;
|
2018-03-26 21:58:03 +08:00
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline void use_acpi_alarm_quirks(void) { }
|
|
|
|
#endif
|
|
|
|
|
2008-10-15 03:50:21 +08:00
|
|
|
/* Every ACPI platform has a mc146818 compatible "cmos rtc". Here we find
|
|
|
|
* its device node and pass extra config data. This helps its driver use
|
|
|
|
* capabilities that the now-obsolete mc146818 didn't have, and informs it
|
|
|
|
* that this board's RTC is wakeup-capable (per ACPI spec).
|
|
|
|
*/
|
|
|
|
static struct cmos_rtc_board_info acpi_rtc_info;
|
|
|
|
|
2012-12-22 05:09:38 +08:00
|
|
|
static void cmos_wake_setup(struct device *dev)
|
2008-10-15 03:50:21 +08:00
|
|
|
{
|
|
|
|
if (acpi_disabled)
|
|
|
|
return;
|
|
|
|
|
2018-03-26 21:58:03 +08:00
|
|
|
use_acpi_alarm_quirks();
|
|
|
|
|
2008-10-15 03:50:21 +08:00
|
|
|
acpi_rtc_info.wake_on = rtc_wake_on;
|
|
|
|
acpi_rtc_info.wake_off = rtc_wake_off;
|
|
|
|
|
|
|
|
/* workaround bug in some ACPI tables */
|
|
|
|
if (acpi_gbl_FADT.month_alarm && !acpi_gbl_FADT.day_alarm) {
|
|
|
|
dev_dbg(dev, "bogus FADT month_alarm (%d)\n",
|
|
|
|
acpi_gbl_FADT.month_alarm);
|
|
|
|
acpi_gbl_FADT.month_alarm = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
acpi_rtc_info.rtc_day_alarm = acpi_gbl_FADT.day_alarm;
|
|
|
|
acpi_rtc_info.rtc_mon_alarm = acpi_gbl_FADT.month_alarm;
|
|
|
|
acpi_rtc_info.rtc_century = acpi_gbl_FADT.century;
|
|
|
|
|
|
|
|
/* NOTE: S4_RTC_WAKE is NOT currently useful to Linux */
|
|
|
|
if (acpi_gbl_FADT.flags & ACPI_FADT_S4_RTC_WAKE)
|
|
|
|
dev_info(dev, "RTC can wake from S4\n");
|
|
|
|
|
|
|
|
dev->platform_data = &acpi_rtc_info;
|
|
|
|
|
|
|
|
/* RTC always wakes from S1/S2/S3, and often S4/STD */
|
|
|
|
device_init_wakeup(dev, 1);
|
|
|
|
}
|
|
|
|
|
2016-09-20 07:12:43 +08:00
|
|
|
static void cmos_check_acpi_rtc_status(struct device *dev,
|
|
|
|
unsigned char *rtc_control)
|
|
|
|
{
|
|
|
|
struct cmos_rtc *cmos = dev_get_drvdata(dev);
|
|
|
|
acpi_event_status rtc_status;
|
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
if (acpi_gbl_FADT.flags & ACPI_FADT_FIXED_RTC)
|
|
|
|
return;
|
|
|
|
|
|
|
|
status = acpi_get_event_status(ACPI_EVENT_RTC, &rtc_status);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
dev_err(dev, "Could not get RTC status\n");
|
|
|
|
} else if (rtc_status & ACPI_EVENT_FLAG_SET) {
|
|
|
|
unsigned char mask;
|
|
|
|
*rtc_control &= ~RTC_AIE;
|
|
|
|
CMOS_WRITE(*rtc_control, RTC_CONTROL);
|
|
|
|
mask = CMOS_READ(RTC_INTR_FLAGS);
|
|
|
|
rtc_update_irq(cmos->rtc, 1, mask);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-10-15 03:50:21 +08:00
|
|
|
#else
|
|
|
|
|
2012-12-22 05:09:38 +08:00
|
|
|
static void cmos_wake_setup(struct device *dev)
|
2008-10-15 03:50:21 +08:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2016-09-20 07:12:43 +08:00
|
|
|
static void cmos_check_acpi_rtc_status(struct device *dev,
|
|
|
|
unsigned char *rtc_control)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2022-10-19 04:35:11 +08:00
|
|
|
static void rtc_wake_setup(struct device *dev)
|
|
|
|
{
|
|
|
|
}
|
2008-10-15 03:50:21 +08:00
|
|
|
#endif
|
|
|
|
|
2007-05-08 15:34:09 +08:00
|
|
|
#ifdef CONFIG_PNP
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
|
|
|
#include <linux/pnp.h>
|
|
|
|
|
2012-12-22 05:09:38 +08:00
|
|
|
static int cmos_pnp_probe(struct pnp_dev *pnp, const struct pnp_device_id *id)
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
{
|
rtc: cmos: Fix event handler registration ordering issue
Because acpi_install_fixed_event_handler() enables the event
automatically on success, it is incorrect to call it before the
handler routine passed to it is ready to handle events.
Unfortunately, the rtc-cmos driver does exactly the incorrect thing
by calling cmos_wake_setup(), which passes rtc_handler() to
acpi_install_fixed_event_handler(), before cmos_do_probe(), because
rtc_handler() uses dev_get_drvdata() to get to the cmos object
pointer and the driver data pointer is only populated in
cmos_do_probe().
This leads to a NULL pointer dereference in rtc_handler() on boot
if the RTC fixed event happens to be active at the init time.
To address this issue, change the initialization ordering of the
driver so that cmos_wake_setup() is always called after a successful
cmos_do_probe() call.
While at it, change cmos_pnp_probe() to call cmos_do_probe() after
the initial if () statement used for computing the IRQ argument to
be passed to cmos_do_probe() which is cleaner than calling it in
each branch of that if () (local variable "irq" can be of type int,
because it is passed to that function as an argument of type int).
Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check
ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number
of systems, because previously it only affected systems with
ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that
commit.
Fixes: 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0")
Fixes: a474aaedac99 ("rtc-cmos: move wake setup from ACPI glue into RTC driver")
Link: https://lore.kernel.org/linux-acpi/20221010141630.zfzi7mk7zvnmclzy@techsingularity.net/
Reported-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Mel Gorman <mgorman@techsingularity.net>
Link: https://lore.kernel.org/r/5629262.DvuYhMxLoT@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2022-10-13 02:07:01 +08:00
|
|
|
int irq, ret;
|
2008-10-15 03:50:21 +08:00
|
|
|
|
2022-10-19 00:09:31 +08:00
|
|
|
cmos_wake_setup(&pnp->dev);
|
|
|
|
|
2017-03-18 21:45:49 +08:00
|
|
|
if (pnp_port_start(pnp, 0) == 0x70 && !pnp_irq_valid(pnp, 0)) {
|
rtc: cmos: Fix event handler registration ordering issue
Because acpi_install_fixed_event_handler() enables the event
automatically on success, it is incorrect to call it before the
handler routine passed to it is ready to handle events.
Unfortunately, the rtc-cmos driver does exactly the incorrect thing
by calling cmos_wake_setup(), which passes rtc_handler() to
acpi_install_fixed_event_handler(), before cmos_do_probe(), because
rtc_handler() uses dev_get_drvdata() to get to the cmos object
pointer and the driver data pointer is only populated in
cmos_do_probe().
This leads to a NULL pointer dereference in rtc_handler() on boot
if the RTC fixed event happens to be active at the init time.
To address this issue, change the initialization ordering of the
driver so that cmos_wake_setup() is always called after a successful
cmos_do_probe() call.
While at it, change cmos_pnp_probe() to call cmos_do_probe() after
the initial if () statement used for computing the IRQ argument to
be passed to cmos_do_probe() which is cleaner than calling it in
each branch of that if () (local variable "irq" can be of type int,
because it is passed to that function as an argument of type int).
Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check
ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number
of systems, because previously it only affected systems with
ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that
commit.
Fixes: 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0")
Fixes: a474aaedac99 ("rtc-cmos: move wake setup from ACPI glue into RTC driver")
Link: https://lore.kernel.org/linux-acpi/20221010141630.zfzi7mk7zvnmclzy@techsingularity.net/
Reported-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Mel Gorman <mgorman@techsingularity.net>
Link: https://lore.kernel.org/r/5629262.DvuYhMxLoT@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2022-10-13 02:07:01 +08:00
|
|
|
irq = 0;
|
2017-03-18 21:45:49 +08:00
|
|
|
#ifdef CONFIG_X86
|
2007-06-01 15:46:51 +08:00
|
|
|
/* Some machines contain a PNP entry for the RTC, but
|
|
|
|
* don't define the IRQ. It should always be safe to
|
2017-03-18 21:45:49 +08:00
|
|
|
* hardcode it on systems with a legacy PIC.
|
2007-06-01 15:46:51 +08:00
|
|
|
*/
|
2017-03-18 21:45:49 +08:00
|
|
|
if (nr_legacy_irqs())
|
2020-01-23 21:14:36 +08:00
|
|
|
irq = RTC_IRQ;
|
2017-03-18 21:45:49 +08:00
|
|
|
#endif
|
|
|
|
} else {
|
rtc: cmos: Fix event handler registration ordering issue
Because acpi_install_fixed_event_handler() enables the event
automatically on success, it is incorrect to call it before the
handler routine passed to it is ready to handle events.
Unfortunately, the rtc-cmos driver does exactly the incorrect thing
by calling cmos_wake_setup(), which passes rtc_handler() to
acpi_install_fixed_event_handler(), before cmos_do_probe(), because
rtc_handler() uses dev_get_drvdata() to get to the cmos object
pointer and the driver data pointer is only populated in
cmos_do_probe().
This leads to a NULL pointer dereference in rtc_handler() on boot
if the RTC fixed event happens to be active at the init time.
To address this issue, change the initialization ordering of the
driver so that cmos_wake_setup() is always called after a successful
cmos_do_probe() call.
While at it, change cmos_pnp_probe() to call cmos_do_probe() after
the initial if () statement used for computing the IRQ argument to
be passed to cmos_do_probe() which is cleaner than calling it in
each branch of that if () (local variable "irq" can be of type int,
because it is passed to that function as an argument of type int).
Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check
ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number
of systems, because previously it only affected systems with
ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that
commit.
Fixes: 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0")
Fixes: a474aaedac99 ("rtc-cmos: move wake setup from ACPI glue into RTC driver")
Link: https://lore.kernel.org/linux-acpi/20221010141630.zfzi7mk7zvnmclzy@techsingularity.net/
Reported-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Mel Gorman <mgorman@techsingularity.net>
Link: https://lore.kernel.org/r/5629262.DvuYhMxLoT@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2022-10-13 02:07:01 +08:00
|
|
|
irq = pnp_irq(pnp, 0);
|
2017-03-18 21:45:49 +08:00
|
|
|
}
|
rtc: cmos: Fix event handler registration ordering issue
Because acpi_install_fixed_event_handler() enables the event
automatically on success, it is incorrect to call it before the
handler routine passed to it is ready to handle events.
Unfortunately, the rtc-cmos driver does exactly the incorrect thing
by calling cmos_wake_setup(), which passes rtc_handler() to
acpi_install_fixed_event_handler(), before cmos_do_probe(), because
rtc_handler() uses dev_get_drvdata() to get to the cmos object
pointer and the driver data pointer is only populated in
cmos_do_probe().
This leads to a NULL pointer dereference in rtc_handler() on boot
if the RTC fixed event happens to be active at the init time.
To address this issue, change the initialization ordering of the
driver so that cmos_wake_setup() is always called after a successful
cmos_do_probe() call.
While at it, change cmos_pnp_probe() to call cmos_do_probe() after
the initial if () statement used for computing the IRQ argument to
be passed to cmos_do_probe() which is cleaner than calling it in
each branch of that if () (local variable "irq" can be of type int,
because it is passed to that function as an argument of type int).
Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check
ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number
of systems, because previously it only affected systems with
ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that
commit.
Fixes: 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0")
Fixes: a474aaedac99 ("rtc-cmos: move wake setup from ACPI glue into RTC driver")
Link: https://lore.kernel.org/linux-acpi/20221010141630.zfzi7mk7zvnmclzy@techsingularity.net/
Reported-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Mel Gorman <mgorman@techsingularity.net>
Link: https://lore.kernel.org/r/5629262.DvuYhMxLoT@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2022-10-13 02:07:01 +08:00
|
|
|
|
|
|
|
ret = cmos_do_probe(&pnp->dev, pnp_get_resource(pnp, IORESOURCE_IO, 0), irq);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2022-10-19 00:09:31 +08:00
|
|
|
rtc_wake_setup(&pnp->dev);
|
rtc: cmos: Fix event handler registration ordering issue
Because acpi_install_fixed_event_handler() enables the event
automatically on success, it is incorrect to call it before the
handler routine passed to it is ready to handle events.
Unfortunately, the rtc-cmos driver does exactly the incorrect thing
by calling cmos_wake_setup(), which passes rtc_handler() to
acpi_install_fixed_event_handler(), before cmos_do_probe(), because
rtc_handler() uses dev_get_drvdata() to get to the cmos object
pointer and the driver data pointer is only populated in
cmos_do_probe().
This leads to a NULL pointer dereference in rtc_handler() on boot
if the RTC fixed event happens to be active at the init time.
To address this issue, change the initialization ordering of the
driver so that cmos_wake_setup() is always called after a successful
cmos_do_probe() call.
While at it, change cmos_pnp_probe() to call cmos_do_probe() after
the initial if () statement used for computing the IRQ argument to
be passed to cmos_do_probe() which is cleaner than calling it in
each branch of that if () (local variable "irq" can be of type int,
because it is passed to that function as an argument of type int).
Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check
ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number
of systems, because previously it only affected systems with
ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that
commit.
Fixes: 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0")
Fixes: a474aaedac99 ("rtc-cmos: move wake setup from ACPI glue into RTC driver")
Link: https://lore.kernel.org/linux-acpi/20221010141630.zfzi7mk7zvnmclzy@techsingularity.net/
Reported-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Mel Gorman <mgorman@techsingularity.net>
Link: https://lore.kernel.org/r/5629262.DvuYhMxLoT@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2022-10-13 02:07:01 +08:00
|
|
|
|
|
|
|
return 0;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
}
|
|
|
|
|
2016-10-18 22:39:54 +08:00
|
|
|
static void cmos_pnp_remove(struct pnp_dev *pnp)
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
{
|
|
|
|
cmos_do_remove(&pnp->dev);
|
|
|
|
}
|
|
|
|
|
2010-01-09 06:43:11 +08:00
|
|
|
static void cmos_pnp_shutdown(struct pnp_dev *pnp)
|
2008-09-03 05:36:11 +08:00
|
|
|
{
|
drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-07 05:35:49 +08:00
|
|
|
struct device *dev = &pnp->dev;
|
|
|
|
struct cmos_rtc *cmos = dev_get_drvdata(dev);
|
|
|
|
|
rtc: cmos: Cancel alarm timer if alarm time is equal to now+1 seconds
Steps to reproduce the problem:
1) Enable RTC wake-up option in BIOS Setup
2) Issue one of these commands in the OS: "poweroff"
or "shutdown -h now"
3) System will shut down and then reboot automatically
Root-cause of the issue:
1) During the shutdown process, the hwclock utility is used
to save the system clock to hardware clock (RTC).
2) The hwclock utility invokes ioctl() with RTC_UIE_ON. The
kernel configures the RTC alarm for the periodic interrupt
(every 1 second).
3) The hwclock uitlity closes the /dev/rtc0 device, and the
kernel disables the RTC alarm irq (AIE bit of Register B)
via ioctl() with RTC_UIE_OFF. But, the configured alarm
time is the current_time + 1.
4) After the next 1 second is elapsed, the AF (alarm
interrupt flag) of Register C is set.
5) The S5 handler in BIOS is invoked to configure alarm
registers (enable AIE bit and configure alarm date/time).
But, BIOS does not clear the previous interrupt status
during alarm configuration. Therefore, "AF=AIE=1" causes
the rtc device to trigger an interrupt.
6) So, the machine reboots automatically right after shutdown.
This patch cancels the alarm timer if the following condictions are
met (suggested by Alexandre):
1) The configured alarm time is equal to current_time + 1
seconds.
2) The AIE timer is not in use.
The member 'alarm_expires' is introduced in struct cmos_rtc because
of the following reasons:
1) The configured alarm time can be retrieved from
cmos_read_alarm(), but we need to take the 'wrapped
timestamp' and 'time rollover' into consideration. The
function __rtc_read_alarm() eliminates the concerns. To
avoid the duplicated code in the lower level RTC driver,
invoking __rtc_read_alarm from the lower level RTC driver
is not encouraged. Moreover, the compilation error 'the
undefined __rtc_read_alarm" is observed if the lower level
RTC driver is compiled as a kernel module.
2) The uie_rtctimer.node.expires and aie_timer.node.expires can
be retrieved for the configured alarm time. But, the problem
is that either of them might configure the CMOS alarm time.
We cannot make sure UIE timer or AIE tiemr configured the
CMOS alarm time before. (uie_rtctimer or aie_timer is enabled
and then is disabled).
3) The patch introduces the member 'alarm_expires' to keep the
newly configured alarm time, so the above-mentioned concerns
can be eliminated.
The issue goes away after 20-time shutdown tests.
Signed-off-by: Adrian Huang <ahuang12@lenovo.com>
Tested-by: Egbert Eich <eich@suse.de>
Tested-by: Diego Ercolani <diego.ercolani@gmail.com>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2015-07-06 12:19:12 +08:00
|
|
|
if (system_state == SYSTEM_POWER_OFF) {
|
|
|
|
int retval = cmos_poweroff(dev);
|
|
|
|
|
|
|
|
if (cmos_aie_poweroff(dev) < 0 && !retval)
|
|
|
|
return;
|
|
|
|
}
|
2008-09-03 05:36:11 +08:00
|
|
|
|
drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-07 05:35:49 +08:00
|
|
|
cmos_do_shutdown(cmos->irq);
|
2008-09-03 05:36:11 +08:00
|
|
|
}
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
|
|
|
static const struct pnp_device_id rtc_ids[] = {
|
|
|
|
{ .id = "PNP0b00", },
|
|
|
|
{ .id = "PNP0b01", },
|
|
|
|
{ .id = "PNP0b02", },
|
|
|
|
{ },
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(pnp, rtc_ids);
|
|
|
|
|
|
|
|
static struct pnp_driver cmos_pnp_driver = {
|
2020-03-06 15:53:01 +08:00
|
|
|
.name = driver_name,
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
.id_table = rtc_ids,
|
|
|
|
.probe = cmos_pnp_probe,
|
2016-10-18 22:39:54 +08:00
|
|
|
.remove = cmos_pnp_remove,
|
2010-01-09 06:43:11 +08:00
|
|
|
.shutdown = cmos_pnp_shutdown,
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
|
|
|
/* flag ensures resume() gets called, and stops syslog spam */
|
|
|
|
.flags = PNP_DRIVER_RES_DO_NOT_CHANGE,
|
2013-09-12 05:23:11 +08:00
|
|
|
.driver = {
|
|
|
|
.pm = &cmos_pm_ops,
|
|
|
|
},
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
};
|
|
|
|
|
2008-06-13 06:21:54 +08:00
|
|
|
#endif /* CONFIG_PNP */
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
|
2011-02-23 04:07:46 +08:00
|
|
|
#ifdef CONFIG_OF
|
|
|
|
static const struct of_device_id of_cmos_match[] = {
|
|
|
|
{
|
|
|
|
.compatible = "motorola,mc146818",
|
|
|
|
},
|
|
|
|
{ },
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(of, of_cmos_match);
|
|
|
|
|
|
|
|
static __init void cmos_of_init(struct platform_device *pdev)
|
|
|
|
{
|
|
|
|
struct device_node *node = pdev->dev.of_node;
|
|
|
|
const __be32 *val;
|
|
|
|
|
|
|
|
if (!node)
|
|
|
|
return;
|
|
|
|
|
|
|
|
val = of_get_property(node, "ctrl-reg", NULL);
|
|
|
|
if (val)
|
|
|
|
CMOS_WRITE(be32_to_cpup(val), RTC_CONTROL);
|
|
|
|
|
|
|
|
val = of_get_property(node, "freq-reg", NULL);
|
|
|
|
if (val)
|
|
|
|
CMOS_WRITE(be32_to_cpup(val), RTC_FREQ_SELECT);
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline void cmos_of_init(struct platform_device *pdev) {}
|
|
|
|
#endif
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
/*----------------------------------------------------------------*/
|
|
|
|
|
2007-05-08 15:34:09 +08:00
|
|
|
/* Platform setup should have set up an RTC device, when PNP is
|
2007-04-02 14:49:47 +08:00
|
|
|
* unavailable ... this could happen even on (older) PCs.
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
static int __init cmos_platform_probe(struct platform_device *pdev)
|
|
|
|
{
|
drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-07 05:35:49 +08:00
|
|
|
struct resource *resource;
|
rtc: cmos: Fix event handler registration ordering issue
Because acpi_install_fixed_event_handler() enables the event
automatically on success, it is incorrect to call it before the
handler routine passed to it is ready to handle events.
Unfortunately, the rtc-cmos driver does exactly the incorrect thing
by calling cmos_wake_setup(), which passes rtc_handler() to
acpi_install_fixed_event_handler(), before cmos_do_probe(), because
rtc_handler() uses dev_get_drvdata() to get to the cmos object
pointer and the driver data pointer is only populated in
cmos_do_probe().
This leads to a NULL pointer dereference in rtc_handler() on boot
if the RTC fixed event happens to be active at the init time.
To address this issue, change the initialization ordering of the
driver so that cmos_wake_setup() is always called after a successful
cmos_do_probe() call.
While at it, change cmos_pnp_probe() to call cmos_do_probe() after
the initial if () statement used for computing the IRQ argument to
be passed to cmos_do_probe() which is cleaner than calling it in
each branch of that if () (local variable "irq" can be of type int,
because it is passed to that function as an argument of type int).
Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check
ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number
of systems, because previously it only affected systems with
ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that
commit.
Fixes: 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0")
Fixes: a474aaedac99 ("rtc-cmos: move wake setup from ACPI glue into RTC driver")
Link: https://lore.kernel.org/linux-acpi/20221010141630.zfzi7mk7zvnmclzy@techsingularity.net/
Reported-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Mel Gorman <mgorman@techsingularity.net>
Link: https://lore.kernel.org/r/5629262.DvuYhMxLoT@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2022-10-13 02:07:01 +08:00
|
|
|
int irq, ret;
|
drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-07 05:35:49 +08:00
|
|
|
|
2011-02-23 04:07:46 +08:00
|
|
|
cmos_of_init(pdev);
|
2022-10-19 00:09:31 +08:00
|
|
|
cmos_wake_setup(&pdev->dev);
|
drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-07 05:35:49 +08:00
|
|
|
|
|
|
|
if (RTC_IOMAPPED)
|
|
|
|
resource = platform_get_resource(pdev, IORESOURCE_IO, 0);
|
|
|
|
else
|
|
|
|
resource = platform_get_resource(pdev, IORESOURCE_MEM, 0);
|
|
|
|
irq = platform_get_irq(pdev, 0);
|
|
|
|
if (irq < 0)
|
|
|
|
irq = -1;
|
|
|
|
|
rtc: cmos: Fix event handler registration ordering issue
Because acpi_install_fixed_event_handler() enables the event
automatically on success, it is incorrect to call it before the
handler routine passed to it is ready to handle events.
Unfortunately, the rtc-cmos driver does exactly the incorrect thing
by calling cmos_wake_setup(), which passes rtc_handler() to
acpi_install_fixed_event_handler(), before cmos_do_probe(), because
rtc_handler() uses dev_get_drvdata() to get to the cmos object
pointer and the driver data pointer is only populated in
cmos_do_probe().
This leads to a NULL pointer dereference in rtc_handler() on boot
if the RTC fixed event happens to be active at the init time.
To address this issue, change the initialization ordering of the
driver so that cmos_wake_setup() is always called after a successful
cmos_do_probe() call.
While at it, change cmos_pnp_probe() to call cmos_do_probe() after
the initial if () statement used for computing the IRQ argument to
be passed to cmos_do_probe() which is cleaner than calling it in
each branch of that if () (local variable "irq" can be of type int,
because it is passed to that function as an argument of type int).
Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check
ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number
of systems, because previously it only affected systems with
ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that
commit.
Fixes: 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0")
Fixes: a474aaedac99 ("rtc-cmos: move wake setup from ACPI glue into RTC driver")
Link: https://lore.kernel.org/linux-acpi/20221010141630.zfzi7mk7zvnmclzy@techsingularity.net/
Reported-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Mel Gorman <mgorman@techsingularity.net>
Link: https://lore.kernel.org/r/5629262.DvuYhMxLoT@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2022-10-13 02:07:01 +08:00
|
|
|
ret = cmos_do_probe(&pdev->dev, resource, irq);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2022-10-19 00:09:31 +08:00
|
|
|
rtc_wake_setup(&pdev->dev);
|
rtc: cmos: Fix event handler registration ordering issue
Because acpi_install_fixed_event_handler() enables the event
automatically on success, it is incorrect to call it before the
handler routine passed to it is ready to handle events.
Unfortunately, the rtc-cmos driver does exactly the incorrect thing
by calling cmos_wake_setup(), which passes rtc_handler() to
acpi_install_fixed_event_handler(), before cmos_do_probe(), because
rtc_handler() uses dev_get_drvdata() to get to the cmos object
pointer and the driver data pointer is only populated in
cmos_do_probe().
This leads to a NULL pointer dereference in rtc_handler() on boot
if the RTC fixed event happens to be active at the init time.
To address this issue, change the initialization ordering of the
driver so that cmos_wake_setup() is always called after a successful
cmos_do_probe() call.
While at it, change cmos_pnp_probe() to call cmos_do_probe() after
the initial if () statement used for computing the IRQ argument to
be passed to cmos_do_probe() which is cleaner than calling it in
each branch of that if () (local variable "irq" can be of type int,
because it is passed to that function as an argument of type int).
Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check
ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number
of systems, because previously it only affected systems with
ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that
commit.
Fixes: 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0")
Fixes: a474aaedac99 ("rtc-cmos: move wake setup from ACPI glue into RTC driver")
Link: https://lore.kernel.org/linux-acpi/20221010141630.zfzi7mk7zvnmclzy@techsingularity.net/
Reported-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Mel Gorman <mgorman@techsingularity.net>
Link: https://lore.kernel.org/r/5629262.DvuYhMxLoT@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2022-10-13 02:07:01 +08:00
|
|
|
|
|
|
|
return 0;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
}
|
|
|
|
|
2016-10-18 22:39:54 +08:00
|
|
|
static int cmos_platform_remove(struct platform_device *pdev)
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
{
|
|
|
|
cmos_do_remove(&pdev->dev);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void cmos_platform_shutdown(struct platform_device *pdev)
|
|
|
|
{
|
drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-07 05:35:49 +08:00
|
|
|
struct device *dev = &pdev->dev;
|
|
|
|
struct cmos_rtc *cmos = dev_get_drvdata(dev);
|
|
|
|
|
rtc: cmos: Cancel alarm timer if alarm time is equal to now+1 seconds
Steps to reproduce the problem:
1) Enable RTC wake-up option in BIOS Setup
2) Issue one of these commands in the OS: "poweroff"
or "shutdown -h now"
3) System will shut down and then reboot automatically
Root-cause of the issue:
1) During the shutdown process, the hwclock utility is used
to save the system clock to hardware clock (RTC).
2) The hwclock utility invokes ioctl() with RTC_UIE_ON. The
kernel configures the RTC alarm for the periodic interrupt
(every 1 second).
3) The hwclock uitlity closes the /dev/rtc0 device, and the
kernel disables the RTC alarm irq (AIE bit of Register B)
via ioctl() with RTC_UIE_OFF. But, the configured alarm
time is the current_time + 1.
4) After the next 1 second is elapsed, the AF (alarm
interrupt flag) of Register C is set.
5) The S5 handler in BIOS is invoked to configure alarm
registers (enable AIE bit and configure alarm date/time).
But, BIOS does not clear the previous interrupt status
during alarm configuration. Therefore, "AF=AIE=1" causes
the rtc device to trigger an interrupt.
6) So, the machine reboots automatically right after shutdown.
This patch cancels the alarm timer if the following condictions are
met (suggested by Alexandre):
1) The configured alarm time is equal to current_time + 1
seconds.
2) The AIE timer is not in use.
The member 'alarm_expires' is introduced in struct cmos_rtc because
of the following reasons:
1) The configured alarm time can be retrieved from
cmos_read_alarm(), but we need to take the 'wrapped
timestamp' and 'time rollover' into consideration. The
function __rtc_read_alarm() eliminates the concerns. To
avoid the duplicated code in the lower level RTC driver,
invoking __rtc_read_alarm from the lower level RTC driver
is not encouraged. Moreover, the compilation error 'the
undefined __rtc_read_alarm" is observed if the lower level
RTC driver is compiled as a kernel module.
2) The uie_rtctimer.node.expires and aie_timer.node.expires can
be retrieved for the configured alarm time. But, the problem
is that either of them might configure the CMOS alarm time.
We cannot make sure UIE timer or AIE tiemr configured the
CMOS alarm time before. (uie_rtctimer or aie_timer is enabled
and then is disabled).
3) The patch introduces the member 'alarm_expires' to keep the
newly configured alarm time, so the above-mentioned concerns
can be eliminated.
The issue goes away after 20-time shutdown tests.
Signed-off-by: Adrian Huang <ahuang12@lenovo.com>
Tested-by: Egbert Eich <eich@suse.de>
Tested-by: Diego Ercolani <diego.ercolani@gmail.com>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2015-07-06 12:19:12 +08:00
|
|
|
if (system_state == SYSTEM_POWER_OFF) {
|
|
|
|
int retval = cmos_poweroff(dev);
|
|
|
|
|
|
|
|
if (cmos_aie_poweroff(dev) < 0 && !retval)
|
|
|
|
return;
|
|
|
|
}
|
2008-09-03 05:36:11 +08:00
|
|
|
|
drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-07 05:35:49 +08:00
|
|
|
cmos_do_shutdown(cmos->irq);
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
}
|
|
|
|
|
2008-04-11 12:29:25 +08:00
|
|
|
/* work with hotplug and coldplug */
|
|
|
|
MODULE_ALIAS("platform:rtc_cmos");
|
|
|
|
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
static struct platform_driver cmos_platform_driver = {
|
2016-10-18 22:39:54 +08:00
|
|
|
.remove = cmos_platform_remove,
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
.shutdown = cmos_platform_shutdown,
|
|
|
|
.driver = {
|
2014-01-24 07:55:11 +08:00
|
|
|
.name = driver_name,
|
2011-01-13 09:00:07 +08:00
|
|
|
.pm = &cmos_pm_ops,
|
2013-02-22 08:44:28 +08:00
|
|
|
.of_match_table = of_match_ptr(of_cmos_match),
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2009-07-30 06:02:13 +08:00
|
|
|
#ifdef CONFIG_PNP
|
|
|
|
static bool pnp_driver_registered;
|
|
|
|
#endif
|
|
|
|
static bool platform_driver_registered;
|
|
|
|
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
static int __init cmos_init(void)
|
|
|
|
{
|
2008-10-15 07:01:59 +08:00
|
|
|
int retval = 0;
|
|
|
|
|
2008-06-13 06:21:54 +08:00
|
|
|
#ifdef CONFIG_PNP
|
2009-07-30 06:02:13 +08:00
|
|
|
retval = pnp_register_driver(&cmos_pnp_driver);
|
|
|
|
if (retval == 0)
|
|
|
|
pnp_driver_registered = true;
|
2008-10-15 07:01:59 +08:00
|
|
|
#endif
|
|
|
|
|
2009-07-30 06:02:13 +08:00
|
|
|
if (!cmos_rtc.dev) {
|
2008-10-15 07:01:59 +08:00
|
|
|
retval = platform_driver_probe(&cmos_platform_driver,
|
|
|
|
cmos_platform_probe);
|
2009-07-30 06:02:13 +08:00
|
|
|
if (retval == 0)
|
|
|
|
platform_driver_registered = true;
|
|
|
|
}
|
2008-10-15 07:01:59 +08:00
|
|
|
|
|
|
|
if (retval == 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
#ifdef CONFIG_PNP
|
2009-07-30 06:02:13 +08:00
|
|
|
if (pnp_driver_registered)
|
|
|
|
pnp_unregister_driver(&cmos_pnp_driver);
|
2008-10-15 07:01:59 +08:00
|
|
|
#endif
|
|
|
|
return retval;
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
}
|
|
|
|
module_init(cmos_init);
|
|
|
|
|
|
|
|
static void __exit cmos_exit(void)
|
|
|
|
{
|
2008-06-13 06:21:54 +08:00
|
|
|
#ifdef CONFIG_PNP
|
2009-07-30 06:02:13 +08:00
|
|
|
if (pnp_driver_registered)
|
|
|
|
pnp_unregister_driver(&cmos_pnp_driver);
|
2008-10-15 07:01:59 +08:00
|
|
|
#endif
|
2009-07-30 06:02:13 +08:00
|
|
|
if (platform_driver_registered)
|
|
|
|
platform_driver_unregister(&cmos_platform_driver);
|
[PATCH] RTC framework driver for CMOS RTCs
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-10 17:46:02 +08:00
|
|
|
}
|
|
|
|
module_exit(cmos_exit);
|
|
|
|
|
|
|
|
|
|
|
|
MODULE_AUTHOR("David Brownell");
|
|
|
|
MODULE_DESCRIPTION("Driver for PC-style 'CMOS' RTCs");
|
|
|
|
MODULE_LICENSE("GPL");
|