> Almost every arch has some form of persistent clock (CMOS, RTC, etc)
> which is normally used at boot time to initialize xtime and
> wall_to_monotonic. As part of the timekeeping consolidation, I propose
> the following generic interface to the arch specific persistent clock:
Hmm, this seems to ignore the RTC framework rather entirely, which
seems to me like the wrong implementation approach. You'd likely have
noticed that if you had supported a few ARM boards. :)
Here's a fairly common scenario for an embedded system: the battery
backed clock is accessed through I2C or SPI, rather than an ISA style
direct register access, so it's not accessible until after those driver
stacks have initialized.
Or similarly, the SOC family may have a powerful RTC ("arch specific")
with alarm and system wakeup capabilities, but it may not be the system's
battery backed clock ... so that RTC would be initialized from another one,
which is accessed using I2C/SPI/etc. (RTCs integrated on SOCs evidently
have a hard time being as power-miserly as the discrete ones.)
The approach in this patch doesn't seem to play well with those scenarios,
because it expects to do timekeeping setup long before the system's RTC is
necessarily going to be available ... and doesn't have an answer for those
cases where the RTC is unavailable before e.g. late_initcall().
I'd be more interested in something that improves on CONFIG_RTC_HCTOSYS,
and for example addresses the need to update the system wall time from
such RTCs after resume, not just at boot time.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
