From: joeyli <jlee@suse.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Julian Wollrath <jwollrath@web.de>,
x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
John Stultz <john.stultz@linaro.org>, "Ted Ts'o" <tytso@mit.edu>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
Date: Thu, 13 Mar 2014 10:38:27 +0800 [thread overview]
Message-ID: <1394678307.26565.218.camel@linux-s257.site> (raw)
In-Reply-To: <alpine.DEB.2.02.1403130049500.18573@ionos.tec.linutronix.de>
於 四,2014-03-13 於 01:54 +0100,Thomas Gleixner 提到:
> On Thu, 13 Mar 2014, Rafael J. Wysocki wrote:
> > Thus follow the original idea to execute acpi_early_init() before
> > efi_enter_virtual_mode() to help the EFI people for now and we can
> > revisit the other problem that commit 73f7d1ca3263 attempted to
> > address in the future (if really necessary).
>
> It's not necessary at all. In fact we really want to get rid of the
> arch specific cmos stuff which is an historical leftover.
>
> I talked to John Stultz earlier today and he agrees that there are
> only a few trivial things to add to the RTC subsystem to make this
> work.
>
I sent rtc-acpitad driver for RTC subsystem on last month, I will send
second version.
For using TAD to set wall clock is because in ACPI 5.0 spec, there have
a "CMOS RTC Not Present" flag in FADT to indicate OSPM should use TAD
when this flag set:
CMOS RTC Not Present
If set, indicates that the CMOS RTC is either not implemented, or
does not exist at the legacy addresses. OSPM uses the Control
Method Time and Alarm Namespace device instead.
So, the original thinking of patch is using TAD to replace CMOS
interface in kernel for access RTC. The timekeeping_init() is the
earliest function to access CMOS RTC, that's why move TAD before it.
I hope can discuss about "CMOS RTC Not Present" flag. If hardware vendor
set this flag in FADT, should we avoid to access CMOS RTC interface in
any kernel code?
> >From the timekeeping POV there is absolutely no need to set the wall
> clock time early. The kernel boot phase does not care about wall time
> at all. We should have it done before we hit userspace, but not even
> that is a hard requirement.
I agree! If kernel boot phase does not care about wall time, then we
don't need parse DSDT for access TAD too early.
>
> That TAD/EFI time mess is not going to happen before that is solved.
>
> Thanks,
>
> tglx
>
ACPI TAD return local time and timezone information so kernel can adjust
wall time then don't need userspace involve.
Thanks a lot!
Joey Lee
next prev parent reply other threads:[~2014-03-13 2:39 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-10 10:04 [RESEND] Fast TSC calibration fails with v3.14-rc1 and later Julian Wollrath
2014-03-10 10:27 ` Paul Bolle
2014-03-10 14:06 ` Thomas Gleixner
2014-03-10 15:28 ` Paul Bolle
2014-03-10 17:04 ` Thomas Gleixner
2014-03-10 18:32 ` Paul Bolle
2014-03-10 18:57 ` Thomas Gleixner
2014-03-10 19:19 ` Paul Bolle
2014-03-10 20:50 ` Thomas Gleixner
2014-03-10 23:06 ` Paul Bolle
2014-03-11 16:02 ` Thomas Gleixner
2014-03-11 13:27 ` Julian Wollrath
2014-03-10 10:39 ` Thomas Gleixner
2014-03-11 13:29 ` Julian Wollrath
2014-03-11 13:56 ` Thomas Gleixner
2014-03-11 17:15 ` Julian Wollrath
2014-03-12 4:00 ` joeyli
2014-03-12 10:20 ` Julian Wollrath
2014-03-12 13:52 ` joeyli
2014-03-12 11:20 ` Rafael J. Wysocki
2014-03-12 13:30 ` Rafael J. Wysocki
2014-03-12 13:55 ` Julian Wollrath
2014-03-12 15:41 ` joeyli
2014-03-12 16:20 ` Thomas Gleixner
2014-03-12 16:23 ` Thomas Gleixner
2014-03-12 16:39 ` Thomas Gleixner
2014-03-12 23:27 ` Rafael J. Wysocki
2014-03-12 23:49 ` Thomas Gleixner
2014-03-13 0:13 ` Rafael J. Wysocki
2014-03-13 2:56 ` joeyli
2014-03-13 0:54 ` Thomas Gleixner
2014-03-13 1:01 ` Thomas Gleixner
2014-03-13 2:38 ` joeyli [this message]
2014-03-13 3:11 ` H. Peter Anvin
2014-03-13 3:55 ` joeyli
2014-03-13 3:59 ` H. Peter Anvin
2014-03-13 4:12 ` joeyli
2014-03-13 8:12 ` Thomas Gleixner
2014-03-13 8:59 ` joeyli
2014-03-13 3:41 ` H. Peter Anvin
2014-03-12 14:00 ` joeyli
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=1394678307.26565.218.camel@linux-s257.site \
--to=jlee@suse.com \
--cc=hpa@zytor.com \
--cc=john.stultz@linaro.org \
--cc=jwollrath@web.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rjw@rjwysocki.net \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=x86@kernel.org \
/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