devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
Cc: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
	Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [RFC PATCH 0/5] ARM: introducing DT topology
Date: Wed, 18 Jan 2012 16:24:23 +0000	[thread overview]
Message-ID: <20120118162423.GK1068@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <1326897408-11204-1-git-send-email-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>

On Wed, Jan 18, 2012 at 02:36:43PM +0000, Lorenzo Pieralisi wrote:
> Current code in the kernel, in particular the boot sequence, hinges upon a
> sequential mapping of MPIDR values for cpus and related interrupt
> controller CPU interfaces to logical cpu indexing. 

I don't believe it does.  What it does rely upon is having cpu_logical_map()
correctly setup for the logical-to-hardware mapping - which, if it's
different, should be done in smp_init_cpus(), taking note that logical
CPU 0 is _always_ the boot CPU.  (That's a restriction caused by the
way suspend/resume unplugs all but the lowest numbered logical online
CPU.)

So, with the code today, there's nothing in the code which prevents this
from happening:

a) you boot on h/w CPU 1, which becomes logical CPU 0.
b) you boot h/w CPU 3 as logical CPU 1.
c) you boot h/w CPU 0 as logical CPU 2.
d) you boot h/w CPU 2 as logical CPU 3.

You just need to ensure that cpu_logical_map() contains the array
{1, 3, 0, 2} instead of the default (because we _have_ to have a
default) of {1, 0, 2, 3}.

> This hypothesis is not valid when the concept of cluster is introduced since
> the MPIDR cannot be represented as a single index and interrupt controller
> CPU interfaces might be wired with a numbering scheme following per-SoC
> design parameters which cannot be extrapolated easily through generic functions
> by the primary CPU.

So what you're saying is that the GIC CPU index may not be the CPU number
given by MPIDR?

> Furthermore, relying on the MPIDR to be wired according to real topology
> levels might turn out to be an unreliable solution, hence a SW
> representation is needed to override possibly incorrect MPIDR register
> values.

This sounds like you're saying that the contents of MPIDR might be buggy
sometime in the future?  Do we actually know of any situations where the
information in there is currently wrong (outside of the development lab)?
If not, it's not something we should cater for until it's actually happened,
and then the pain should be felt by those silly enough to allow the chip
to go out the door.

  parent reply	other threads:[~2012-01-18 16:24 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-18 14:36 [RFC PATCH 0/5] ARM: introducing DT topology Lorenzo Pieralisi
2012-01-18 14:36 ` [RFC PATCH 1/5] ARM: kernel: add device tree init map function Lorenzo Pieralisi
2012-01-18 14:36 ` [RFC PATCH 2/5] ARM: kernel: add cpu logical map DT init in setup_arch Lorenzo Pieralisi
2012-01-18 14:36 ` [RFC PATCH 3/5] ARM: kernel: add logical mappings look-up Lorenzo Pieralisi
2012-01-18 14:36 ` [RFC PATCH 4/5] ARM: gic: add cpuif topology description Lorenzo Pieralisi
     [not found]   ` <1326897408-11204-5-git-send-email-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
2012-01-18 15:54     ` Rob Herring
2012-01-18 17:17       ` Lorenzo Pieralisi
2012-01-18 14:36 ` [RFC PATCH 5/5] ARM: kernel: build CPU topology from DT Lorenzo Pieralisi
     [not found] ` <1326897408-11204-1-git-send-email-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
2012-01-18 15:38   ` [RFC PATCH 0/5] ARM: introducing DT topology Rob Herring
2012-01-18 16:12     ` Lorenzo Pieralisi
2012-01-18 16:24   ` Russell King - ARM Linux [this message]
2012-01-18 17:50     ` Lorenzo Pieralisi
     [not found]       ` <20120118175028.GD9691-7AyDDHkRsp3ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2012-01-18 18:04         ` Russell King - ARM Linux
2012-01-19 10:52           ` Lorenzo Pieralisi
2012-01-19 12:18           ` Catalin Marinas
     [not found]             ` <20120119121832.GD9268-5wv7dgnIgG8@public.gmane.org>
2012-01-19 12:23               ` Russell King - ARM Linux

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=20120118162423.GK1068@n2100.arm.linux.org.uk \
    --to=linux-lfz/pmaqli7xmaaqvzeohq@public.gmane.org \
    --cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org \
    --cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.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).