Peter Jeremy <[email protected]> writes: > Traditionally, the (PC) RTC is on the ISA bus (though it's possible it > might use I2C on other architectures or LPC on current PCs).
AFAIK, it's usually on I2C on non-i386 platforms. I2C RTC chips are dirt cheap and easy to integrate, especially if you already have I2C temperature sensors and whatnot. > > Actually, it might be a good idea to call resettodr() any time the > > clock is stepped. > This should occur now via kern_time.c::settime(). OK. > Given that: > - resettodr() needs to be serialised; > - resettodr() may take a significant amount of time; and > - resettodr() should ideally be synchronised to the second boundary; > maybe creating a kthread to manage the RTC updating is reasonable. If "synchronised to the second boundary" means what I think it means (set the RTC at the exact top-of-the-second), don't go out of your way to implement that. You don't get that kind of accuracy back when you read it anyway - unless it's a calibrated RTC (I've written a Linux driver for one, hence my familiarity with eleven-minute-mode etc.) > A new kthread which sleeps on channel "update_rtc". When woken, it > checks to see if it's within (say) 50msec of a second boundary and so, > it does a trylock on the (new) RTC mutex. If it grabs the mutex then > it performs the update. If it was too far from the second boundary or > it fails to grab the mutex then it sleeps until the next second > boundary and tries again. > > The existing resettodr() would then turn into a wakeup(update_rtc). Sounds good to me, but if only that thread has access to the RTC, why bother with a mutex? DES -- Dag-Erling Smørgrav - [email protected] _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[email protected]"
