From: Mark Rutland <mark.rutland@arm.com>
To: Magnus Damm <magnus.damm@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
Marc Zyngier <Marc.Zyngier@arm.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
"horms@verge.net.au" <horms@verge.net.au>,
"john.stultz@linaro.org" <john.stultz@linaro.org>,
"shinya.kuribayashi.px@renesas.com"
<shinya.kuribayashi.px@renesas.com>,
"tglx@linutronix.de" <tglx@linutronix.de>
Subject: Re: [PATCH/RFC] arm: arch_timer: Do not set C3STOP in case CPU_IDLE=n
Date: Mon, 17 Jun 2013 15:53:52 +0100 [thread overview]
Message-ID: <20130617145352.GG6809@e106331-lin.cambridge.arm.com> (raw)
In-Reply-To: <20130617002056.7646.54131.sendpatchset@w520>
On Mon, Jun 17, 2013 at 01:20:56AM +0100, Magnus Damm wrote:
> From: Magnus Damm <damm@opensource.se>
>
> Modify the ARM architected timer driver to not set C3STOP
> in case CPU_IDLE is disabled. This is a short term fix that
> allows use of high resolution timers even though no additional
> clock event is registered.
>
> Not-really-Signed-off-by: Magnus Damm <damm@opensource.se>
> ---
>
> If someone cares about this case then perhaps it should be
> moved up to the clock event main code. The same issue should
> in theory trigger on all architectures, perhaps x86 people
> hunting for low latency may try to disable CPU_IDLE?
I think that changing tick_is_oneshot_capable and friends to only worry about
C3STOP when CPU_IDLE is enabled would be a nicer solution. That way you enable
all clock_event_devices with C3STOP to function as high resolution timers when
CPU_IDLE's selected. Presenting the hardware differently depending on CPU_IDLE
feels wrong.
Having some other clock_event_device would be a nicer solution still.
Thanks,
Mark.
>
> I propose carrying this patch locally to enable high resolution
> timers until CPU_IDLE and an additional clock event is supported.
>
> Observed on r8a73a4 and APE6EVM.
>
> drivers/clocksource/arm_arch_timer.c | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> --- 0001/drivers/clocksource/arm_arch_timer.c
> +++ work/drivers/clocksource/arm_arch_timer.c 2013-06-17 09:03:44.000000000 +0900
> @@ -125,7 +125,23 @@ static int arch_timer_set_next_event_phy
>
> static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
> {
> - clk->features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP;
> + clk->features = CLOCK_EVT_FEAT_ONESHOT;
> +#ifdef CONFIG_CPU_IDLE
> + /* By not setting the C3STOP flag it is possible to let the
> + * ARM architected timer to be the only clock event installed
> + * on the system and have working high resolution timers.
> + *
> + * If the C3STOP flag is set unconditionally then the kernel
> + * will always prevent using the high resoultion timer feature
> + * unless an additional clock event is registered.
> + *
> + * In the case where CPU_IDLE is enabled then there is a chance
> + * that deeper sleep states will be handled by software, but
> + * if CPU_IDLE is disabled then deep sleep states cannot be
> + * entered and the feature flagged by C3STOP is not needed.
> + */
> + clk->features |= CLOCK_EVT_FEAT_C3STOP;
> +#endif
> clk->name = "arch_sys_timer";
> clk->rating = 450;
> if (arch_timer_use_virtual) {
>
next prev parent reply other threads:[~2013-06-17 14:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-17 0:20 [PATCH/RFC] arm: arch_timer: Do not set C3STOP in case CPU_IDLE=n Magnus Damm
2013-06-17 2:13 ` Simon Horman
2013-06-17 2:47 ` Magnus Damm
2013-06-17 2:57 ` Simon Horman
2013-06-17 14:53 ` Mark Rutland [this message]
2013-06-18 7:32 ` Magnus Damm
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=20130617145352.GG6809@e106331-lin.cambridge.arm.com \
--to=mark.rutland@arm.com \
--cc=Catalin.Marinas@arm.com \
--cc=Marc.Zyngier@arm.com \
--cc=horms@verge.net.au \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=shinya.kuribayashi.px@renesas.com \
--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