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 19:35:23 -0700 [thread overview]
Message-ID: <20130123023523.GC1590@obsidianresearch.com> (raw)
In-Reply-To: <50FF42CD.6010203@linaro.org>
On Tue, Jan 22, 2013 at 05:54:21PM -0800, John Stultz wrote:
> >>complicated part. Additionally, there may be cases where the
> >>timekeeping clocksource is one clocksource and the suspend
> >>clocksource is another. So I think to properly integrate this sort
> >Does the difference matter? The clocksource to use is detected at
> >runtime, if the timekeeping clocksource is no good for suspend time
> >keeping then it just won't be used. With a distinct
> >read_persistent_clock API then they are already seperate??
>
> Not sure I'm following you here. I still think the selection of
> which clocksource to use for suspend timing is problematic
> (especially if its not the active timekeeping clocksource). So I
> think instead of complicating the generic timekeeping code with the
> logic, I'd rather push it off to new read_presistent_clock api.
Well, where do you see the complication?
My thought was to save the cycle_t from *all* the clock sources during
suspend, and then on resume look for the highest priority one where
the driver reports it continued to tick the whole time. The active
timekeeping clock source doesn't seem to come into the equation??
Add
int (*active_during_suspend)(struct clocksource *cs);
cycle_t value_before_suspend;
To struct clocksource.
Before suspend:
foreach(cs,all clocksources) {
if (cs->active_during_suspend)
cs->value_before_suspend = cs->read(cs);
}
After resume:
cycle_t best_delta = 0;
struct clocksource *best_cs = NULL;
foreach(cs,all clocksources) {
if (cs->active_during_suspend &&
(best_cs == NULL || cs->rating > best_cs->rating) &&
cs->active_during_suspend(cs)) {
best_delta = cs->read(cs) - cs->value_before_suspend;
best_cs = cs;
}
}
Update the TSC driver to set the function pointer
active_during_suspend when the CPU supports non-stop TSC. Have it
return true if S3 was the deepest sleep entered during the last
suspend/resume cycle, false otherwise. Ditto for that ARM case.
This seems reasonably simple, compared to adding a new API, new
drivers, new function pointer multiplexors to arches...
Jason
next prev parent reply other threads:[~2013-01-23 2:35 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
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 [this message]
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=20130123023523.GC1590@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