linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/4] CPU hotplug support for Versatile platforms
Date: Wed, 22 Sep 2010 18:45:15 +0100	[thread overview]
Message-ID: <006001cb5a7d$eaa69a70$bff3cf50$@deacon@arm.com> (raw)
In-Reply-To: <4C9527FA.2030803@gmail.com>

Hi Rob,

> On 09/17/2010 06:01 PM, Russell King - ARM Linux wrote:
> > On Fri, Sep 17, 2010 at 04:21:42PM -0500, Rob Herring wrote:
> >> The platform specific SMP code is one area that prevents supporting a
> >> single kernel image. All the functions in platsmp.c need to be converted
> >> to function pointers and a lot of that code is pretty simliar across
> >> platforms. What's needed is a common platsmp.c with something like
> >> platform specific smp_ops like PowerPC. I think addressing that first
> >> would simplify this restructuring as you are doing some of what's
> >> needed, but you introducing new namespace problems like platform_cpu_*.
> >
> > The split between smp.c and platsmp.c is there to allow different SMP
> > implementations from the standard ARM Ltd SMP implementation (and there
> > will be different implementations.)
> >
> > Just because all the SMP implementations that are currently merged are
> > the standard ARM Ltd SMP implementation does not mean that we should
> > move stuff out of platsmp.c into the generic code.
> 
> Agreed, but the interface between smp.c and platsmp.c does not allow for
> more than one SMP platform in a single image. Granted, there are plenty
> of other obstacles to multi-platform kernel binaries, but this one would
> be good to address before there are a bunch of SMP platforns rather than
> after. Ideally, platsmp.c could be common, but optional for platforms
> that are significantly different.
> 
> The idea I have is add a smp_init function ptr to struct mdesc which
> would fill in an smp_ops struct of function pointers and call
> set_cpu_possible for each core. This would replace the direct
> smp_init_cpus call.

I think this is a separate patch. Whilst this sort of stuff is in the
back of my mind when doing BSP stuff, it's not the primary concern of
these patches. The platform_cpu_* namespace exists in the kernel already
and is not something I have introduced [see mach-realview/hotplug.c].

The main aim of these patches is to allow multiple variants (core tiles)
to exist for the versatile express without having to have separate machine
IDs.

Cheers,

Will

      reply	other threads:[~2010-09-22 17:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-17 13:12 [PATCH 0/4] CPU hotplug support for Versatile platforms Will Deacon
2010-09-17 13:12 ` [PATCH 1/4] ARM: vexpress: add support for multiple core tiles Will Deacon
2010-09-17 13:12 ` [PATCH 2/4] ARM: realview: fix CPU hotplug support for SMP platforms Will Deacon
2010-09-17 13:12 ` [PATCH 3/4] ARM: plat-versatile: factor out common hotplug code Will Deacon
2010-09-17 13:12 ` [PATCH 4/4] ARM: vexpress: add support for CPU hotplug to ct-ca9x4 tile Will Deacon
2010-09-17 21:21 ` [PATCH 0/4] CPU hotplug support for Versatile platforms Rob Herring
2010-09-17 23:01   ` Russell King - ARM Linux
2010-09-18 20:58     ` Rob Herring
2010-09-22 17:45       ` Will Deacon [this message]

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='006001cb5a7d$eaa69a70$bff3cf50$@deacon@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 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).