Commit ea04683f592e6200b52e191b7e2842aedcfd88b6

Authored by John Stultz
1 parent 416f0e8056

RTC: Fix up rtc.txt documentation to reflect changes to generic rtc layer

Now that the genric RTC layer handles much of the RTC functionality,
the rtc.txt documentation needs to be updated to remove outdated information.

CC: Thomas Gleixner <tglx@linutronix.de>
CC: Alessandro Zummo <a.zummo@towertech.it>
CC: Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br>
CC: rtc-linux@googlegroups.com
Signed-off-by: John Stultz <john.stultz@linaro.org>

Showing 1 changed file with 10 additions and 19 deletions Side-by-side Diff

Documentation/rtc.txt
... ... @@ -178,38 +178,29 @@
178 178 setting the longer alarm time and enabling its IRQ using a single
179 179 request (using the same model as EFI firmware).
180 180  
181   - * RTC_UIE_ON, RTC_UIE_OFF ... if the RTC offers IRQs, it probably
182   - also offers update IRQs whenever the "seconds" counter changes.
183   - If needed, the RTC framework can emulate this mechanism.
  181 + * RTC_UIE_ON, RTC_UIE_OFF ... if the RTC offers IRQs, the RTC framework
  182 + will emulate this mechanism.
184 183  
185   - * RTC_PIE_ON, RTC_PIE_OFF, RTC_IRQP_SET, RTC_IRQP_READ ... another
186   - feature often accessible with an IRQ line is a periodic IRQ, issued
187   - at settable frequencies (usually 2^N Hz).
  184 + * RTC_PIE_ON, RTC_PIE_OFF, RTC_IRQP_SET, RTC_IRQP_READ ... these icotls
  185 + are emulated via a kernel hrtimer.
188 186  
189 187 In many cases, the RTC alarm can be a system wake event, used to force
190 188 Linux out of a low power sleep state (or hibernation) back to a fully
191 189 operational state. For example, a system could enter a deep power saving
192 190 state until it's time to execute some scheduled tasks.
193 191  
194   -Note that many of these ioctls need not actually be implemented by your
195   -driver. The common rtc-dev interface handles many of these nicely if your
196   -driver returns ENOIOCTLCMD. Some common examples:
  192 +Note that many of these ioctls are handled by the common rtc-dev interface.
  193 +Some common examples:
197 194  
198 195 * RTC_RD_TIME, RTC_SET_TIME: the read_time/set_time functions will be
199 196 called with appropriate values.
200 197  
201   - * RTC_ALM_SET, RTC_ALM_READ, RTC_WKALM_SET, RTC_WKALM_RD: the
202   - set_alarm/read_alarm functions will be called.
  198 + * RTC_ALM_SET, RTC_ALM_READ, RTC_WKALM_SET, RTC_WKALM_RD: gets or sets
  199 + the alarm rtc_timer. May call the set_alarm driver function.
203 200  
204   - * RTC_IRQP_SET, RTC_IRQP_READ: the irq_set_freq function will be called
205   - to set the frequency while the framework will handle the read for you
206   - since the frequency is stored in the irq_freq member of the rtc_device
207   - structure. Your driver needs to initialize the irq_freq member during
208   - init. Make sure you check the requested frequency is in range of your
209   - hardware in the irq_set_freq function. If it isn't, return -EINVAL. If
210   - you cannot actually change the frequency, do not define irq_set_freq.
  201 + * RTC_IRQP_SET, RTC_IRQP_READ: These are emulated by the generic code.
211 202  
212   - * RTC_PIE_ON, RTC_PIE_OFF: the irq_set_state function will be called.
  203 + * RTC_PIE_ON, RTC_PIE_OFF: These are also emulated by the generic code.
213 204  
214 205 If all else fails, check out the rtc-test.c driver!
215 206