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
