All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/6] ARM: smp: set thread_info->cpu to hardware CPU number for boot thread
Date: Mon, 8 Aug 2011 21:25:52 +0100	[thread overview]
Message-ID: <20110808202551.GA10666@e102144-lin.cambridge.arm.com> (raw)
In-Reply-To: <20110808200256.GE19367@n2100.arm.linux.org.uk>

Hi Russell,

On Mon, Aug 08, 2011 at 09:02:56PM +0100, Russell King - ARM Linux wrote:
> On Mon, Aug 08, 2011 at 07:14:59PM +0100, Will Deacon wrote:
> > Can be. I just followed suit with secondary_start_kernel, but smp.c doesn't
> > seem to be consistent anyway so I'll add the specifier.
> 
> Actually, it's probably much better to keep logical CPU0 as the boot CPU.
> The hotplug code makes the assumption that the lowest online CPU number
> is the boot CPU.

Yes, you're right. I only tested this on a dual-core platform so I didn't
get a chance to play with hotplug (except to see that it failed, like I
expected). That assumption is also in the generic code so I guess it's
easier to leave it be.

> So unless we want even more pain, I suggest we just ensure logical CPU0
> is the boot CPU.

Right. Ensuring the logical CPU number isn't too hard, but we should aim to
support an arbitrary physical CPU number for the boot ID, even if most
platforms can't cater for that at the moment.

> We're already fairly clean on our interactions between CPU numbering and
> the hardware CPU numbering - there's only a limited number of places where
> the two interact.  Those are the GIC, IPI, secondary CPU bringup, and
> hotplug code.  I suggest that we preserve the independence, and introduce
> a mapping between logical CPU numbering and hardware CPU numbering.

This was my initial approach but then I thought I'd try and cheat my messing
with the logical numbering. I'll look at implementing the mapping and then
updating the GIC and friends to indirect their CPU number lookups through
that instead. I'll post it as its own series since it will be more than just
a simple hack now.

Stay tuned...

Cheers,

Will

  reply	other threads:[~2011-08-08 20:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-08 17:10 [PATCH 0/6] Miscellaneous patches for 3.1 and 3.2 Will Deacon
2011-08-08 17:10 ` [PATCH 1/6] ARM: vexpress: determine active tile site before reading tile ID Will Deacon
2011-08-08 17:10 ` [PATCH 2/6] ARM: realview: ensure visibility of writes during reset Will Deacon
2011-08-08 21:16   ` Rob Herring
2011-08-09  8:32     ` Will Deacon
2011-08-08 17:10 ` [PATCH 3/6] ARM: twd: register clockevents device before enabling PPI Will Deacon
2011-08-08 18:19   ` Marc Zyngier
2011-08-08 17:10 ` [PATCH 4/6] ARM: smp: set thread_info->cpu to hardware CPU number for boot thread Will Deacon
2011-08-08 17:33   ` Stephen Boyd
2011-08-08 18:14     ` Will Deacon
2011-08-08 20:02       ` Russell King - ARM Linux
2011-08-08 20:25         ` Will Deacon [this message]
2011-08-09 11:48   ` Sergei Shtylyov
2011-08-09 12:13     ` Will Deacon
2011-08-08 17:10 ` [PATCH 5/6] ARM: cache: detect VIPT aliasing I-cache on ARMv6 Will Deacon
2011-08-08 17:10 ` [PATCH 6/6] ARM: cache: detect PIPT I-cache using CTR Will Deacon

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=20110808202551.GA10666@e102144-lin.cambridge.arm.com \
    --to=will.deacon@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 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.