[RFC][PATCH 0/4] RTC: Use class devices as a persistent clock

[Maciej W. Rozycki]

Hello,

 While investigating why Linux on the MIPS64 Broadcom BCM91250A board (the
SWARM, based on the SiByte BCM1250A SOC) does not support an RTC device
anymore I discovered the "wiring" of code to access /dev/rtc to the RTC
device driver got removed with some changes that happened a while ago.  
The board uses the ST M41T81 I2C chip with a driver buried within the
architecture code.  There is a standard driver for this chip in our tree
already, which is called rtc-m41t80, and which as a part of the RTC driver
suite provides the necessary "wiring" to /dev/rtc.

 I decided to remove the platform driver as redundant and unportable -- it
groups together knowledge about the M41T81 and the BCM1250A onchip I2C
controller.  This revealed a couple of problems which this patch set
addresses.  I'd like to skip the discussion of hardware-specific bits
here, which I think are rather obvious and which I will cover with the
individual patches.

 My point here is whether we want to switch over to the RTC suite in
preference to legacy RTC drivers (like drivers/char/rtc.c) and perhaps
more importantly platform RTC drivers which are often buried in a mixture
of header files and arch C code for the purpose of timekeeping.  The API
in question are the read_persistent_clock() and update_persistent_clock()  
functions used mostly by the NTP support code.

 The notable gain is the removal of the additional burden from platform
code -- all that has be implemented is support for the RTC chip the
platform has.  I have added the rtc_read_persistent_clock() and
rtc_update_persistent_clock() functions to the RTC suite that can serve as
the implementation of the API and work the same (hardware implementation
permitting) regardless of the exact RTC chip used.  There is even support
for the ubiquitous derivatives of the MC146818 available as a class device
already.  Additionally, if there is more than one RTC chip in a given
system, the user can select which of the chips to use.

 The drawback is some implementations behind these functions may sleep,
for example because hardware is slow to access.  The current calling
context of update_persistent_clock() (which is the softirq) does not
permit the function to sleep.  To rectify I have moved the call into the
process context, but it now means the latency between getnstimeofday() and
the writeback into the RTC will be yet less predictable and potentially
higher.  This should not matter in practice, because the RTC generally
cannot guarantee suitable precision to be a reliable sub-second resolution
device for providing time while the NTP daemon is not running and one who
cares about timekeeping will run NTP during normal system operation anyway
which will correct any inaccuracy gathered from the RTC.  I am mentioning
it though as I think it should be noted.

 Individual patches follow, feedback is welcome.  All have been
successfully tested at the run time with a big-endian 64-bit MIPS
configuration, using the usual SMP vs non-SMP and PREEMPT vs non-PREEMPT
configurations, with spinlock, etc. debugging on; no checkpatch.pl nor
sparse problems either.  They have been successfully built for a 32-bit
x86 and Alpha configuration as well.

  Maciej
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/