Date: Sun, 28 Mar 2010 13:45:25 +0200 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: Peter Jeremy <peterjeremy@acm.org> Cc: freebsd-hackers@FreeBSD.org, Andriy Gapon <avg@icyb.net.ua> Subject: Re: periodically save current time to time-of-day hardware Message-ID: <86fx3k7jqi.fsf@ds4.des.no> In-Reply-To: <20100327214634.GI32799@server.vk2pj.dyndns.org> (Peter Jeremy's message of "Sun, 28 Mar 2010 08:46:34 %2B1100") References: <4BACC791.70502@icyb.net.ua> <86zl1v84vy.fsf@ds4.des.no> <4BACD88E.2040803@icyb.net.ua> <86vdcj82qx.fsf@ds4.des.no> <20100326213022.GD32799@server.vk2pj.dyndns.org> <86pr2qlhtf.fsf@ds4.des.no> <20100327214634.GI32799@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy <peterjeremy@acm.org> 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 --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86fx3k7jqi.fsf>