{ "content": [ { "type": "text", "text": "# rtc(4) (man)\n\n**Summary:** rtc - real-time clock\n\n**Synopsis:** #include \nint ioctl(fd, RTCrequest, param);\n\n## See Also\n\n- date(1)\n- adjtimex(2)\n- gettimeofday(2)\n- settimeofday(2)\n- stime(2)\n- time(2)\n- gmtime(3)\n- time(7)\n- hwclock(8)\n\n## Section Outline\n\n- **NAME** (2 lines)\n- **SYNOPSIS** (4 lines)\n- **DESCRIPTION** (14 lines) — 3 subsections\n - RTC vs system clock (14 lines)\n - RTC functionality (25 lines)\n - ioctl(2) interface (85 lines)\n- **FILES** (6 lines)\n- **NOTES** (19 lines)\n- **SEE ALSO** (5 lines)\n- **COLOPHON** (7 lines)\n\n## Full Content\n\n### NAME\n\nrtc - real-time clock\n\n### SYNOPSIS\n\n#include \n\nint ioctl(fd, RTCrequest, param);\n\n### DESCRIPTION\n\nThis is the interface to drivers for real-time clocks (RTCs).\n\nMost computers have one or more hardware clocks which record the current \"wall clock\" time.\nThese are called \"Real Time Clocks\" (RTCs). One of these usually has battery backup power so\nthat it tracks the time even while the computer is turned off. RTCs often provide alarms and\nother interrupts.\n\nAll i386 PCs, and ACPI-based systems, have an RTC that is compatible with the Motorola\nMC146818 chip on the original PC/AT. Today such an RTC is usually integrated into the main‐\nboard's chipset (south bridge), and uses a replaceable coin-sized backup battery.\n\nNon-PC systems, such as embedded systems built around system-on-chip processors, use other\nimplementations. They usually won't offer the same functionality as the RTC from a PC/AT.\n\n#### RTC vs system clock\n\nRTCs should not be confused with the system clock, which is a software clock maintained by\nthe kernel and used to implement gettimeofday(2) and time(2), as well as setting timestamps\non files, and so on. The system clock reports seconds and microseconds since a start point,\ndefined to be the POSIX Epoch: 1970-01-01 00:00:00 +0000 (UTC). (One common implementation\ncounts timer interrupts, once per \"jiffy\", at a frequency of 100, 250, or 1000 Hz.) That is,\nit is supposed to report wall clock time, which RTCs also do.\n\nA key difference between an RTC and the system clock is that RTCs run even when the system is\nin a low power state (including \"off\"), and the system clock can't. Until it is initialized,\nthe system clock can only report time since system boot ... not since the POSIX Epoch. So at\nboot time, and after resuming from a system low power state, the system clock will often be\nset to the current wall clock time using an RTC. Systems without an RTC need to set the sys‐\ntem clock using another clock, maybe across the network or by entering that data manually.\n\n#### RTC functionality\n\nRTCs can be read and written with hwclock(8), or directly with the ioctl(2) requests listed\nbelow.\n\nBesides tracking the date and time, many RTCs can also generate interrupts\n\n* on every clock update (i.e., once per second);\n\n* at periodic intervals with a frequency that can be set to any power-of-2 multiple in the\nrange 2 Hz to 8192 Hz;\n\n* on reaching a previously specified alarm time.\n\nEach of those interrupt sources can be enabled or disabled separately. On many systems, the\nalarm interrupt can be configured as a system wakeup event, which can resume the system from\na low power state such as Suspend-to-RAM (STR, called S3 in ACPI systems), Hibernation\n(called S4 in ACPI systems), or even \"off\" (called S5 in ACPI systems). On some systems, the\nbattery backed RTC can't issue interrupts, but another one can.\n\nThe /dev/rtc (or /dev/rtc0, /dev/rtc1, etc.) device can be opened only once (until it is\nclosed) and it is read-only. On read(2) and select(2) the calling process is blocked until\nthe next interrupt from that RTC is received. Following the interrupt, the process can read\na long integer, of which the least significant byte contains a bit mask encoding the types of\ninterrupt that occurred, while the remaining 3 bytes contain the number of interrupts since\nthe last read(2).\n\n#### ioctl(2) interface\n\nThe following ioctl(2) requests are defined on file descriptors connected to RTC devices:\n\nRTCRDTIME\nReturns this RTC's time in the following structure:\n\nstruct rtctime {\nint tmsec;\nint tmmin;\nint tmhour;\nint tmmday;\nint tmmon;\nint tmyear;\nint tmwday; /* unused */\nint tmyday; /* unused */\nint tmisdst; /* unused */\n};\n\nThe fields in this structure have the same meaning and ranges as for the tm structure\ndescribed in gmtime(3). A pointer to this structure should be passed as the third\nioctl(2) argument.\n\nRTCSETTIME\nSets this RTC's time to the time specified by the rtctime structure pointed to by the\nthird ioctl(2) argument. To set the RTC's time the process must be privileged (i.e.,\nhave the CAPSYSTIME capability).\n\nRTCALMREAD, RTCALMSET\nRead and set the alarm time, for RTCs that support alarms. The alarm interrupt must\nbe separately enabled or disabled using the RTCAIEON, RTCAIEOFF requests. The\nthird ioctl(2) argument is a pointer to an rtctime structure. Only the tmsec,\ntmmin, and tmhour fields of this structure are used.\n\nRTCIRQPREAD, RTCIRQPSET\nRead and set the frequency for periodic interrupts, for RTCs that support periodic in‐\nterrupts. The periodic interrupt must be separately enabled or disabled using the\nRTCPIEON, RTCPIEOFF requests. The third ioctl(2) argument is an unsigned long *\nor an unsigned long, respectively. The value is the frequency in interrupts per sec‐\nond. The set of allowable frequencies is the multiples of two in the range 2 to 8192.\nOnly a privileged process (i.e., one having the CAPSYSRESOURCE capability) can set\nfrequencies above the value specified in /proc/sys/dev/rtc/max-user-freq. (This file\ncontains the value 64 by default.)\n\nRTCAIEON, RTCAIEOFF\nEnable or disable the alarm interrupt, for RTCs that support alarms. The third\nioctl(2) argument is ignored.\n\nRTCUIEON, RTCUIEOFF\nEnable or disable the interrupt on every clock update, for RTCs that support this\nonce-per-second interrupt. The third ioctl(2) argument is ignored.\n\nRTCPIEON, RTCPIEOFF\nEnable or disable the periodic interrupt, for RTCs that support these periodic inter‐\nrupts. The third ioctl(2) argument is ignored. Only a privileged process (i.e., one\nhaving the CAPSYSRESOURCE capability) can enable the periodic interrupt if the fre‐\nquency is currently set above the value specified in /proc/sys/dev/rtc/max-user-freq.\n\nRTCEPOCHREAD, RTCEPOCHSET\nMany RTCs encode the year in an 8-bit register which is either interpreted as an 8-bit\nbinary number or as a BCD number. In both cases, the number is interpreted relative\nto this RTC's Epoch. The RTC's Epoch is initialized to 1900 on most systems but on\nAlpha and MIPS it might also be initialized to 1952, 1980, or 2000, depending on the\nvalue of an RTC register for the year. With some RTCs, these operations can be used\nto read or to set the RTC's Epoch, respectively. The third ioctl(2) argument is an\nunsigned long * or an unsigned long, respectively, and the value returned (or as‐\nsigned) is the Epoch. To set the RTC's Epoch the process must be privileged (i.e.,\nhave the CAPSYSTIME capability).\n\nRTCWKALMRD, RTCWKALMSET\nSome RTCs support a more powerful alarm interface, using these ioctls to read or write\nthe RTC's alarm time (respectively) with this structure:\n\nstruct rtcwkalrm {\nunsigned char enabled;\nunsigned char pending;\nstruct rtctime time;\n};\n\nThe enabled flag is used to enable or disable the alarm interrupt, or to read its cur‐\nrent status; when using these calls, RTCAIEON and RTCAIEOFF are not used. The\npending flag is used by RTCWKALMRD to report a pending interrupt (so it's mostly\nuseless on Linux, except when talking to the RTC managed by EFI firmware). The time\nfield is as used with RTCALMREAD and RTCALMSET except that the tmmday, tmmon,\nand tmyear fields are also valid. A pointer to this structure should be passed as\nthe third ioctl(2) argument.\n\n### FILES\n\n/dev/rtc, /dev/rtc0, /dev/rtc1, etc.\nRTC special character device files.\n\n/proc/driver/rtc\nstatus of the (first) RTC.\n\n### NOTES\n\nWhen the kernel's system time is synchronized with an external reference using adjtimex(2) it\nwill update a designated RTC periodically every 11 minutes. To do so, the kernel has to\nbriefly turn off periodic interrupts; this might affect programs using that RTC.\n\nAn RTC's Epoch has nothing to do with the POSIX Epoch which is used only for the system\nclock.\n\nIf the year according to the RTC's Epoch and the year register is less than 1970 it is as‐\nsumed to be 100 years later, that is, between 2000 and 2069.\n\nSome RTCs support \"wildcard\" values in alarm fields, to support scenarios like periodic\nalarms at fifteen minutes after every hour, or on the first day of each month. Such usage is\nnonportable; portable user-space code expects only a single alarm interrupt, and will either\ndisable or reinitialize the alarm after receiving it.\n\nSome RTCs support periodic interrupts with periods that are multiples of a second rather than\nfractions of a second; multiple alarms; programmable output clock signals; nonvolatile mem‐\nory; and other hardware capabilities that are not currently exposed by this API.\n\n### SEE ALSO\n\ndate(1), adjtimex(2), gettimeofday(2), settimeofday(2), stime(2), time(2), gmtime(3),\ntime(7), hwclock(8)\n\nDocumentation/rtc.txt in the Linux kernel source tree\n\n### COLOPHON\n\nThis page is part of release 5.10 of the Linux man-pages project. A description of the\nproject, information about reporting bugs, and the latest version of this page, can be found\nat https://www.kernel.org/doc/man-pages/.\n\n\n\nLinux 2017-09-15 RTC(4)\n\n" } ], "structuredContent": { "command": "rtc", "section": "4", "mode": "man", "summary": "rtc - real-time clock", "synopsis": "#include \nint ioctl(fd, RTCrequest, param);", "flags": [], "examples": [], "see_also": [ { "name": "date", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/date/1/json" }, { "name": "adjtimex", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/adjtimex/2/json" }, { "name": "gettimeofday", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/gettimeofday/2/json" }, { "name": "settimeofday", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/settimeofday/2/json" }, { "name": "stime", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/stime/2/json" }, { "name": "time", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/time/2/json" }, { "name": "gmtime", "section": "3", "url": "https://www.chedong.com/phpMan.php/man/gmtime/3/json" }, { "name": "time", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/time/7/json" }, { "name": "hwclock", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/hwclock/8/json" } ], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "SYNOPSIS", "lines": 4, "subsections": [] }, { "name": "DESCRIPTION", "lines": 14, "subsections": [ { "name": "RTC vs system clock", "lines": 14 }, { "name": "RTC functionality", "lines": 25 }, { "name": "ioctl(2) interface", "lines": 85 } ] }, { "name": "FILES", "lines": 6, "subsections": [] }, { "name": "NOTES", "lines": 19, "subsections": [] }, { "name": "SEE ALSO", "lines": 5, "subsections": [] }, { "name": "COLOPHON", "lines": 7, "subsections": [] } ] } }