Date:	Tue, 13 May 2008 04:25:45 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Alessandro Zummo <a.zummo@...ertech.it>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Atsushi Nemoto <anemo@....ocn.ne.jp>,
	David Woodhouse <dwmw2@...radead.org>,
	Jean Delvare <khali@...ux-fr.org>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Thomas Gleixner <tglx@...utronix.de>
cc:	rtc-linux@...glegroups.com, i2c@...sensors.org,
	linux-mips@...ux-mips.org, linux-kernel@...r.kernel.org
Subject: [PATCH 0/6] RTC: Use class devices as a persistent clock (#2)

Hello,

 This is the second stage of patch submission for this change.  Thanks
everybody for all the useful suggestions and testing.  As I understand the
changes are in line with the intent of everyone concerned.  At this
moment, unless anybody complains, I consider these patches ready to be
applied upstream.

 These patches provide means to switch to the RTC class devices for the
purpose of providing the backup clock for 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.

 Significant changes from the first iteration:

1. MIPS Makefile changes are now separate so that they can go straight
   into the MIPS tree without relying on I2C changes.

2. M41T80 driver changes have been simplified -- thanks, Jean and DavidB,
   for your feedback letting me understand the I2C core better.

 Individual patches follow, feedback is welcome.  All have been
successfully tested at the run time with a big-endian 64-bit MIPS
configuration (a Broadcom BCM91250A board), 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists