linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v4 09/13] ARM: msm: use remapped PPI interrupts for local	timer
Date: Sat, 28 May 2011 12:58:07 +0200	[thread overview]
Message-ID: <1a1e2af761ca29d8e75c9149274ced5f@localhost> (raw)
In-Reply-To: <4DDFFBC9.30002@codeaurora.org>


On Fri, 27 May 2011 12:30:17 -0700, Stephen Boyd <sboyd@codeaurora.org>
wrote:
> On 05/27/2011 09:27 AM, Marc Zyngier wrote:
>> Use the normal interrupt scheme for the local timers by using
>> a remapped PPI interrupt.
>>
>> MSM already had a very similar scheme, though still mixing both
>> GIC-specific and generic APIs.
>>
>> Fixes and ideas courtesy of Stephen Boyd.
>>
>> Cc: David Brown <davidb@codeaurora.org>
>> Cc: Daniel Walker <dwalker@fifo99.com>
>> Cc: Bryan Huntsman <bryanh@codeaurora.org>
> 
> Reviewed-and-Tested-by: Stephen Boyd <sboyd@codeaurora.org>

Thanks Stephen.

>>  
>> +static bool local_timer_inited;
> 
> Except this is unused if SMP=n. Here's a fix:

Thanks, will apply.

> ---8<----
> 
> diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
> index 186abdf..a242b89 100644
> --- a/arch/arm/mach-msm/timer.c
> +++ b/arch/arm/mach-msm/timer.c
> @@ -84,7 +84,6 @@ enum {
>  
>  
>  static struct msm_clock msm_clocks[];
> -static bool local_timer_inited;
>  
>  static irqreturn_t msm_timer_interrupt(int irq, void *dev_id)
>  {
> @@ -259,6 +258,7 @@ int __cpuinit local_timer_setup(struct
> clock_event_device *evt)
>  {
>         struct msm_clock *clock = &msm_clocks[MSM_GLOBAL_TIMER];
>         int res;
> +       static bool local_timer_inited;
>  
>         /* Use existing clock_event for cpu 0 */
>         if (!smp_processor_id())
> 
> 
> 
> ---
> 
> But now I really want to know. Why can't we use system_state ==
> SYSTEM_BOOTING? Perhaps I'm thinking ahead too much, but I'm concerned

I thought of that. Except that system_state is really what it means, an
indication of the state of the system as a whole. On startup, memory
allocation can hardly fail, even when in atomic context. On cpu hotplug,
anything can fail (as far as memory allocation is concerned).

> that if we have more than two cores we're going to have to make a percpu
> variable here just to avoid requesting the irq again. It would be
> simpler to just accept the fact that we can't boot a secondary core for
> the first time after kernel init due to the way the code is written.
> If/when we decide to allow such a thing we can revisit this code and
> make it into a percpu variable.

This is actually what I've done for TWD. And frankly, I hate it.

> Or another idea is to pass a "first_boot" flag or something to
> local_timer_setup() to indicate this is the first boot. Then we could
> extend the percpu_clockevent variable in the localtimer core to have
> this flag.
> 
> Either way it seems like something we should centralize.

Agreed. If this patch series goes in, I plan to keep track of the state at
the core level. Or at least as a generic feature of the ARM implementation
(I already have a bunch of patches to go on top of this). There are other
code paths that may need to may need to track this as well (I have a pair
of ugly hacks in the A15 code...).

Cheers,

        M.
-- 
Fast, cheap, reliable. Pick two.

  reply	other threads:[~2011-05-28 10:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-27 16:27 [RFC PATCH v4 00/13] Consolidating GIC per-cpu interrupts Marc Zyngier
2011-05-27 16:27 ` [RFC PATCH v4 01/13] ARM: gic: add per-cpu interrupt multiplexer Marc Zyngier
2011-05-27 19:30   ` Stephen Boyd
2011-05-27 16:27 ` [RFC PATCH v4 02/13] ARM: smp: add interrupt handler for local timers Marc Zyngier
2011-05-27 16:27 ` [RFC PATCH v4 03/13] ARM: smp_twd: add support for remapped PPI interrupts Marc Zyngier
2011-05-27 16:27 ` [RFC PATCH v4 04/13] ARM: omap4: use remapped PPI interrupts for local timer Marc Zyngier
2011-05-27 16:27 ` [RFC PATCH v4 05/13] ARM: versatile: " Marc Zyngier
2011-05-27 16:27 ` [RFC PATCH v4 06/13] ARM: shmobile: " Marc Zyngier
2011-05-27 16:27 ` [RFC PATCH v4 07/13] ARM: ux500: " Marc Zyngier
2011-05-27 16:27 ` [RFC PATCH v4 08/13] ARM: tegra: " Marc Zyngier
2011-05-27 16:27 ` [RFC PATCH v4 09/13] ARM: msm: " Marc Zyngier
2011-05-27 19:30   ` Stephen Boyd
2011-05-28 10:58     ` Marc Zyngier [this message]
2011-05-27 16:27 ` [RFC PATCH v4 10/13] ARM: exynos4: " Marc Zyngier
2011-05-27 16:27 ` [RFC PATCH v4 11/13] ARM: gic: remove previous local timer interrupt handling Marc Zyngier
2011-05-27 19:30   ` Stephen Boyd
2011-05-30  8:08     ` Marc Zyngier
2011-05-30  8:25       ` Marc Zyngier
2011-05-30  9:12         ` Stephen Boyd
2011-05-27 16:27 ` [RFC PATCH v4 12/13] ARM: gic: add compute_irqnr macro for exynos4 Marc Zyngier
2011-05-27 16:27 ` [RFC PATCH v4 13/13] ARM: SMP: automatically select ARM_GIC_VPPI Marc Zyngier

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=1a1e2af761ca29d8e75c9149274ced5f@localhost \
    --to=marc.zyngier@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).