|
@@ -178,38 +178,29 @@ RTC class framework, but can't be supported by the older driver.
|
|
setting the longer alarm time and enabling its IRQ using a single
|
|
setting the longer alarm time and enabling its IRQ using a single
|
|
request (using the same model as EFI firmware).
|
|
request (using the same model as EFI firmware).
|
|
|
|
|
|
- * RTC_UIE_ON, RTC_UIE_OFF ... if the RTC offers IRQs, it probably
|
|
|
|
- also offers update IRQs whenever the "seconds" counter changes.
|
|
|
|
- If needed, the RTC framework can emulate this mechanism.
|
|
|
|
|
|
+ * 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 ... another
|
|
|
|
- feature often accessible with an IRQ line is a periodic IRQ, issued
|
|
|
|
- at settable frequencies (usually 2^N Hz).
|
|
|
|
|
|
+ * 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
|
|
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
|
|
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
|
|
operational state. For example, a system could enter a deep power saving
|
|
state until it's time to execute some scheduled tasks.
|
|
state until it's time to execute some scheduled tasks.
|
|
|
|
|
|
-Note that many of these ioctls need not actually be implemented by your
|
|
|
|
-driver. The common rtc-dev interface handles many of these nicely if your
|
|
|
|
-driver returns ENOIOCTLCMD. Some common examples:
|
|
|
|
|
|
+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
|
|
* RTC_RD_TIME, RTC_SET_TIME: the read_time/set_time functions will be
|
|
called with appropriate values.
|
|
called with appropriate values.
|
|
|
|
|
|
- * RTC_ALM_SET, RTC_ALM_READ, RTC_WKALM_SET, RTC_WKALM_RD: the
|
|
|
|
- set_alarm/read_alarm functions will be called.
|
|
|
|
|
|
+ * 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: the irq_set_freq function will be called
|
|
|
|
- to set the frequency while the framework will handle the read for you
|
|
|
|
- since the frequency is stored in the irq_freq member of the rtc_device
|
|
|
|
- structure. Your driver needs to initialize the irq_freq member during
|
|
|
|
- init. Make sure you check the requested frequency is in range of your
|
|
|
|
- hardware in the irq_set_freq function. If it isn't, return -EINVAL. If
|
|
|
|
- you cannot actually change the frequency, do not define irq_set_freq.
|
|
|
|
|
|
+ * RTC_IRQP_SET, RTC_IRQP_READ: These are emulated by the generic code.
|
|
|
|
|
|
- * RTC_PIE_ON, RTC_PIE_OFF: the irq_set_state function will be called.
|
|
|
|
|
|
+ * RTC_PIE_ON, RTC_PIE_OFF: These are also emulated by the generic code.
|
|
|
|
|
|
If all else fails, check out the rtc-test.c driver!
|
|
If all else fails, check out the rtc-test.c driver!
|
|
|
|
|