Re: [rtc-linux] [PATCH 04/10] RTC: Cleanup rtc_class_ops->read_alarm()

[John Stultz <john.stultz@linaro.org>]

On Tue, 2011-02-22 at 02:34 +0000, Mark Brown wrote:
> On Mon, Feb 21, 2011 at 03:55:32PM -0800, John Stultz wrote:
> > With the generic rtc code managing the now virtualized alarm timer,
> > no one actually calls rtc_clas_ops->read_alarm().
> 
> > We do check that it exists in rtc_read_alarm(), but that is only
> > to verify that the hardware supports irqs. The same test can
> > be done by checking set_alarm instead.
> 
> > This patch changes the the read_alarm check to set_alarm, and then
> > removes the read_alarm method and its implementations in the rt
> > drivers.
> 
> Can you go into more detail on the rationale behind this virtualised
> functionality and how it works?  I'd really expect the RTC alarm to be
> preserved over system reboots (on some systems it can be used to
> initiate a boot) and that would mean that we need to go to the hardware
> for at least the initial configuration.

So with respect to the rationale:

The difference with the new code (already in for 2.6.38), is that when
alarms are set via the userland interface, instead of directly
manipulating the hardware, it creates a rtc_timer event that is managed
by the kernel.

The kernel then looks at the list of rtc_timers and sets the RTC for
soonest rtc_timer. When the alarm occurs (possibly waking up the
system), the kernel notifies the waiting userland app and then looks at
the timer list to see if there are any more events to program into the
hardware.

This allows us in the future to multiplex events onto the RTC hardware
from different sources without breaking compatibility.

Right now, if two applications want to set a wake alarm on the RTC ,
they have to coordinate their access to the rtc device (or the machine
has to have multiple RTC devices).

Soon, with my posix alarm timers work, those two applications would be
able to set standard posix timers against CLOCK_REALTIME_ALARM, and the
kernel will manage the RTC hardware to wake the system up for both
application's alarms. No coordination needed.


Now, to your point about persistence across reboots:

It is an interesting point to consider. 

So currently, if the hardware supports it, then the behavior should
remain the same: As long as no application sets a new alarm, the
previous alarm should persist in the RTC hardware.

However, an application's ability to notice that such an alarm is set,
is currently limited.  So your point about reading the hardware to
initialize the state is quite valid, and shows a good reason to preserve
the read_alarm() method. 

Thus, I'll drop this patch for my 2.6.39 queue. And I'll try to fix the
current initialization limitation to ensure applications can detect
alarm persistence.

Thanks for pointing this issue out!
-john