From: Sudeep Holla <Sudeep.Holla@arm.com>
To: Hanjun Guo <hanjun.guo@linaro.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Sudeep.Holla@arm.com, Lan Tianyu <tianyu.lan@intel.com>,
"patches@linaro.org" <patches@linaro.org>,
"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
Joe Perches <joe@perches.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v5 3/5] ACPI / processor: Introduce map_gic_id() to get apic id from MADT or _MAT method
Date: Wed, 19 Feb 2014 14:33:40 +0000 [thread overview]
Message-ID: <5304C0C4.3080601@arm.com> (raw)
In-Reply-To: <1392740638-2479-4-git-send-email-hanjun.guo@linaro.org>
Hi Hanjun,
On 18/02/14 16:23, Hanjun Guo wrote:
> Get apic id from MADT or _MAT method is not implemented on arm/arm64,
> and ACPI 5.0 introduces GIC Structure for it, so this patch introduces
> map_gic_id() to get apic id followed the ACPI 5.0 spec.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> drivers/acpi/processor_core.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
> index 4dcf776..d316d9b 100644
> --- a/drivers/acpi/processor_core.c
> +++ b/drivers/acpi/processor_core.c
> @@ -71,6 +71,27 @@ static int map_lsapic_id(struct acpi_subtable_header *entry,
> return 0;
> }
>
> +static int map_gic_id(struct acpi_subtable_header *entry,
> + int device_declaration, u32 acpi_id, int *apic_id)
> +{
> + struct acpi_madt_generic_interrupt *gic =
> + (struct acpi_madt_generic_interrupt *)entry;
> +
> + if (!(gic->flags & ACPI_MADT_ENABLED))
> + return -ENODEV;
> +
> + /* In the GIC interrupt model, logical processors are
> + * required to have a Processor Device object in the DSDT,
> + * so we should check device_declaration here
> + */
> + if (device_declaration && (gic->uid == acpi_id)) {
> + *apic_id = gic->gic_id;
I have mentioned this earlier, it's not clear yet to me how does this work ?
It needs more clarity in the form of comment here at-least as the ACPIv5.0 is
also not so clear or explicit on how to handle this.
Here you are expecting gic->uid = acpi_id which is fine, while acpi_map_cpuid
matches apic_id with cpu_physical_id(which must be MPIDR in ARM{32,64}). The
latter imposes restriction that gic->gic_id has to be MPIDR. Does that mean we
are imposing restriction on GIC ID to be MPIDR ? If so please document it here
and please explain the reason behind that choice.
I would expect _UID to be MPIDR rather than GIC ID but you may have some reasons
for this choice.
Regards,
Sudeep
WARNING: multiple messages have this Message-ID (diff)
From: Sudeep.Holla@arm.com (Sudeep Holla)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 3/5] ACPI / processor: Introduce map_gic_id() to get apic id from MADT or _MAT method
Date: Wed, 19 Feb 2014 14:33:40 +0000 [thread overview]
Message-ID: <5304C0C4.3080601@arm.com> (raw)
In-Reply-To: <1392740638-2479-4-git-send-email-hanjun.guo@linaro.org>
Hi Hanjun,
On 18/02/14 16:23, Hanjun Guo wrote:
> Get apic id from MADT or _MAT method is not implemented on arm/arm64,
> and ACPI 5.0 introduces GIC Structure for it, so this patch introduces
> map_gic_id() to get apic id followed the ACPI 5.0 spec.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> drivers/acpi/processor_core.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
> index 4dcf776..d316d9b 100644
> --- a/drivers/acpi/processor_core.c
> +++ b/drivers/acpi/processor_core.c
> @@ -71,6 +71,27 @@ static int map_lsapic_id(struct acpi_subtable_header *entry,
> return 0;
> }
>
> +static int map_gic_id(struct acpi_subtable_header *entry,
> + int device_declaration, u32 acpi_id, int *apic_id)
> +{
> + struct acpi_madt_generic_interrupt *gic =
> + (struct acpi_madt_generic_interrupt *)entry;
> +
> + if (!(gic->flags & ACPI_MADT_ENABLED))
> + return -ENODEV;
> +
> + /* In the GIC interrupt model, logical processors are
> + * required to have a Processor Device object in the DSDT,
> + * so we should check device_declaration here
> + */
> + if (device_declaration && (gic->uid == acpi_id)) {
> + *apic_id = gic->gic_id;
I have mentioned this earlier, it's not clear yet to me how does this work ?
It needs more clarity in the form of comment here at-least as the ACPIv5.0 is
also not so clear or explicit on how to handle this.
Here you are expecting gic->uid = acpi_id which is fine, while acpi_map_cpuid
matches apic_id with cpu_physical_id(which must be MPIDR in ARM{32,64}). The
latter imposes restriction that gic->gic_id has to be MPIDR. Does that mean we
are imposing restriction on GIC ID to be MPIDR ? If so please document it here
and please explain the reason behind that choice.
I would expect _UID to be MPIDR rather than GIC ID but you may have some reasons
for this choice.
Regards,
Sudeep
next prev parent reply other threads:[~2014-02-19 14:33 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-18 16:23 [PATCH v5 0/5] Prepare for running ACPI on !x86 and !ia64 Hanjun Guo
2014-02-18 16:23 ` Hanjun Guo
2014-02-18 16:23 ` [PATCH v5 1/5] ACPI / idle: Make idle_boot_override depend on x86 and ia64 Hanjun Guo
2014-02-18 16:23 ` Hanjun Guo
2014-02-18 16:23 ` [PATCH v5 2/5] ACPI / processor_core: Rework _PDC related stuff to make it more arch-independent Hanjun Guo
2014-02-18 16:23 ` Hanjun Guo
2014-02-19 0:50 ` Rafael J. Wysocki
2014-02-19 0:50 ` Rafael J. Wysocki
2014-02-19 2:16 ` Hanjun Guo
2014-02-19 2:16 ` Hanjun Guo
2014-02-19 16:52 ` Rafael J. Wysocki
2014-02-19 16:52 ` Rafael J. Wysocki
2014-02-19 16:52 ` Rafael J. Wysocki
2014-02-21 18:24 ` Catalin Marinas
2014-02-21 18:24 ` Catalin Marinas
2014-02-21 23:35 ` Rafael J. Wysocki
2014-02-21 23:35 ` Rafael J. Wysocki
2014-02-22 10:33 ` Catalin Marinas
2014-02-22 10:33 ` Catalin Marinas
2014-02-22 10:33 ` Catalin Marinas
2014-02-24 6:57 ` Hanjun Guo
2014-02-24 6:57 ` Hanjun Guo
2014-02-24 6:57 ` Hanjun Guo
2014-02-18 16:23 ` [PATCH v5 3/5] ACPI / processor: Introduce map_gic_id() to get apic id from MADT or _MAT method Hanjun Guo
2014-02-18 16:23 ` Hanjun Guo
2014-02-19 14:33 ` Sudeep Holla [this message]
2014-02-19 14:33 ` Sudeep Holla
2014-02-20 3:59 ` Hanjun Guo
2014-02-20 3:59 ` Hanjun Guo
2014-02-20 3:59 ` Hanjun Guo
2014-02-21 12:37 ` Sudeep Holla
2014-02-21 12:37 ` Sudeep Holla
2014-02-21 12:37 ` Sudeep Holla
2014-02-22 10:21 ` Hanjun Guo
2014-02-22 10:21 ` Hanjun Guo
2014-02-22 11:30 ` Marc Zyngier
2014-02-22 11:30 ` Marc Zyngier
2014-02-22 11:30 ` Marc Zyngier
2014-02-24 6:48 ` Hanjun Guo
2014-02-24 6:48 ` Hanjun Guo
2014-02-24 6:48 ` Hanjun Guo
2014-02-18 16:23 ` [PATCH v5 4/5] ACPI: Move BAD_MADT_ENTRY() to linux/acpi.h Hanjun Guo
2014-02-18 16:23 ` Hanjun Guo
2014-02-18 16:23 ` [PATCH v5 5/5] ACPI: Replace printk with pr_* in tables.c Hanjun Guo
2014-02-18 16:23 ` 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=5304C0C4.3080601@arm.com \
--to=sudeep.holla@arm.com \
--cc=hanjun.guo@linaro.org \
--cc=joe@perches.com \
--cc=linaro-acpi@lists.linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@linaro.org \
--cc=rjw@rjwysocki.net \
--cc=tianyu.lan@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.