Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759470AbbBIGzZ (ORCPT ); Mon, 9 Feb 2015 01:55:25 -0500 Received: from foss-mx-na.foss.arm.com ([217.140.108.86]:42668 "EHLO foss-mx-na.foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753238AbbBIGzX (ORCPT ); Mon, 9 Feb 2015 01:55:23 -0500 Date: Mon, 9 Feb 2015 06:55:12 +0000 From: Will Deacon To: Hanjun Guo Cc: Catalin Marinas , "Rafael J. Wysocki" , Olof Johansson , Arnd Bergmann , Mark Rutland , "grant.likely@linaro.org" , Lorenzo Pieralisi , "graeme.gregory@linaro.org" , Sudeep Holla , "jcm@redhat.com" , Jason Cooper , Marc Zyngier , Bjorn Helgaas , Daniel Lezcano , Mark Brown , Rob Herring , Robert Richter , Randy Dunlap , Charles Garcia-Tobin , "phoenix.liyi@huawei.com" , Timur Tabi , Ashwin Chaugule , "suravee.suthikulpanit@amd.com" , Mark Langsdorf , "wangyijing@huawei.com" , "linux-acpi@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linaro-acpi@lists.linaro.org" Subject: Re: [PATCH v8 14/21] ACPI / processor: Make it possible to get CPU hardware ID via GICC Message-ID: <20150209065512.GK13969@arm.com> References: <1422881149-8177-1-git-send-email-hanjun.guo@linaro.org> <1422881149-8177-15-git-send-email-hanjun.guo@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1422881149-8177-15-git-send-email-hanjun.guo@linaro.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2773 Lines: 73 On Mon, Feb 02, 2015 at 12:45:42PM +0000, Hanjun Guo wrote: > Introduce a new function map_gicc_mpidr() to allow MPIDRs to be obtained > from the GICC Structure introduced by ACPI 5.1. > > MPIDR is the CPU hardware ID as local APIC ID on x86 platform, so we use > MPIDR not the GIC CPU interface ID to identify CPUs. > > Further steps would typedef a phys_id_t for in arch code(with > appropriate size and a corresponding invalid value, say ~0) and use that > instead of an int in drivers/acpi/processor_core.c to store phys_id, then > no need for mpidr packing. > > CC: Rafael J. Wysocki > CC: Catalin Marinas > CC: Will Deacon > Tested-by: Suravee Suthikulpanit > Tested-by: Yijing Wang > Tested-by: Mark Langsdorf > Tested-by: Jon Masters > Tested-by: Timur Tabi > Signed-off-by: Hanjun Guo > --- > arch/arm64/include/asm/acpi.h | 30 ++++++++++++++++++++++++++++++ > drivers/acpi/processor_core.c | 37 +++++++++++++++++++++++++++++++++++++ > 2 files changed, 67 insertions(+) > > diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h > index 8984aa5..7e825b9 100644 > --- a/arch/arm64/include/asm/acpi.h > +++ b/arch/arm64/include/asm/acpi.h > @@ -12,6 +12,8 @@ > #ifndef _ASM_ACPI_H > #define _ASM_ACPI_H > > +#include > + > /* Basic configuration for ACPI */ > #ifdef CONFIG_ACPI > #define acpi_strict 1 /* No out-of-spec workarounds on ARM64 */ > @@ -45,6 +47,34 @@ static inline void enable_acpi(void) > acpi_noirq = 0; > } > > +/* MPIDR value provided in GICC structure is 64 bits, but the > + * existing phys_id (CPU hardware ID) using in acpi processor > + * driver is 32-bit, to conform to the same datatype we need > + * to repack the GICC structure MPIDR. > + * > + * bits other than following 32 bits are defined as 0, so it > + * will be no information lost after repacked. > + * > + * Bits [0:7] Aff0; > + * Bits [8:15] Aff1; > + * Bits [16:23] Aff2; > + * Bits [32:39] Aff3; > + */ > +static inline u32 pack_mpidr(u64 mpidr) > +{ > + return (u32) ((mpidr & 0xff00000000) >> 8) | mpidr; > +} I'm a bit puzzled by this packing: - Bit 31 of the MPIDR is RES1. Do we need to mask it out first? - How does this work for uniprocessor systems where bit 30 is set? - Similarly for mythical multi-threaded implementations with bit 24 set. Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/