aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/rtc/Kconfig
diff options
context:
space:
mode:
authorDavid Brownell <david-b@pacbell.net>2007-05-08 03:33:42 -0400
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-05-08 14:15:18 -0400
commit7ca1d488ffe4817adaba61cc05b972782f7d3f91 (patch)
tree97fee4d2ddbc5be5265d99f5825e902f7a9262c1 /drivers/rtc/Kconfig
parentcd9662094edf4173e87f0452e57e4eacc228f8ff (diff)
rtc: suspend()/resume() restores system clock
RTC class suspend/resume support, re-initializing the system clock on resume from the clock used to initialize it at boot time. - The reinit-on-resume is hooked to the existing RTC_HCTOSYS config option, on the grounds that a clock good enough for init must also be good enough for re-init. - Inlining a version of the code used by ARM, to save and restore the delta between a selected RTC and the current system wall-clock time. - Removes calls to that ARM code from AT91, OMAP1, and S3C RTCs. This means that systems using those RTCs across suspend/resume will likely want to change their kernel configs to enable RTC_HCTOSYS. If HCTOSYS isn't using a second RTC (with battery?), this changes the system's initial date from Jan 1970 to the epoch this hardware uses: 1998 for AT91, 2000 for OMAP1 (assuming no split power mode), etc. This goes on top of the patch series removing "struct class_device" usage from the RTC framework. That's all needed for class suspend()/resume(). Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-By: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/rtc/Kconfig')
-rw-r--r--drivers/rtc/Kconfig24
1 files changed, 17 insertions, 7 deletions
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index ec33ee87735e..a53ef4d670cc 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -21,21 +21,31 @@ config RTC_CLASS
21 will be called rtc-class. 21 will be called rtc-class.
22 22
23config RTC_HCTOSYS 23config RTC_HCTOSYS
24 bool "Set system time from RTC on startup" 24 bool "Set system time from RTC on startup and resume"
25 depends on RTC_CLASS = y 25 depends on RTC_CLASS = y
26 default y 26 default y
27 help 27 help
28 If you say yes here, the system time will be set using 28 If you say yes here, the system time (wall clock) will be set using
29 the value read from the specified RTC device. This is useful 29 the value read from a specified RTC device. This is useful to avoid
30 in order to avoid unnecessary fsck runs. 30 unnecessary fsck runs at boot time, and to network better.
31 31
32config RTC_HCTOSYS_DEVICE 32config RTC_HCTOSYS_DEVICE
33 string "The RTC to read the time from" 33 string "RTC used to set the system time"
34 depends on RTC_HCTOSYS = y 34 depends on RTC_HCTOSYS = y
35 default "rtc0" 35 default "rtc0"
36 help 36 help
37 The RTC device that will be used as the source for 37 The RTC device that will be used to (re)initialize the system
38 the system time, usually rtc0. 38 clock, usually rtc0. Initialization is done when the system
39 starts up, and when it resumes from a low power state.
40
41 This clock should be battery-backed, so that it reads the correct
42 time when the system boots from a power-off state. Otherwise, your
43 system will need an external clock source (like an NTP server).
44
45 If the clock you specify here is not battery backed, it may still
46 be useful to reinitialize system time when resuming from system
47 sleep states. Do not specify an RTC here unless it stays powered
48 during all this system's supported sleep states.
39 49
40config RTC_DEBUG 50config RTC_DEBUG
41 bool "RTC debug support" 51 bool "RTC debug support"