From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: John Stultz <john.stultz@linaro.org>
Cc: Feng Tang <feng.tang@intel.com>,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
"H. Peter Anvin" <hpa@linux.intel.com>,
x86@kernel.org, Len Brown <lenb@kernel.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/5] Add support for S3 non-stop TSC support.
Date: Tue, 22 Jan 2013 12:57:01 -0700 [thread overview]
Message-ID: <20130122195701.GH30647@obsidianresearch.com> (raw)
In-Reply-To: <50FD8D07.5030908@linaro.org>
On Mon, Jan 21, 2013 at 10:46:31AM -0800, John Stultz wrote:
> What I'd propose is that we break the read_persistent_clock()
> functionality up. So we need two interfaces:
> 1) An interface to access a time value we used to initialize the
> system's CLOCK_REALTIME time.
> 2) An interface to measure the length of suspend.
> Interface #1 could be possibly just replaced with the RTCTOSYS
> functionality. Although the downside there is that for some time at
> bootup between the timekeeping_init() function running (prior to
> interrupts being enabled) and the RTC driver being available (after
> interrupts are enabled), where we'd have an incorrect system clock.
> So we may want to preserve something like the existing
> read_persistent_clock() interface, but as Jason suggested, we could
> push that access into the RTC driver itself.
How big of an issue is this? Could the RTCTOSYS function be moved to
the moment the RTC driver is registered rather than using a
late_initcall?
> Interface #2 could then be either RTC based, or countinuous counter
> based. Since we still want to do this measurement with interrupts
> off, we still would need that interrupt-free RTC method like
> read_persistent_clock() where supported (falling back to the RTC
> driver's suspend/resume handler to try to fix things up as best it
> can if that's not available).
Could the counter version of this be bundled into the clocksource
framework? It already has generic APIs for handling cycle counters and
things. Isn't there a TSC driver for clocksource already? Is all that
is missing is a way to tell if the counter survived suspend?
clocksource already has suspend/resume callbacks stuff, so the counter
driver could sense if the sleep was too deep and mark itself as
invalid.
This would help solve the problem on ARM with muxing persistent clock
on multi-platform.
A RTC device flag 'readable with interrupts off' still seems like a
good idea for the RTC case..
Cheers,
Jason
next prev parent reply other threads:[~2013-01-22 19:57 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-21 6:38 [RFC PATCH 0/5] Add support for S3 non-stop TSC support Feng Tang
2013-01-21 6:38 ` [RFC PATCH 1/5] x86: Add cpu capability flag X86_FEATURE_TSC_S3_NOTSTOP Feng Tang
2013-01-21 7:27 ` Chen Gong
2013-01-21 7:59 ` Feng Tang
2013-01-21 15:58 ` H. Peter Anvin
2013-01-22 14:07 ` Feng Tang
2013-01-21 6:38 ` [RFC PATCH 2/5] clocksource: Add new feature flag CLOCK_SOURCE_SUSPEND_NOTSTOP Feng Tang
2013-01-21 6:38 ` [RFC PATCH 3/5] x86: tsc: Add support for new S3_NOTSTOP feature Feng Tang
2013-01-21 6:38 ` [RFC PATCH 4/5] clocksource: Enlarge the maxim time interval when configuring the scale and shift Feng Tang
2013-01-21 7:25 ` Chen Gong
2013-01-21 6:38 ` [RFC PATCH 5/5] timekeeping: Add support for clocksource which doesn't stop during suspend Feng Tang
2013-01-21 13:55 ` [RFC PATCH 0/5] Add support for S3 non-stop TSC support Rafael J. Wysocki
2013-03-30 18:14 ` Pavel Machek
2013-04-01 17:32 ` John Stultz
2013-04-01 20:31 ` Pavel Machek
2013-04-01 20:41 ` John Stultz
2013-01-21 18:46 ` John Stultz
2013-01-22 14:55 ` Feng Tang
2013-01-22 21:56 ` John Stultz
2013-01-24 3:37 ` Feng Tang
2013-01-24 18:15 ` Jason Gunthorpe
2013-01-22 19:57 ` Jason Gunthorpe [this message]
2013-01-22 20:22 ` John Stultz
2013-01-23 0:26 ` Jason Gunthorpe
2013-01-23 0:41 ` John Stultz
2013-01-23 1:37 ` Jason Gunthorpe
2013-01-23 1:54 ` John Stultz
2013-01-23 2:35 ` Jason Gunthorpe
2013-01-23 3:07 ` John Stultz
2013-01-23 19:23 ` Jason Gunthorpe
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=20130122195701.GH30647@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=feng.tang@intel.com \
--cc=hpa@linux.intel.com \
--cc=john.stultz@linaro.org \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rafael.j.wysocki@intel.com \
--cc=tglx@linutronix.de \
--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