From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 10/20] ARM64 / ACPI: Enumerate possible/present CPU set and map logical cpu id to APIC id
Date: Wed, 22 Jan 2014 15:53:31 +0000 [thread overview]
Message-ID: <20140122155331.GD24288@e102568-lin.cambridge.arm.com> (raw)
In-Reply-To: <1389961514-13562-11-git-send-email-hanjun.guo@linaro.org>
On Fri, Jan 17, 2014 at 12:25:04PM +0000, Hanjun Guo wrote:
[...]
> +/* map logic cpu id to physical GIC id */
> +extern int arm_cpu_to_apicid[NR_CPUS];
> +#define cpu_physical_id(cpu) arm_cpu_to_apicid[cpu]
Sudeep already commented on this, please update it accordingly.
> +
> #else /* !CONFIG_ACPI */
> #define acpi_disabled 1 /* ACPI sometimes enabled on ARM */
> #define acpi_noirq 1 /* ACPI sometimes enabled on ARM */
> diff --git a/drivers/acpi/plat/arm-core.c b/drivers/acpi/plat/arm-core.c
> index 8ba3e6f..1d9b789 100644
> --- a/drivers/acpi/plat/arm-core.c
> +++ b/drivers/acpi/plat/arm-core.c
> @@ -31,6 +31,7 @@
> #include <linux/smp.h>
>
> #include <asm/pgtable.h>
> +#include <asm/cputype.h>
>
> /*
> * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
> @@ -52,6 +53,13 @@ EXPORT_SYMBOL(acpi_pci_disabled);
> */
> static u64 acpi_lapic_addr __initdata;
Is this variable actually needed ?
>
> +/* available_cpus here means enabled cpu in MADT */
> +static int available_cpus;
Ditto.
> +
> +/* Map logic cpu id to physical GIC id (physical CPU id). */
> +int arm_cpu_to_apicid[NR_CPUS] = { [0 ... NR_CPUS-1] = -1 };
> +static int boot_cpu_apic_id = -1;
Do we need all these variables ? I think we should reuse cpu_logical_map
data structures for that, it looks suspiciously familiar.
> #define BAD_MADT_ENTRY(entry, end) ( \
> (!entry) || (unsigned long)entry + sizeof(*entry) > end || \
> ((struct acpi_subtable_header *)entry)->length < sizeof(*entry))
> @@ -132,6 +140,55 @@ static int __init acpi_parse_madt(struct acpi_table_header *table)
> * Please refer to chapter5.2.12.14/15 of ACPI 5.0
> */
>
> +/**
> + * acpi_register_gic_cpu_interface - register a gic cpu interface and
> + * generates a logic cpu number
> + * @id: gic cpu interface id to register
> + * @enabled: this cpu is enabled or not
> + *
> + * Returns the logic cpu number which maps to the gic cpu interface
> + */
> +static int acpi_register_gic_cpu_interface(int id, u8 enabled)
> +{
> + int cpu;
> +
> + if (id >= MAX_GIC_CPU_INTERFACE) {
> + pr_info(PREFIX "skipped apicid that is too big\n");
> + return -EINVAL;
> + }
> +
> + total_cpus++;
> + if (!enabled)
> + return -EINVAL;
> +
> + if (available_cpus >= NR_CPUS) {
> + pr_warn(PREFIX "NR_CPUS limit of %d reached,"
> + " Processor %d/0x%x ignored.\n", NR_CPUS, total_cpus, id);
> + return -EINVAL;
> + }
Hmm...what if you are missing the boot CPU ? It is a worthy check.
Have a look at smp_init_cpus(), it does not bail out on cpu>= NR_CPUS
because you do want to make sure that the DT contains the boot CPU
node. Same logic applies.
> +
> + available_cpus++;
> +
Is available_cpus != num_possible_cpus() ? It does not look like hence
available_cpus can go.
> + /* allocate a logic cpu id for the new comer */
> + if (boot_cpu_apic_id == id) {
> + /*
> + * boot_cpu_init() already hold bit 0 in cpu_present_mask
> + * for BSP, no need to allocte again.
> + */
> + cpu = 0;
> + } else {
> + cpu = cpumask_next_zero(-1, cpu_present_mask);
> + }
> +
> + /* map the logic cpu id to APIC id */
> + arm_cpu_to_apicid[cpu] = id;
> +
> + set_cpu_present(cpu, true);
> + set_cpu_possible(cpu, true);
This is getting nasty. Before adding this patch and previous ones we
need to put in place a method for the kernel to make a definite choice between
ACPI and DT and stick to that. We can't initialize the logical map twice
(which will happen if your DT has valid cpu nodes and a chosen node pointing
to proper ACPI tables) or even having some entries initialized from DT and
others by ACPI. It is a big fat no-no, please update the series accordingly.
> +
> + return cpu;
> +}
> +
> static int __init
> acpi_parse_gic(struct acpi_subtable_header *header, const unsigned long end)
> {
> @@ -144,6 +201,16 @@ acpi_parse_gic(struct acpi_subtable_header *header, const unsigned long end)
>
> acpi_table_print_madt_entry(header);
>
> + /*
> + * We need to register disabled CPU as well to permit
> + * counting disabled CPUs. This allows us to size
> + * cpus_possible_map more accurately, to permit
> + * to not preallocating memory for all NR_CPUS
> + * when we use CPU hotplug.
> + */
> + acpi_register_gic_cpu_interface(processor->gic_id,
> + processor->flags & ACPI_MADT_ENABLED);
> +
> return 0;
> }
>
> @@ -186,6 +253,19 @@ static int __init acpi_parse_madt_gic_entries(void)
> return count;
> }
>
> +#ifdef CONFIG_SMP
> + if (available_cpus == 0) {
> + pr_info(PREFIX "Found 0 CPUs; assuming 1\n");
> + arm_cpu_to_apicid[available_cpus] =
> + read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> + available_cpus = 1; /* We've got at least one of these */
> + }
I'd rather check the MADT for at least the boot cpu to present, if it is
not ACPI tables are horribly buggy and the kernel should barf on that.
> +#endif
> +
> + /* Make boot-up look pretty */
> + pr_info("%d CPUs available, %d CPUs total\n", available_cpus,
> + total_cpus);
Ok, now, how can we use the "disabled" CPUs == (total_cpus - available_cpus) ?
Are we keeping track of them in the kernel at all ? It does not look
like, so I wonder whether we need this bit of info. I do not see why it
is pretty to know that there are disabled, aka unusable CPUs.
> return 0;
> }
>
> @@ -321,6 +401,9 @@ int __init early_acpi_boot_init(void)
> if (acpi_disabled)
> return -ENODEV;
>
> + /* Get the boot CPU's GIC cpu interface id before MADT parsing */
> + boot_cpu_apic_id = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
See Sudeep's comment.
Thanks,
Lorenzo
next prev parent reply other threads:[~2014-01-22 15:53 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-17 12:24 [PATCH 00/20] Make ACPI core running on ARM64 Hanjun Guo
2014-01-17 12:24 ` [PATCH 01/20] ARM64 / ACPI: Make PCI optional for ACPI " Hanjun Guo
2014-01-17 16:00 ` Bjorn Helgaas
2014-01-20 9:33 ` Hanjun Guo
2014-01-17 12:24 ` [PATCH 02/20] ARM64 : Add dummy asm/cpu.h Hanjun Guo
2014-01-17 14:22 ` Sudeep Holla
2014-01-20 8:58 ` Hanjun Guo
2014-01-23 16:15 ` Catalin Marinas
2014-01-24 14:41 ` Hanjun Guo
2014-01-17 12:24 ` [PATCH 03/20] ARM64 / ACPI: Introduce the skeleton of _PDC related for ARM64 Hanjun Guo
2014-01-17 14:25 ` Sudeep Holla
2014-01-20 9:20 ` Hanjun Guo
2014-01-23 16:19 ` Catalin Marinas
2014-01-24 14:43 ` Hanjun Guo
2014-01-23 18:03 ` Catalin Marinas
2014-01-24 15:35 ` Hanjun Guo
2014-01-17 12:24 ` [PATCH 04/20] ARM64 / ACPI: Introduce arm_core.c and its related head file Hanjun Guo
2014-01-17 14:12 ` Will Deacon
2014-01-18 4:05 ` Hanjun Guo
2014-01-17 16:56 ` Sudeep Holla
2014-01-20 12:26 ` Hanjun Guo
2014-01-22 11:54 ` Lorenzo Pieralisi
2014-01-23 15:56 ` [Linaro-acpi] " Tomasz Nowicki
2014-01-24 9:09 ` Hanjun Guo
2014-01-24 12:53 ` Lorenzo Pieralisi
2014-01-24 16:44 ` Tomasz Nowicki
2014-01-17 12:24 ` [PATCH 05/20] ARM64 / ACPI: Introduce lowlevel suspend function Hanjun Guo
2014-01-17 12:25 ` [PATCH 06/20] ARM64 / ACPI: Introduce some PCI functions when PCI is enabled Hanjun Guo
2014-01-17 14:04 ` Arnd Bergmann
2014-01-20 8:08 ` Hanjun Guo
2014-01-20 8:20 ` Arnd Bergmann
2014-01-20 14:13 ` Hanjun Guo
2014-01-20 18:39 ` Arnd Bergmann
2014-01-21 3:40 ` Hanjun Guo
2014-01-17 12:25 ` [PATCH 07/20] ARM64 / ACPI: Enable ARM64 in Kconfig Hanjun Guo
2014-01-17 14:34 ` Sudeep Holla
2014-01-20 9:30 ` Hanjun Guo
2014-01-23 16:39 ` Catalin Marinas
2014-01-24 14:45 ` Hanjun Guo
2014-01-17 12:25 ` [PATCH 08/20] ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64 Hanjun Guo
2014-01-17 12:25 ` [PATCH 09/20] ARM64 / ACPI: Implement core functions for parsing MADT table Hanjun Guo
2014-01-17 14:12 ` Arnd Bergmann
2014-01-20 8:49 ` Hanjun Guo
2014-01-23 17:54 ` Marc Zyngier
2014-01-24 15:34 ` Hanjun Guo
2014-01-24 20:57 ` Arnd Bergmann
2014-01-17 12:25 ` [PATCH 10/20] ARM64 / ACPI: Enumerate possible/present CPU set and map logical cpu id to APIC id Hanjun Guo
2014-01-17 17:37 ` Sudeep Holla
2014-01-20 14:00 ` Hanjun Guo
2014-01-22 15:53 ` Lorenzo Pieralisi [this message]
2014-01-24 14:37 ` Hanjun Guo
2014-01-24 15:35 ` Lorenzo Pieralisi
2014-01-24 16:02 ` Hanjun Guo
2014-01-17 12:25 ` [PATCH 11/20] ARM64 / ACPI: Get the enable method for SMP initialization Hanjun Guo
2014-01-23 17:50 ` Catalin Marinas
2014-01-24 14:57 ` Hanjun Guo
2014-01-17 12:25 ` [PATCH 12/20] ARM64 / ACPI: Use Parked Address in GIC structure for spin table SMP initialisation Hanjun Guo
2014-01-17 14:15 ` Arnd Bergmann
2014-01-17 14:35 ` Tomasz Nowicki
2014-01-17 12:25 ` [PATCH 13/20] ARM64 / ACPI: Define ACPI_IRQ_MODEL_GIC needed for arm Hanjun Guo
2014-01-17 12:25 ` [PATCH 14/20] Irqchip / gic: Set as default domain so we can access from ACPI Hanjun Guo
2014-01-17 12:25 ` [PATCH 15/20] ACPI / ARM64: Update acpi_register_gsi to register with the core IRQ subsystem Hanjun Guo
2014-01-17 12:25 ` [PATCH 17/20] clocksource / arch_timer: Use ACPI GTDT table to initialize arch timer Hanjun Guo
2014-01-27 11:26 ` Mark Rutland
2014-01-17 12:25 ` [PATCH 18/20] clocksource / acpi: Add macro CLOCKSOURCE_ACPI_DECLARE Hanjun Guo
2014-01-17 14:21 ` Arnd Bergmann
2014-01-20 9:08 ` Hanjun Guo
2014-01-22 11:46 ` Mark Rutland
2014-01-22 14:56 ` Arnd Bergmann
2014-01-22 15:17 ` Mark Rutland
2014-01-22 15:47 ` Arnd Bergmann
2014-01-24 9:19 ` Hanjun Guo
2014-01-24 0:46 ` Hanjun Guo
2014-01-22 8:26 ` Linus Walleij
2014-01-22 11:45 ` Mark Rutland
2014-01-22 14:38 ` Linus Walleij
2014-01-24 0:20 ` Hanjun Guo
2014-01-24 12:08 ` Mark Rutland
2014-01-24 15:15 ` Catalin Marinas
2014-01-24 15:44 ` Mark Rutland
2014-01-24 15:53 ` Hanjun Guo
2014-01-24 0:12 ` Hanjun Guo
2014-01-24 12:32 ` Mark Rutland
2014-01-24 15:45 ` Hanjun Guo
2014-01-17 12:25 ` [PATCH 19/20] clocksource / ACPI: Introduce clocksource_acpi_init() using CLOCKSOURCE_ACPI_DECLARE Hanjun Guo
2014-01-17 12:25 ` [PATCH 20/20] ARM64 / clocksource: Use clocksource_acpi_init() Hanjun Guo
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=20140122155331.GD24288@e102568-lin.cambridge.arm.com \
--to=lorenzo.pieralisi@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).