[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54B8F2E3.80306@arm.com>
Date: Fri, 16 Jan 2015 11:15:47 +0000
From: Marc Zyngier <marc.zyngier@....com>
To: Hanjun Guo <hanjun.guo@...aro.org>,
Catalin Marinas <Catalin.Marinas@....com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Olof Johansson <olof@...om.net>, Arnd Bergmann <arnd@...db.de>,
Mark Rutland <Mark.Rutland@....com>,
"grant.likely@...aro.org" <grant.likely@...aro.org>,
Will Deacon <Will.Deacon@....com>
CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
"graeme.gregory@...aro.org" <graeme.gregory@...aro.org>,
Sudeep Holla <Sudeep.Holla@....com>,
"jcm@...hat.com" <jcm@...hat.com>,
Jason Cooper <jason@...edaemon.net>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Mark Brown <broonie@...nel.org>, Rob Herring <robh@...nel.org>,
Robert Richter <rric@...nel.org>,
Randy Dunlap <rdunlap@...radead.org>,
Charles Garcia-Tobin <Charles.Garcia-Tobin@....com>,
"phoenix.liyi@...wei.com" <phoenix.liyi@...wei.com>,
Timur Tabi <timur@...eaurora.org>,
"suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
"wangyijing@...wei.com" <wangyijing@...wei.com>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
Tomasz Nowicki <tomasz.nowicki@...aro.org>
Subject: Re: [PATCH v7 13/17] ARM64 / ACPI: Add GICv2 specific ACPI boot support
On 14/01/15 15:05, Hanjun Guo wrote:
> From: Tomasz Nowicki <tomasz.nowicki@...aro.org>
>
> ACPI kernel uses MADT table for proper GIC initialization. It needs to
> parse GIC related subtables, collect CPU interface and distributor
> addresses and call driver initialization function (which is hardware
> abstraction agnostic). In a similar way, FDT initialize GICv1/2.
>
> NOTE: This commit allow to initialize GICv1/2 basic functionality.
> GICv2 vitalization extension, GICv3/4 and ITS are considered as next
> steps.
And so is GICv2m, apparently (see below).
>
> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@....com>
> Tested-by: Yijing Wang <wangyijing@...wei.com>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@...aro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@...aro.org>
> ---
> arch/arm64/kernel/acpi.c | 26 +++++++++
> drivers/irqchip/irq-gic.c | 108 +++++++++++++++++++++++++++++++++++
> drivers/irqchip/irqchip.c | 3 +
> include/linux/irqchip/arm-gic-acpi.h | 31 ++++++++++
> 4 files changed, 168 insertions(+)
> create mode 100644 include/linux/irqchip/arm-gic-acpi.h
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index c3e24c4..ea3c9fc 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -23,6 +23,7 @@
> #include <linux/irqdomain.h>
> #include <linux/bootmem.h>
> #include <linux/smp.h>
> +#include <linux/irqchip/arm-gic-acpi.h>
>
> #include <asm/cputype.h>
> #include <asm/cpu_ops.h>
> @@ -315,6 +316,31 @@ void __init acpi_boot_table_init(void)
> pr_err("Can't find FADT or error happened during parsing FADT\n");
> }
>
> +void __init acpi_gic_init(void)
> +{
> + struct acpi_table_header *table;
> + acpi_status status;
> + acpi_size tbl_size;
> + int err;
> +
> + if (acpi_disabled)
> + return;
> +
> + status = acpi_get_table_with_size(ACPI_SIG_MADT, 0, &table, &tbl_size);
> + if (ACPI_FAILURE(status)) {
> + const char *msg = acpi_format_exception(status);
> +
> + pr_err("Failed to get MADT table, %s\n", msg);
> + return;
> + }
> +
> + err = gic_v2_acpi_init(table);
> + if (err)
> + pr_err("Failed to initialize GIC IRQ controller");
> +
> + early_acpi_os_unmap_memory((char *)table, tbl_size);
> +}
> +
> static int __init parse_acpi(char *arg)
> {
> if (!arg)
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index d617ee5..89a8120 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -33,12 +33,14 @@
> #include <linux/of.h>
> #include <linux/of_address.h>
> #include <linux/of_irq.h>
> +#include <linux/acpi.h>
> #include <linux/irqdomain.h>
> #include <linux/interrupt.h>
> #include <linux/percpu.h>
> #include <linux/slab.h>
> #include <linux/irqchip/chained_irq.h>
> #include <linux/irqchip/arm-gic.h>
> +#include <linux/irqchip/arm-gic-acpi.h>
>
> #include <asm/cputype.h>
> #include <asm/irq.h>
> @@ -1083,3 +1085,109 @@ IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic", gic_of_init);
> IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init);
>
> #endif
> +
> +#ifdef CONFIG_ACPI
> +static phys_addr_t dist_phy_base, cpu_phy_base;
> +static int cpu_base_assigned;
> +
> +static int __init
> +gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
> + const unsigned long end)
> +{
> + struct acpi_madt_generic_interrupt *processor;
> + phys_addr_t gic_cpu_base;
> +
> + processor = (struct acpi_madt_generic_interrupt *)header;
> +
> + if (BAD_MADT_ENTRY(processor, end))
> + return -EINVAL;
> +
> + /*
> + * There is no support for non-banked GICv1/2 register in ACPI spec.
> + * All CPU interface addresses have to be the same.
> + */
> + gic_cpu_base = processor->base_address;
> + if (cpu_base_assigned && gic_cpu_base != cpu_phy_base)
> + return -EFAULT;
EFAULT? That feels weird. This error code should be returned if an
access would generate (or has actually generated) a fault, but this is
not the case here. Same for the other cases below.
> +
> + cpu_phy_base = gic_cpu_base;
> + cpu_base_assigned = 1;
> + return 0;
> +}
> +
> +static int __init
> +gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
> + const unsigned long end)
> +{
> + struct acpi_madt_generic_distributor *dist;
> +
> + dist = (struct acpi_madt_generic_distributor *)header;
> +
> + if (BAD_MADT_ENTRY(dist, end))
> + return -EINVAL;
> +
> + dist_phy_base = dist->base_address;
> + return 0;
> +}
> +
> +int __init
> +gic_v2_acpi_init(struct acpi_table_header *table)
> +{
> + void __iomem *cpu_base, *dist_base;
> + int count;
> +
> + /* Collect CPU base addresses */
> + count = acpi_parse_entries(ACPI_SIG_MADT,
> + sizeof(struct acpi_table_madt),
> + gic_acpi_parse_madt_cpu, table,
> + ACPI_MADT_TYPE_GENERIC_INTERRUPT, 0);
> + if (count < 0) {
> + pr_err("Error during GICC entries parsing\n");
> + return -EFAULT;
> + } else if (!count) {
> + pr_err("No valid GICC entries exist\n");
> + return -EINVAL;
> + }
> +
> + /*
> + * Find distributor base address. We expect one distributor entry since
> + * ACPI 5.1 spec neither support multi-GIC instances nor GIC cascade.
> + */
> + count = acpi_parse_entries(ACPI_SIG_MADT,
> + sizeof(struct acpi_table_madt),
> + gic_acpi_parse_madt_distributor, table,
> + ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR, 0);
> + if (count <= 0) {
> + pr_err("Error during GICD entries parsing\n");
> + return -EFAULT;
> + } else if (!count) {
> + pr_err("No valid GICD entries exist\n");
> + return -EINVAL;
> + } else if (count > 1) {
> + pr_err("More than one GICD entry detected\n");
> + return -EINVAL;
> + }
> +
> + cpu_base = ioremap(cpu_phy_base, ACPI_GIC_CPU_IF_MEM_SIZE);
> + if (!cpu_base) {
> + pr_err("Unable to map GICC registers\n");
> + return -ENOMEM;
> + }
> +
> + dist_base = ioremap(dist_phy_base, ACPI_GICV2_DIST_MEM_SIZE);
> + if (!dist_base) {
> + pr_err("Unable to map GICD registers\n");
> + iounmap(cpu_base);
> + return -ENOMEM;
> + }
> +
> + /*
> + * Initialize zero GIC instance (no multi-GIC support). Also, set GIC
> + * as default IRQ domain to allow for GSI registration and GSI to IRQ
> + * number translation (see acpi_register_gsi() and acpi_gsi_to_irq()).
> + */
> + gic_init_bases(0, -1, dist_base, cpu_base, 0, NULL);
I assume you never tried to port the GICv2m driver to ACPI, right?
Because the above code actively prevents the GIC domain to be defined as
a stacked domain, making it impossible for the v2m widget to be
implemented on top of GIC. But maybe legacy interrupts are enough?
> + irq_set_default_host(gic_data[0].domain);
> + return 0;
> +}
> +#endif
> diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
> index 0fe2f71..9106c6d 100644
> --- a/drivers/irqchip/irqchip.c
> +++ b/drivers/irqchip/irqchip.c
> @@ -11,6 +11,7 @@
> #include <linux/init.h>
> #include <linux/of_irq.h>
> #include <linux/irqchip.h>
> +#include <linux/irqchip/arm-gic-acpi.h>
>
> /*
> * This special of_device_id is the sentinel at the end of the
> @@ -26,4 +27,6 @@ extern struct of_device_id __irqchip_of_table[];
> void __init irqchip_init(void)
> {
> of_irq_init(__irqchip_of_table);
> +
> + acpi_gic_init();
Have you realised that this file is probably compiled on multiple
architecture, none of which particularly cares about ACPI or the GIC?
This is (still) very ugly.
I still think this should be implemented properly, following the path
shown by the line just above. Even if we only have two interrupt
controllers until the end of times (which moderately likely unlikely to
be true). But I'm tired of sounding like a stuck record, so I'll STFU.
Thanks,
M.
> }
> diff --git a/include/linux/irqchip/arm-gic-acpi.h b/include/linux/irqchip/arm-gic-acpi.h
> new file mode 100644
> index 0000000..ad5b577
> --- /dev/null
> +++ b/include/linux/irqchip/arm-gic-acpi.h
> @@ -0,0 +1,31 @@
> +/*
> + * Copyright (C) 2014, Linaro Ltd.
> + * Author: Tomasz Nowicki <tomasz.nowicki@...aro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef ARM_GIC_ACPI_H_
> +#define ARM_GIC_ACPI_H_
> +
> +#ifdef CONFIG_ACPI
> +
> +/*
> + * Hard code here, we can not get memory size from MADT (but FDT does),
> + * Actually no need to do that, because this size can be inferred
> + * from GIC spec.
> + */
> +#define ACPI_GICV2_DIST_MEM_SIZE (SZ_4K)
> +#define ACPI_GIC_CPU_IF_MEM_SIZE (SZ_8K)
> +
> +struct acpi_table_header;
> +
> +void acpi_gic_init(void);
> +int gic_v2_acpi_init(struct acpi_table_header *table);
> +#else
> +static inline void acpi_gic_init(void) { }
> +#endif
> +
> +#endif /* ARM_GIC_ACPI_H_ */
>
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists