Re: [patch] Generic time fixes

[Ralf Baechle <ralf@linux-mips.org>]

On Tue, Jul 22, 2003 at 12:21:04PM +0200, Wolfgang Denk wrote:

> Another common situation especially with embedded systems is that the
> RTC holds the "correct"  time,  and  probably  runs  at  much  higher
> precision  than  the systm clock. In such systems, NTP can be used to
> keep the system time in sync with the RTC, but the system  time  must
> never  be  written  back to the RTC. [Except when explicitely setting
> the date&time.]

True; supposedly the TXOs in RTC have higher long term frequency accuracy
than those commonly used to clock system though some RTC are really
badly off.

> > I share your dislike of updating the RTC for performance reasons; these
> 
> There are more problems with the 11 minute mode.  We  ran  into  this
> issue  for hard on some PowerPC systems. Assume a situation where the
> RTC is connected through a I2C  bus.  Problem  1:  normally  the  i2c
> drivers  will  be  loaded prety late, which means the system will run
> initially with an undefined time. Problem 2: on some  actions  a  i2c
> transfer  involves  programming an on-chip i2c controller, which will
> perform the task and then signal it's done by an interrupt. On such a
> system the 11 minute mode will crash the system because rtc_set  will
> be called from interrupt contect itself.
> 
> There was a  somewhat  controverse  discussion  on  the  linuxppc_dev
> mailing list, without a real solution.

[...]

> And never, ever update the RTC from interrupt context, please.

It's the right thing for > 99% of systems and doing it triggered by an
interrupt seems the right thing.  If you happen to have hardware that
has trouble with updates in interrupts you still could implement the
RTC update procedure to just trigger the update in softirq or process
context, as appropriate.

  Ralf