All of lore.kernel.org
 help / color / mirror / Atom feed
From: Magnus Damm <magnus.damm@gmail.com>
To: linux-kernel@vger.kernel.org
Cc: mark.rutland@arm.com, linux-sh@vger.kernel.org,
	marc.zyngier@arm.com, catalin.marinas@arm.com,
	horms@verge.net.au, john.stultz@linaro.org,
	shinya.kuribayashi.px@renesas.com,
	Magnus Damm <magnus.damm@gmail.com>,
	tglx@linutronix.de
Subject: [PATCH/RFC] arm: arch_timer: Do not set C3STOP in case CPU_IDLE=n
Date: Mon, 17 Jun 2013 00:20:56 +0000	[thread overview]
Message-ID: <20130617002056.7646.54131.sendpatchset@w520> (raw)

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 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) {

WARNING: multiple messages have this Message-ID (diff)
From: Magnus Damm <magnus.damm@gmail.com>
To: linux-kernel@vger.kernel.org
Cc: mark.rutland@arm.com, linux-sh@vger.kernel.org,
	marc.zyngier@arm.com, catalin.marinas@arm.com,
	horms@verge.net.au, john.stultz@linaro.org,
	shinya.kuribayashi.px@renesas.com,
	Magnus Damm <magnus.damm@gmail.com>,
	tglx@linutronix.de
Subject: [PATCH/RFC] arm: arch_timer: Do not set C3STOP in case CPU_IDLE=n
Date: Mon, 17 Jun 2013 09:20:56 +0900	[thread overview]
Message-ID: <20130617002056.7646.54131.sendpatchset@w520> (raw)

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 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) {

             reply	other threads:[~2013-06-17  0:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-17  0:20 Magnus Damm [this message]
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:13   ` Simon Horman
2013-06-17  2:47   ` Magnus Damm
2013-06-17  2:47     ` Magnus Damm
2013-06-17  2:57     ` Simon Horman
2013-06-17  2:57       ` Simon Horman
2013-06-17 14:53 ` Mark Rutland
2013-06-17 14:53   ` Mark Rutland
2013-06-18  7:32   ` Magnus Damm
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=20130617002056.7646.54131.sendpatchset@w520 \
    --to=magnus.damm@gmail.com \
    --cc=catalin.marinas@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=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.