Improvements to iphb client wakeups and rtc time/alarm management

[spiiroin]

The rtc time is synchronized to system in two phases. First the rtc
time of day is brought within one second of system time. Then
sub-second timer is used to write rtc time of day again when system
time is just past full second. Effectively this should make rtc wakeup
alarms both more accurate (since the rtc is closer to system time) and
less frequent (since rtc should always be a bit behind system time and
thus the normal timers trigger before rtc alarms as long as the system
is not suspended).

Also while libiphb api still uses full seconds for wakeup ranges, they
are processed internally in us/ms accuracy. This should limit the odd
+/-1 second issues resulting from mixed use of system time, monotonic
clock and rtc time of day.

If libiphb clients request too wide mintime-maxtime range for the
wakeup, the mintime is moved closer to maxtime.

Also the client wakeups are done as late as possible, but if there are
external clients that must be woken up, all eligible clients are woken
up at the same time.

[iphb] Improvements to iphb client wakeups and rtc time/alarm management

[rburchell]

With the advent of git packaging, you'll want to use [FOO] type prefixes on your commit messages, where FOO might be dsme in this case. Each tagged release must have at least one such prefix, otherwise it won't build.

The RPM changelog is automatically generated from these messages.

P.S. will this fix constant spam like this?:

May 27 15:04:08 localhost DSME[254]: IPHB: read /dev/rtc0: type=0xa0, count=1
May 27 15:04:08 localhost DSME[254]: IPHB: rtc alarm disabled
May 27 15:04:08 localhost DSME[254]: IPHB: rtc alarm @ 2013-05-27 12:04:21

because that's starting to make debugging really annoying.

[spiiroin]

I've understood that the preferred way is not to have the [feature] in the "commit title", hence the last
line "[iphb] Improvements to iphb client wakeups and rtc time/alarm management" is meant to go to
the changelog.

The "IPHB: read /dev/rtc0: type=0xa0, count=1" is not spam. It just highlighted that there were issues
with using one second accuracy while dealing with multiple clock sources. It should have come only
when the device wakes up from suspend to handle an iphb timer. I'd like to keep it there, since if it
still annoys people we need further fixing. (The log message is jibberish though, I'll fix it)

The "rtc alarm this and that" however were debug spam and are no longer emitted by default.

[spiiroin]

Just realized that also the "IPHB: read /dev/rtc0: type=0xa0, count=1" diagnostics were omitted by default.
They still are, but now - in verbose mode - the output will be "woke up to handle rtc wakeup alarm".