From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Gleixner Subject: Re: [PATCH] timekeeping: Move persistent clock registration code from ARM to kernel Date: Fri, 14 Nov 2014 01:26:44 +0100 (CET) Message-ID: References: <1415388855-35074-1-git-send-email-anatol.pomozov@gmail.com> <20141110095325.GC12126@ulmo> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-Reply-To: Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: John Stultz Cc: Anatol Pomozov , Thierry Reding , Stephen Warren , Daniel Lezcano , Russell King , LKML , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Tony Lindgren , Mark Rutland List-Id: linux-tegra@vger.kernel.org On Thu, 13 Nov 2014, John Stultz wrote: > On Thu, Nov 13, 2014 at 2:46 PM, Thomas Gleixner wrote: > > Aside of that I really wonder why we need that persistent_clock stuff > > at all. We already have mechanisms to register persistent clocks AKA > > RTCs after the early boot process and update the wall clock time > > before we actually need it. Nothing in early boot depends on correct > > wall clock at all. > > > > So instead of adding more extra persistent clock nonsense, can we just > > move all of that to the place where it belongs, i.e. RTC? > > Sigh.. I've got this on an eventual todo list.. The big problem though > is that the RTC infrastructure can't be called with irqs off, so its > not as optimal for measuring suspend time. Some of the suspend-time > measurement with clocksources that don't halt is interesting here. > > So we need to add to the RTC infrastructure special accessors that are > safe when irqs are off, and we can then deprecate the persistent clock > bits. There's still evaluation quirks with setting the time earlier in > boot or not (possibly some rng effects as well there), but that could > be worked out if we had the suspend timing via safe RTC interfaces > sorted. So we better work on this instead of creating more legacy enforcement APIs.... Thanks, tglx