From: santosh.shilimkar@ti•com (Santosh Shilimkar)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCHv3 2/5] arm64: factor out spin-table boot method
Date: Wed, 14 Aug 2013 14:12:26 -0400 [thread overview]
Message-ID: <520BC88A.5080207@ti.com> (raw)
In-Reply-To: <1376497228-20543-3-git-send-email-mark.rutland@arm.com>
On Wednesday 14 August 2013 12:20 PM, Mark Rutland wrote:
> The arm64 kernel has an internal holding pen, which is necessary for
> some systems where we can't bring CPUs online individually and must hold
> multiple CPUs in a safe area until the kernel is able to handle them.
> The current SMP infrastructure for arm64 is closely coupled to this
> holding pen, and alternative boot methods must launch CPUs into the pen,
> where they sit before they are launched into the kernel proper.
>
> With PSCI (and possibly other future boot methods), we can bring CPUs
> online individually, and need not perform the secondary_holding_pen
> dance. Instead, this patch factors the holding pen management code out
> to the spin-table boot method code, as it is the only boot method
> requiring the pen.
>
> A new entry point for secondaries, secondary_entry is added for other
> boot methods to use, which bypasses the holding pen and its associated
> overhead when bringing CPUs online. The smp.pen.text section is also
> removed, as the pen can live in head.text without problem.
>
> The smp_operations structure is extended with two new functions,
> cpu_boot and cpu_postboot, for bringing a cpu into the kernel and
> performing any post-boot cleanup required by a bootmethod (e.g.
> resetting the secondary_holding_pen_release to INVALID_HWID).
> Documentation is added for smp_operations.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm•com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti•com>
> ---
[..]
> diff --git a/arch/arm64/kernel/smp_spin_table.c b/arch/arm64/kernel/smp_spin_table.c
> index 5fecffc..87af6bb 100644
> --- a/arch/arm64/kernel/smp_spin_table.c
> +++ b/arch/arm64/kernel/smp_spin_table.c
> @@ -16,13 +16,36 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +#include <linux/delay.h>
> #include <linux/init.h>
> #include <linux/of.h>
> #include <linux/smp.h>
>
> #include <asm/cacheflush.h>
> +#include <asm/cputype.h>
> +#include <asm/smp_plat.h>
> +
> +extern void secondary_holding_pen(void);
> +volatile unsigned long secondary_holding_pen_release = INVALID_HWID;
>
> static phys_addr_t cpu_release_addr[NR_CPUS];
> +static DEFINE_RAW_SPINLOCK(boot_lock);
> +
> +/*
> + * Write secondary_holding_pen_release in a way that is guaranteed to be
> + * visible to all observers, irrespective of whether they're taking part
> + * in coherency or not. This is necessary for the hotplug code to work
> + * reliably.
> + */
> +static void write_pen_release(u64 val)
> +{
> + void *start = (void *)&secondary_holding_pen_release;
> + unsigned long size = sizeof(secondary_holding_pen_release);
> +
> + secondary_holding_pen_release = val;
> + __flush_dcache_area(start, size);
> +}
> +
>
> static int smp_spin_table_cpu_init(struct device_node *dn, unsigned int cpu)
> {
> @@ -59,8 +82,60 @@ static int smp_spin_table_cpu_prepare(unsigned int cpu)
> return 0;
> }
>
> +static int smp_spin_table_cpu_boot(unsigned int cpu)
> +{
> + unsigned long timeout;
> +
> + /*
> + * Set synchronisation state between this boot processor
> + * and the secondary one
> + */
> + raw_spin_lock(&boot_lock);
> +
> + /*
> + * Update the pen release flag.
> + */
> + write_pen_release(cpu_logical_map(cpu));
> +
> + /*
> + * Send an event, causing the secondaries to read pen_release.
> + */
> + sev();
> +
> + timeout = jiffies + (1 * HZ);
> + while (time_before(jiffies, timeout)) {
> + if (secondary_holding_pen_release == INVALID_HWID)
> + break;
> + udelay(10);
> + }
> +
> + /*
> + * Now the secondary core is starting up let it run its
> + * calibrations, then wait for it to finish
> + */
> + raw_spin_unlock(&boot_lock);
> +
> + return secondary_holding_pen_release != INVALID_HWID ? -ENOSYS : 0;
> +}
> +
> +void smp_spin_table_cpu_postboot(void)
> +{
> + /*
> + * Let the primary processor know we're out of the pen.
> + */
> + write_pen_release(INVALID_HWID);
> +
> + /*
> + * Synchronise with the boot thread.
> + */
> + raw_spin_lock(&boot_lock);
> + raw_spin_unlock(&boot_lock);
> +}
> +
I was just wonderring whether we can absrtact the synchronization
further out of spin_table and psci method. At least the lock
synchronization is common and needed in both cases.
Other than patch looks fine to me.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti•com>
next prev parent reply other threads:[~2013-08-14 18:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-14 16:20 [PATCHv3 0/5] arm64: initial CPU hotplug support Mark Rutland
2013-08-14 16:20 ` [PATCHv3 1/5] arm64: reorganise smp_enable_ops Mark Rutland
2013-08-14 17:46 ` Nicolas Pitre
2013-08-14 18:01 ` Santosh Shilimkar
2013-08-14 16:20 ` [PATCHv3 2/5] arm64: factor out spin-table boot method Mark Rutland
2013-08-14 17:51 ` Nicolas Pitre
2013-08-30 13:44 ` Catalin Marinas
2013-08-14 18:12 ` Santosh Shilimkar [this message]
2013-08-14 18:21 ` Nicolas Pitre
2013-08-14 19:17 ` Santosh Shilimkar
2013-08-14 19:21 ` Olof Johansson
2013-08-14 20:20 ` Nicolas Pitre
2013-08-14 16:20 ` [PATCHv3 3/5] arm64: read enable-method for CPU0 Mark Rutland
2013-08-14 17:51 ` Nicolas Pitre
2013-08-14 18:15 ` Santosh Shilimkar
2013-08-14 18:22 ` Nicolas Pitre
2013-08-14 19:02 ` Santosh Shilimkar
2013-08-14 16:20 ` [PATCHv3 4/5] arm64: add CPU_HOTPLUG infrastructure Mark Rutland
2013-08-14 17:53 ` Nicolas Pitre
2013-08-14 19:24 ` Santosh Shilimkar
2013-08-14 16:20 ` [PATCHv3 5/5] arm64: add PSCI CPU_OFF-based hotplug support Mark Rutland
2013-08-14 17:54 ` Nicolas Pitre
2013-08-14 18:05 ` [PATCHv3 0/5] arm64: initial CPU " Nicolas Pitre
2013-08-30 16:39 ` Catalin Marinas
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=520BC88A.5080207@ti.com \
--to=santosh.shilimkar@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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