From: john stultz <johnstul@us.ibm.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Feng Tang <feng.tang@intel.com>,
Jacob Pan <jacob.jun.pan@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
"Du, Alek" <alek.du@intel.com>,
Arjan van de Ven <arjan@linux.intel.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 7/8] x86/mrst: add vrtc driver which serves as a wall clock device
Date: Tue, 18 May 2010 13:43:54 -0700 [thread overview]
Message-ID: <1274215434.1699.12.camel@localhost> (raw)
In-Reply-To: <alpine.LFD.2.00.1005171102590.3368@localhost.localdomain>
On Mon, 2010-05-17 at 11:15 +0200, Thomas Gleixner wrote:
>
>
> There is no particular reason why we need to read it in
> timekeeping_init(). Nothing in the kernel needs the correct wall time
> at that point. So we can safely move the setting of xtime to rtc wall
> clock time to a separate timekeeping_late_init() function.
>
> John ???
No big objections here. Still would like to keep the amount of time that
the kernel is up without xtime being initialized to a minimum. However
the generic RTC code already have this issue since some of them require
interrupts to be enabled to do a read, so pushing it off into a
_late_init() function is probably just a short term fix until we figure
out how to get the generic RTC code working better with the timekeeping
code.
Does the delayed init required by vrtc cause any trouble with
suspend/resume?
thanks
-john
next prev parent reply other threads:[~2010-05-18 20:44 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-07 17:41 [PATCH 0/8] Moorestown changes in arch/x86 for 35 merge window Jacob Pan
2010-05-07 17:41 ` [PATCH 1/8] x86: avoid check hlt if no timer interrupts Jacob Pan
2010-05-07 20:32 ` RFD: Should we remove the HLT check? (was Re: [PATCH 1/8] x86: avoid check hlt if no timer interrupts) H. Peter Anvin
2010-05-07 20:33 ` Arjan van de Ven
2010-05-07 20:36 ` H. Peter Anvin
2010-05-07 22:24 ` Alan Cox
2010-05-07 22:27 ` H. Peter Anvin
2010-05-07 22:46 ` Alan Cox
2010-05-07 22:35 ` Arjan van de Ven
2010-05-07 20:54 ` Linus Torvalds
2010-05-07 21:04 ` H. Peter Anvin
2010-05-07 22:07 ` jacob pan
2010-05-07 17:41 ` [PATCH 2/8] x86/mrst/pci: return 0 for non-present pci bars Jacob Pan
2010-05-07 17:41 ` [PATCH 3/8] x86/apic: allow use of lapic timer early calibration result Jacob Pan
2010-05-11 13:46 ` Thomas Gleixner
2010-05-11 19:42 ` Pan, Jacob jun
2010-05-11 19:50 ` Thomas Gleixner
2010-05-11 20:46 ` Pan, Jacob jun
2010-05-11 20:51 ` H. Peter Anvin
2010-05-07 17:41 ` [PATCH 4/8] x86/mrst: change clock selection logic to support medfield Jacob Pan
2010-05-11 14:36 ` Thomas Gleixner
2010-05-11 15:30 ` Alan Cox
2010-05-11 15:50 ` Thomas Gleixner
2010-05-11 16:03 ` Alan Cox
2010-05-13 22:16 ` Pan, Jacob jun
2010-05-17 2:14 ` Du, Alek
2010-05-17 2:27 ` Du, Alek
2010-05-07 17:41 ` [PATCH 5/8] x86/apbt: support more timer configurations on mrst Jacob Pan
2010-05-07 17:41 ` [PATCH 6/8] x86/platform: add a wallclock_init func to x86_platforms ops Jacob Pan
2010-05-11 14:42 ` Thomas Gleixner
2010-05-07 17:41 ` [PATCH 7/8] x86/mrst: add vrtc driver which serves as a wall clock device Jacob Pan
2010-05-07 18:51 ` Joe Perches
2010-05-07 19:02 ` Alan Cox
2010-05-07 19:06 ` Joe Perches
2010-05-07 19:56 ` H. Peter Anvin
2010-05-10 9:17 ` Feng Tang
2010-05-10 18:22 ` H. Peter Anvin
2010-05-11 2:30 ` Feng Tang
2010-05-11 14:57 ` Thomas Gleixner
2010-05-12 2:34 ` Feng Tang
2010-05-17 9:15 ` Thomas Gleixner
2010-05-18 6:27 ` Feng Tang
2010-05-18 7:38 ` Thomas Gleixner
2010-05-18 20:43 ` john stultz [this message]
2010-05-18 21:02 ` Thomas Gleixner
2010-05-21 2:15 ` [PATCH 1/3] timekeeping: moving xtime's init to a later time Feng Tang
2010-05-21 2:16 ` [PATCH 2/3] x86: unify current 3 similar ways of saving IRQ info Feng Tang
2010-05-21 2:19 ` [PATCH 3/3] x86/mrst: add vrtc driver which serves as a wall clock device Feng Tang
2010-05-07 17:41 ` [PATCH 8/8] x86/mrst: Add nop functions to x86_init mpparse functions Jacob Pan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1274215434.1699.12.camel@localhost \
--to=johnstul@us.ibm.com \
--cc=alek.du@intel.com \
--cc=arjan@linux.intel.com \
--cc=feng.tang@intel.com \
--cc=hpa@zytor.com \
--cc=jacob.jun.pan@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).