Comments

Hi!
hwclock calls the RTC_UIE_ON ioctl to wait for a timer tick.
If RTC_UIE_ON was successful it opens /dev/rtcX and waits up to 5 seconds using select()
for a tick.
Some RTC drivers have no support for RTC_UIE_ON and ioctl just returns -EINVAL.
Drivers indicated this by setting rtc_class_ops->update_irq_enable to NULL.
In this case hwclock waits in a busy loop for the next timer tick.
These two commits changed this behavior:
6610e08 (RTC: Rework RTC code to use timerqueue for events)
51ba60c (RTC: Cleanup rtc_class_ops->update_irq_enable())
rtc_class_ops->update_irq_enable was removed and rtc_update_irq_enable()
is now using rtc_class_ops->set_alarm instead of rtc_class_ops->update_irq_enable.
Some RTC devices (like mpc515x) don't support intervals smaller than one
minute.
rtc-mpc5121.c deals with this by rounding up to one minute.
But now after commit 6610e08 RTC_UIE_ON will no longer return -EINVAL and
the next tick comes somewhen within the next 60 seconds, because the driver rounded up...
hwclock's select() is not happy about this and timeouts in most cases.
The attached patch fixes the issue for mpc512x.
set_alarm returns now -EINVAL if the requested interval is less than one minute.
But I'm sure there are more RTC drivers and devices which are unable to handle
such short intervals.
Their RTC_UIE_ON behavior is currently undefined.
Thanks,
//richard
----