Date:	Wed, 23 Dec 2009 17:27:10 -0700
From:	"Dialup Jon Norstog" <thursday@...idaho.com>
To:	john stultz <johnstul@...ibm.com>, Paul Mundt <lethal@...ux-sh.org>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Richard Henderson <rth@...ddle.net>,
	linux-alpha@...r.kernel.org, linux-sh@...r.kernel.org,
	Russell King <linux@....linux.org.uk>,
	Haavard Skinnemoen <hskinnemoen@...el.com>,
	Mike Frysinger <vapier@...too.org>,
	Mikael Starvik <starvik@...s.com>,
	David Howells <dhowells@...hat.com>,
	Yoshinori Sato <ysato@...rs.sourceforge.jp>,
	Tony Luck <tony.luck@...el.com>,
	Hirokazu Takata <takata@...ux-m32r.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Koichi Yasutake <yasutake.koichi@...panasonic.com>,
	Kyle McMartin <kyle@...artin.ca>,
	"David S. Miller" <davem@...emloft.net>,
	David Brownell <dbrownell@...rs.sourceforge.net>
Subject: Re: [RFC][PATCH 0/14] Convert remaining arches to read/update_persistent_clock

john,

IMO the biggest clock problem on Alpha is that dual booting Tru64 and Linux 
whacks the clock every time you go from one OS to the other.  Allowing Linux 
to decouple from SRM's TOY clock would be a signal advance.

jon norstog


---------- Original Message -----------
From: john stultz <johnstul@...ibm.com>
To: Paul Mundt <lethal@...ux-sh.org>
Cc: lkml <linux-kernel@...r.kernel.org>, Richard Henderson 
<rth@...ddle.net>, linux-alpha@...r.kernel.org, linux-sh@...r.kernel.org, 
Russell King <linux@....linux.org.uk>, Haavard Skinnemoen 
<hskinnemoen@...el.com>, Mike Frysinger <vapier@...too.org>, Mikael Starvik 
<starvik@...s.com>, David Howells <dhowells@...hat.com>, Yoshinori Sato 
<ysato@...rs.sourceforge.jp>, Tony Luck <tony.luck@...el.com>, Hirokazu 
Takata <takata@...ux-m32r.org>, Geert Uytterhoeven <geert@...ux-m68k.org>, 
Koichi Yasutake <yasutake.koichi@...panasonic.com>, Kyle McMartin 
<kyle@...artin.ca>, "David S. Miller" <davem@...emloft.net>, David Brownell 
<dbrownell@...rs.sourceforge.net>
Sent: Wed, 23 Dec 2009 14:04:59 -0800
Subject: Re: [RFC][PATCH 0/14] Convert remaining arches to 
read/update_persistent_clock

> On Wed, 2009-12-23 at 14:08 +0900, Paul Mundt wrote:
> > On Tue, Dec 22, 2009 at 07:59:22PM -0800, john stultz wrote:
> > > In this case the generic read_persistent_clock() and
> > > update_persistent_clock() methods have been provided to allow the
> > > generic timekeeping code to initialize xtime and set the persistent
> > > clock when NTP is synced. However many arches haven't converted, so the
> > > generic code has to handle the case where the arch is doing this
> > > management itself.
> > > 
> > > This patch series tries to convert the following 14 architectures over
> > > to use read_persistent_clock() and update_persistent_clock() as
> > > applicable, killing off about 200 lines of arch specific code.
> > > 
> > While I think that this is a good goal, many of the underlying
> > architectures have veered pretty far away from having meaningful
> > persistent clock interfaces after having moved entirely to generic
> > timekeeping and the RTC subsystem.
> > 
> > In the case of SH at least that interface along with the generic CMOS
> > stuff is largely a stop-gap for antiquated platforms that don't have
> > proper RTC drivers and likely never will, while the default for all of
> > the rest of the platforms effectively returns a fixed dummy value. I
> > copied this approach from MIPS originally, so there are at least a few
> > architectures that this will apply to.
> > 
> > In any event, I wonder if it might make more sense to take something like
> > the SPARC implementation that is simply a wrapper around the RTC, move
> > that out in to a more generic place, and permit architectures to select
> > an RTC class backed persistent clock instead (it seems to be only
> > platforms that haven't caught up yet in terms of generic time and RTC
> > migration that would want to define this interface on their own at all at
> > this point)?
> 
> Yea, there's some additional complications with the RTC interface via
> read_persistent_clock, as some RTC clocks require irqs enabled to be
> able to read. This keeps them from being used via
> read_persistent_clock() as it is used prior to irqs being enabled, 
> and then again with irqs disabled in the suspend and resume path.
> 
> This has a bit of a trade-off, as we can better handle timekeeping
> around a suspend/resume with read_persistent_clock(), but for some
> hardware we just can't use the RTC for that.
> 
> Anyway, if we can improve the timekeeping/RTC interface used for
> initialization and suspend/resume, I'm all for it (maybe having the RTC
> code to tell the timekeeping code if it can be accessed with irqs 
> off?). But for hardware that needs irqs, i'm not sure how we can 
> handle resumes correctly there. So suggestions would be welcome.
> 
> Anyway, the main point of this patch set is to remove the direct access
> to timekeeping internals (xtime, wall_to_monotonic). Those need to go
> soon, as they're limiting changes in the timekeeping code.
> read_persistent_clock() is the current way to avoid it, but if 
> systems are fine doing a settimeofday() at init that's ok too 
> (although some oddities may be seen wrt boot time with the direct 
> settimeofday, I need to refresh my head on how the varying default 
> boot times between arches may be effected).
> 
> thanks
> -john
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> alpha" in the body of a message to majordomo@...r.kernel.org More 
> majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
------- End of Original Message -------

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists