devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	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 09:38:54 -0600	[thread overview]
Message-ID: <4F16E78E.2060801@gmail.com> (raw)
In-Reply-To: <1326897408-11204-1-git-send-email-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>

On 01/18/2012 08:36 AM, Lorenzo Pieralisi wrote:
> The introduction of multi-cluster ARM systems in SoC designs requires the kernel
> to become cluster aware, so that it can be booted on every CPU in the system
> and it can build an appropriate representation of topology levels.
> 
> 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. 
> 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.
> 
> 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.
> 

"might be" is used several times. Is this a real problem? Wouldn't a
more simple solution be providing properties to override the MPIDR
register value if it is unreliable?

> Through the device tree and relative bindings, the kernel is provided
> with HW values for MPIDR registers, interrupt controller CPU interfaces and
> with a topology representation of hierarchy levels and connection between cores.
> 
> The device tree bindings allow to boot the Linux kernel on a multi-cluster
> system without relying on platform specific hook to identify the number of CPUs
> and interrupt controller wiring definition.
> 
> The patchset has been tested against:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-arm-arch.git master
> 
> to boot an 8-core dual-cluster system on every possible CPU and to describe
> the relative cpu topology according to the affinity levels.
> 
> Compile tested against linux-next, with a dependency on the following patch:
> 
> http://www.spinics.net/lists/arm-kernel/msg155873.html
> 
> Documentation of new device tree bindings is provided in the corresponding
> patches and provided for discussion.
> 
> Lorenzo Pieralisi (5):
>   ARM: kernel: add device tree init map function
>   ARM: kernel: add cpu logical map DT init in setup_arch
>   ARM: kernel: add logical mappings look-up
>   ARM: gic: add cpuif topology description
>   ARM: kernel: build CPU topology from DT
> 
>  Documentation/devicetree/bindings/arm/cpus.txt     |   42 +++++
>  Documentation/devicetree/bindings/arm/gic.txt      |   69 ++++++++
>  Documentation/devicetree/bindings/arm/topology.txt |  167 ++++++++++++++++++++
>  arch/arm/common/gic.c                              |   94 +++++++++++-
>  arch/arm/include/asm/prom.h                        |    2 +
>  arch/arm/include/asm/smp_plat.h                    |   12 ++
>  arch/arm/kernel/devtree.c                          |   40 +++++
>  arch/arm/kernel/setup.c                            |    1 +
>  arch/arm/kernel/topology.c                         |  110 +++++++++++---
>  9 files changed, 513 insertions(+), 24 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/cpus.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/topology.txt
> 

  parent reply	other threads:[~2012-01-18 15:38 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   ` Rob Herring [this message]
2012-01-18 16:12     ` [RFC PATCH 0/5] ARM: introducing DT topology Lorenzo Pieralisi
2012-01-18 16:24   ` Russell King - ARM Linux
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=4F16E78E.2060801@gmail.com \
    --to=robherring2-re5jqeeqqe8avxtiumwx3w@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=linux-lFZ/pmaqli7XmaaqVzeoHQ@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).