linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	John Stultz <john.stultz@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Santosh Shilimkar <santosh.shilimkar@ti.com>
Subject: Re: [PATCHv3 01/10] clocksource: add generic dummy timer driver
Date: Thu, 04 Apr 2013 18:46:25 -0700	[thread overview]
Message-ID: <515E2CF1.6030709@codeaurora.org> (raw)
In-Reply-To: <20130326112811.GD4065@e106331-lin.cambridge.arm.com>

On 03/26/13 04:28, Mark Rutland wrote:
> On Tue, Mar 26, 2013 at 02:14:53AM +0000, Stephen Boyd wrote:
>> Ok. Thanks for clearing up my confusion.
>>
>> Like you say, increasing the dummy timer rating seems like a hack. But
>> it also sounds like you want to keep the dummy timer driver fully self
>> contained. I'm not opposed to calling dummy_timer_register() at the
>> bottom of tick_init() if we have to, but it sounds like you don't like that.
> I'd like to keep the dummy timer driver self-contained if we can, but if it
> makes it more robust and/or easier to deal with by having an external call to
> register the driver, then I'm not opposed to that.
>
>> An alternative would be to push the dummy timer logic into the core
>> clockevents layer under the ifdef for arch has broadcast. This is
>> probably the correct approach because most devices don't want to have a
>> dummy timer sitting around unused. I might be able to take a look at
>> this tomorrow.
> I'm also not opposed to this idea.

What if we only check the rating if the two devices are for the same
CPU, i.e. always prefer percpu devices over global ones? This would make
your dummy timers into tick devices.

diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index b1600a6..9ea59b9 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -251,9 +251,10 @@ static int tick_check_new_device(struct clock_event_device *newdev)
                    !(newdev->features & CLOCK_EVT_FEAT_ONESHOT))
                        goto out_bc;
                /*
-                * Check the rating
+                * Check the rating, but prefer CPU local devices
                 */
-               if (curdev->rating >= newdev->rating)
+               if (curdev->rating >= newdev->rating &&
+                   cpumask_equal(curdev->cpumask, newdev->cpumask))
                        goto out_bc;
        }
 

I think it will work with smp_twd, sp804, and dummy timers registered in
any order too.

> Though "broadcasting" to the same cpu is special-cased in tick_do_broadcast,
> which will call the tick device's event_handler directly rather than having the
> cpu attempt to IPI to itself.
>
> As you suggest, tick_switch_to_oneshot does complain:
>
> Clockevents: could not switch to one-shot mode: dummy_timer is not functional.
> Could not switch to high resolution mode on CPU 0
>
> To handle this case we could check cpu_possible_mask when initialising the
> dummy and only register it if more than 1 cpu is possible. That would be
> roughly in line with how we handle this case in smp.c.

Yes, this will work well enough. Squashed it into this patch.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  reply	other threads:[~2013-04-05  1:46 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-13 18:17 [PATCHv3 00/10] Remove ARM local timer API Stephen Boyd
2013-03-13 18:17 ` [PATCHv3 01/10] clocksource: add generic dummy timer driver Stephen Boyd
2013-03-21 18:09   ` Mark Rutland
2013-03-21 18:13     ` Stephen Boyd
2013-03-22 18:03       ` Mark Rutland
2013-03-25 16:49         ` Stephen Boyd
2013-03-25 18:00           ` Mark Rutland
2013-03-25 20:47             ` Thomas Gleixner
2013-03-26 15:26               ` Mark Rutland
2013-03-26  2:14             ` Stephen Boyd
2013-03-26 11:28               ` Mark Rutland
2013-04-05  1:46                 ` Stephen Boyd [this message]
2013-03-13 18:17 ` [PATCHv3 02/10] ARM: smp: Remove duplicate dummy timer implementation Stephen Boyd
2013-03-13 18:17 ` [PATCHv3 03/10] ARM: smp_twd: Divorce smp_twd from local timer API Stephen Boyd
2013-03-28 15:22   ` Mark Rutland
2013-03-28 20:09     ` Stephen Boyd
2013-04-02  8:41       ` Mark Rutland
2013-03-13 18:17 ` [PATCHv3 04/10] ARM: OMAP2+: Divorce " Stephen Boyd
2013-03-13 18:17 ` [PATCHv3 05/10] ARM: EXYNOS4: Divorce mct " Stephen Boyd
2013-03-13 18:17 ` [PATCHv3 06/10] ARM: PRIMA2: Divorce timer-marco " Stephen Boyd
2013-03-13 18:17 ` [PATCHv3 07/10] ARM: msm: Divorce msm_timer " Stephen Boyd
2013-03-13 18:17 ` [PATCHv3 08/10] clocksource: time-armada-370-xp: Fix sparse warning Stephen Boyd
2013-03-20 17:06   ` Gregory CLEMENT
2013-03-13 18:17 ` [PATCHv3 09/10] clocksource: time-armada-370-xp: Divorce from local timer API Stephen Boyd
2013-03-20 17:09   ` Gregory CLEMENT
2013-03-20 17:20     ` Stephen Boyd
2013-03-20 17:26       ` Gregory CLEMENT
2013-03-20 17:44         ` Gregory CLEMENT
2013-03-20 18:00           ` Stephen Boyd
2013-03-20 17:21     ` Gregory CLEMENT
2013-03-13 18:17 ` [PATCHv3 10/10] ARM: smp: Remove " Stephen Boyd

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=515E2CF1.6030709@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=john.stultz@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=santosh.shilimkar@ti.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;
as well as URLs for NNTP newsgroup(s).