On Tuesday 11 November 2008, David Woodhouse wrote: > I believe you were also concerned that some device wouldn't want the > behaviour given by the existing sync_cmos_clock() function and workqueue > stuff in kernel/ntp.c, where we update the clock precisely half-way > through the second?
That's a problem, yes. I've never heard of any RTC that wants such delays ... except for the PC's "CMOS" RTC. There was some discussion about how to expose that knowledge to userspace too. The "hwclock" utility always imposes that delay, and it shouldn't (except when talking to a PC RTC). > We should probably rip that code out of ntp.c (or just disable it ifdef > CONFIG_RTC_CLASS), and provide our own version of notify_cmos_timer(). My suggestion for in-kernel code is that "struct rtc_device" just grow a field like "unsigned settime_delay_msec" which would never be initialized except by rtc-cmos (which uses 500) ... and the NTP sync code would use that value. For out-of-kernel use, that value could be extracted with an ioctl(), and used similarly. > The workqueue stuff to trigger at half-past the second could be kept as > a library function which most RTC devices would use, but they'd have the > option to use their own instead. I thought the workqueue stuff was primarily there to make sure that RTC was always updated in task context -- so it can grab the relevant mutex -- and the half-second delay was legacy PC code ... - Dave _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
