public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: slash.tmp@free•fr (Mason)
To: linux-arm-kernel@lists•infradead.org
Subject: schedule_timeout sleeps too long after dividing CPU frequency
Date: Thu, 21 May 2015 14:35:42 +0200	[thread overview]
Message-ID: <555DD11E.7080302@free.fr> (raw)
In-Reply-To: <2681862.SyQNaSxams@wuerfel>

On 21/05/2015 00:18, Arnd Bergmann wrote:

> On Wednesday 20 May 2015 23:56:31 Mason wrote:
>
>> Or perhaps the other way around?
>> i.e. feat_c3stop initialized to 0 (thus in the bss section)
>> and set to FEAT_C3STOP if "twd_never_stops" doesn't exist...
> 
> yes.

IIUC, something along these lines:

diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 172c6a05..e10a388 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -34,6 +34,7 @@ static unsigned long twd_timer_rate;
 static DEFINE_PER_CPU(bool, percpu_setup_called);
 
 static struct clock_event_device __percpu *twd_evt;
+static int feat_c3stop;
 static int twd_ppi;
 
 static void twd_set_mode(enum clock_event_mode mode,
@@ -294,7 +295,7 @@ static void twd_timer_setup(void)
 
 	clk->name = "local_timer";
 	clk->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT |
-			CLOCK_EVT_FEAT_C3STOP;
+			feat_c3stop;
 	clk->rating = 350;
 	clk->set_mode = twd_set_mode;
 	clk->set_next_event = twd_set_next_event;
@@ -346,6 +347,8 @@ static int __init twd_local_timer_common_register(struct device_node *np)
 		goto out_irq;
 
 	twd_get_clock(np);
+	if (!of_property_read_bool(np, "twd_never_stops"))
+		feat_c3stop = CLOCK_EVT_FEAT_C3STOP;
 
 	/*
 	 * Immediately configure the timer on the boot CPU, unless we need


>> Russell, when you added the FEAT_C3STOP flag unconditionally in
>> commit 5388a6b266, didn't that potentially break platforms that
>> didn't expect the flag to be set?
> 
> To take a step back, you should first figure out whether clearing
> this flag is actually the correct behavior for your hardware, or
> just happens to work by accident.

According to my (limited) understanding of the clockevents core,
a "broadcast device" is required if and only if the local timers
have CLOCK_EVT_FEAT_C3STOP. I could be wrong.

Additional reference:
https://lwn.net/Articles/574962/

Regards.

  reply	other threads:[~2015-05-21 12:35 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-12 14:32 schedule_timeout sleeps too long after dividing CPU frequency Mason
2015-05-12 14:46 ` Viresh Kumar
2015-05-12 15:14   ` Mason
2015-05-12 15:50     ` Russell King - ARM Linux
2015-05-12 16:14       ` Mason
2015-05-13 16:51       ` Mason
2015-05-14  2:13         ` Viresh Kumar
2015-05-14 11:22           ` Mason
2015-05-14 11:54             ` Viresh Kumar
2015-05-14 13:06               ` Mason
2015-05-14 13:53                 ` Russell King - ARM Linux
2015-05-14 14:51                   ` Mason
2015-05-14 13:59                 ` Viresh Kumar
2015-05-14 14:38                   ` Viresh Kumar
2015-05-14 14:42                   ` Russell King - ARM Linux
2015-05-15  9:29                     ` Mason
2015-05-15  9:51                       ` Russell King - ARM Linux
2015-05-15 10:01                         ` Viresh Kumar
2015-05-15 10:36                         ` Mason
2015-05-15 11:58                           ` Russell King - ARM Linux
2015-05-15 12:45                             ` Mason
2015-05-15 13:15                               ` Russell King - ARM Linux
2015-05-15 13:58                                 ` Mason
2015-05-15 18:35                                   ` Mason
2015-05-18 11:24                                     ` Mason
2015-05-18 11:54                                       ` Russell King - ARM Linux
2015-05-20 16:21                                         ` Mason
2015-05-20 18:50                                           ` Arnd Bergmann
2015-05-20 19:34                                             ` Mason
2015-05-20 20:14                                               ` Russell King - ARM Linux
2015-05-20 20:41                                                 ` Mason
2015-05-20 20:52                                                   ` Arnd Bergmann
2015-05-20 21:56                                                     ` Mason
2015-05-20 22:18                                                       ` Arnd Bergmann
2015-05-21 12:35                                                         ` Mason [this message]
2015-05-20 23:14                                                       ` Russell King - ARM Linux
2015-05-21  9:56                                                         ` Mason
2015-05-21 10:20                                                           ` Russell King - ARM Linux
2015-05-14 14:48                   ` Mason
2015-05-15  4:16                     ` Viresh Kumar
2015-05-15  5:07                       ` Viresh Kumar
2015-05-15  9:00                       ` Russell King - ARM Linux
2015-05-15  9:21                       ` Mason
2015-05-15 10:11                       ` Mason
2015-05-12 15:23 ` Russell King - ARM Linux
2015-05-12 16:03   ` Mason

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=555DD11E.7080302@free.fr \
    --to=slash.tmp@free$(echo .)fr \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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