the system clock from the discrete RTC, but use the integrated one for all
other tasks, because of its greater functionality.
-SYSFS interface
----------------
-
-The sysfs interface under /sys/class/rtc/rtcN provides access to various
-rtc attributes without requiring the use of ioctls. All dates and times
-are in the RTC's timezone, rather than in system time.
-
-================ ==============================================================
-date RTC-provided date
-hctosys 1 if the RTC provided the system time at boot via the
- CONFIG_RTC_HCTOSYS kernel option, 0 otherwise
-max_user_freq The maximum interrupt rate an unprivileged user may request
- from this RTC.
-name The name of the RTC corresponding to this sysfs directory
-since_epoch The number of seconds since the epoch according to the RTC
-time RTC-provided time
-wakealarm The time at which the clock will generate a system wakeup
- event. This is a one shot wakeup event, so must be reset
- after wake if a daily wakeup is required. Format is seconds
- since the epoch by default, or if there's a leading +, seconds
- in the future, or if there is a leading +=, seconds ahead of
- the current alarm.
-offset The amount which the rtc clock has been adjusted in firmware.
- Visible only if the driver supports clock offset adjustment.
- The unit is parts per billion, i.e. The number of clock ticks
- which are added to or removed from the rtc's base clock per
- billion ticks. A positive value makes a day pass more slowly,
- longer, and a negative value makes a day pass more quickly.
-*/nvmem The non volatile storage exported as a raw file, as described
- in Documentation/nvmem/nvmem.txt
-================ ==============================================================
-
-IOCTL interface
----------------
-
-The ioctl() calls supported by /dev/rtc are also supported by the RTC class
-framework. However, because the chips and systems are not standardized,
-some PC/AT functionality might not be provided. And in the same way, some
-newer features -- including those enabled by ACPI -- are exposed by the
-RTC class framework, but can't be supported by the older driver.
-
- * RTC_RD_TIME, RTC_SET_TIME ... every RTC supports at least reading
- time, returning the result as a Gregorian calendar date and 24 hour
- wall clock time. To be most useful, this time may also be updated.
-
- * RTC_AIE_ON, RTC_AIE_OFF, RTC_ALM_SET, RTC_ALM_READ ... when the RTC
- is connected to an IRQ line, it can often issue an alarm IRQ up to
- 24 hours in the future. (Use RTC_WKALM_* by preference.)
-
- * RTC_WKALM_SET, RTC_WKALM_RD ... RTCs that can issue alarms beyond
- the next 24 hours use a slightly more powerful API, which supports
- setting the longer alarm time and enabling its IRQ using a single
- request (using the same model as EFI firmware).
-
- * RTC_UIE_ON, RTC_UIE_OFF ... if the RTC offers IRQs, the RTC framework
- will emulate this mechanism.
-
- * RTC_PIE_ON, RTC_PIE_OFF, RTC_IRQP_SET, RTC_IRQP_READ ... these icotls
- are emulated via a kernel hrtimer.
-
-In many cases, the RTC alarm can be a system wake event, used to force
-Linux out of a low power sleep state (or hibernation) back to a fully
-operational state. For example, a system could enter a deep power saving
-state until it's time to execute some scheduled tasks.
-
-Note that many of these ioctls are handled by the common rtc-dev interface.
-Some common examples:
-
- * RTC_RD_TIME, RTC_SET_TIME: the read_time/set_time functions will be
- called with appropriate values.
-
- * RTC_ALM_SET, RTC_ALM_READ, RTC_WKALM_SET, RTC_WKALM_RD: gets or sets
- the alarm rtc_timer. May call the set_alarm driver function.
-
- * RTC_IRQP_SET, RTC_IRQP_READ: These are emulated by the generic code.
-
- * RTC_PIE_ON, RTC_PIE_OFF: These are also emulated by the generic code.
-
-If all else fails, check out the tools/testing/selftests/timers/rtctest.c test!
+Check out tools/testing/selftests/timers/rtctest.c for an example usage of the
+ioctl interface.
git.samba.org / sfrench / cifs-2.6.git / blobdiff