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: Mon, 25 Mar 2013 19:14:53 -0700	[thread overview]
Message-ID: <5151049D.5040400@codeaurora.org> (raw)
In-Reply-To: <20130325180007.GA4065@e106331-lin.cambridge.arm.com>

On 03/25/13 11:00, Mark Rutland wrote:
>
>>> I've spent the last few hours trying to get the dummy_timer driver working on
>>> tc2 with the sp804 as the broadcast source (with architected timer support
>>> disabled). It turns out that having dummy timer's rating so low means that it
>>> won't be selected as the tick device on cpu0 in preference to the sp804, and
>>> thus won't push the sp804 out of that spot (allowing it to become the broadcast
>>> source). This leads to boot stalling.
>> I'm not following here. Why would we want to remove sp804 from the tick
>> duty?
> To run an SMP system without local timers, we need the sp804 to be the
> broadcast timer. Unfortunately the tick device and broadcast timer are mutually
> exclusive positions, so we need to have a dummy timer knock the sp804 out of
> tick device duty to enable broadcast.
>
> When the dummy timer's rating was 400 (against the sp804's 350), this worked.
> The sp804 would be registered, and would become cpu0's tick device. Later the
> dummy would get registered, knocking the sp804 out (whereupon it would get
> cycled back through tick_check_new_device and become the broadcast timer).
>
> With the dummy timer's rating lower, the sp804 stays as cpu0's tick device, all
> other cpus get dummy timers, but there's no broadcast source, so the system
> locks up waiting for secondary cpus.

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.

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.

One final question, if you remove all other CPUs besides the CPU that is
servicing the sp804 interrupt do we end up in a situation where the
sp804 is broadcasting to the dummy tick device? I haven't read through
all the code yet for that one. I would think tick_switch_to_oneshot()
would complain on your device?

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

  parent reply	other threads:[~2013-03-26  2:14 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 [this message]
2013-03-26 11:28               ` Mark Rutland
2013-04-05  1:46                 ` Stephen Boyd
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=5151049D.5040400@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).