| Message ID | 1410530416-30200-15-git-send-email-hanjun.guo@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 09/12/2014 10:00 AM, Hanjun Guo wrote: > From: Tomasz Nowicki <tomasz.nowicki@linaro.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. Aside: A request to specifically update the flags in ACPI to indicate GICv3/v4 systems has been filed for a future spec revision. Jon.
On Fri, Sep 12, 2014 at 03:00:12PM +0100, Hanjun Guo wrote: > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c > index 5b3546b..9869377 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> > @@ -312,6 +313,28 @@ 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; > + > + 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); > +} Maybe this was discussed already but why does this function need to live under arch/arm64? Isn't the driver code more appropriate?
On 09/15/2014 11:01 AM, Catalin Marinas wrote: > On Fri, Sep 12, 2014 at 03:00:12PM +0100, Hanjun Guo wrote: >> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c >> index 5b3546b..9869377 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> >> @@ -312,6 +313,28 @@ 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; >> + >> + 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); >> +} > > Maybe this was discussed already but why does this function need to live > under arch/arm64? Isn't the driver code more appropriate? Well there's two halves to this, right? There's the MADT parsing/setup, which is architecture specific, and then there's the GIC irqchip initialization which lives under drivers. Jon.
On Mon, Sep 15, 2014 at 05:16:21PM +0100, Jon Masters wrote: > On 09/15/2014 11:01 AM, Catalin Marinas wrote: > > On Fri, Sep 12, 2014 at 03:00:12PM +0100, Hanjun Guo wrote: > >> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c > >> index 5b3546b..9869377 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> > >> @@ -312,6 +313,28 @@ 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; > >> + > >> + 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); > >> +} > > > > Maybe this was discussed already but why does this function need to live > > under arch/arm64? Isn't the driver code more appropriate? > > Well there's two halves to this, right? There's the MADT parsing/setup, > which is architecture specific, and then there's the GIC irqchip > initialization which lives under drivers. I think it gets worse, this function is called from irqchip_init(). I would have been slightly happier if it was called from the arm64 init_IRQ(). But putting an ARM specific GIC initialisation call in a generic irqchip_init() just looks weird. Can we do anything better here? > > Jon. > >
On 15.09.2014 18:42, Catalin Marinas wrote: > On Mon, Sep 15, 2014 at 05:16:21PM +0100, Jon Masters wrote: >> On 09/15/2014 11:01 AM, Catalin Marinas wrote: >>> On Fri, Sep 12, 2014 at 03:00:12PM +0100, Hanjun Guo wrote: >>>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c >>>> index 5b3546b..9869377 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> >>>> @@ -312,6 +313,28 @@ 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; >>>> + >>>> + 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); >>>> +} >>> >>> Maybe this was discussed already but why does this function need to live >>> under arch/arm64? Isn't the driver code more appropriate? There will be another call here for GICv3 so this function will merge common logic for them. As Jon pointed out, we are planning to add ACPI flag which indicates GICv3 or GICv2(m) IRQ controller in advance. >> >> Well there's two halves to this, right? There's the MADT parsing/setup, >> which is architecture specific, and then there's the GIC irqchip >> initialization which lives under drivers. > > I think it gets worse, this function is called from irqchip_init(). I > would have been slightly happier if it was called from the arm64 > init_IRQ(). But putting an ARM specific GIC initialisation call in a > generic irqchip_init() just looks weird. Can we do anything better here? Yes this was discussed, please have a look at: https://lkml.org/lkml/2014/9/1/555 We had this in init_IRQ() in previous patch set, then we got feedback irqchip_init() is more appropriate. We can move it back to init_IRQ() and I am sold on this. Tomasz
On Wed, Sep 17, 2014 at 08:40:08AM +0100, Tomasz Nowicki wrote: > On 15.09.2014 18:42, Catalin Marinas wrote: > > On Mon, Sep 15, 2014 at 05:16:21PM +0100, Jon Masters wrote: > >> On 09/15/2014 11:01 AM, Catalin Marinas wrote: > >>> On Fri, Sep 12, 2014 at 03:00:12PM +0100, Hanjun Guo wrote: > >>>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c > >>>> index 5b3546b..9869377 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> > >>>> @@ -312,6 +313,28 @@ 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; > >>>> + > >>>> + 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); > >>>> +} > >>> > >>> Maybe this was discussed already but why does this function need to live > >>> under arch/arm64? Isn't the driver code more appropriate? > > There will be another call here for GICv3 so this function will merge > common logic for them. As Jon pointed out, we are planning to add ACPI > flag which indicates GICv3 or GICv2(m) IRQ controller in advance. We have GIC stuff for ACPI scattered around the kernel (arch/arm64/kernel/acpi.c, drivers/acpi/processor_core.c, drivers/irqchip/). It would be nicer if we find some common place for them, even if that is something under drivers/acpi/ or drivers/irqchip/ (we even have an irq-gic-common.c). > >> Well there's two halves to this, right? There's the MADT parsing/setup, > >> which is architecture specific, and then there's the GIC irqchip > >> initialization which lives under drivers. > > > > I think it gets worse, this function is called from irqchip_init(). I > > would have been slightly happier if it was called from the arm64 > > init_IRQ(). But putting an ARM specific GIC initialisation call in a > > generic irqchip_init() just looks weird. Can we do anything better here? > > Yes this was discussed, please have a look at: > https://lkml.org/lkml/2014/9/1/555 > We had this in init_IRQ() in previous patch set, then we got feedback > irqchip_init() is more appropriate. We can move it back to init_IRQ() > and I am sold on this. The irqchip_init() is indeed the place to call other interrupt controller initialisation functions but what I don't particularly like is calling the GIC one directly while the OF ones are checked against a match string. For GICv3 and later, do you plan to use the same acpi_gic_init() functions? Otherwise we could do something like ACPI_IRQCHIP_DECLARE() similar to the OF ones and a common function that probes whatever is built into the kernel.
On Wednesday 17 September 2014, Catalin Marinas wrote: > > > I think it gets worse, this function is called from irqchip_init(). I > > > would have been slightly happier if it was called from the arm64 > > > init_IRQ(). But putting an ARM specific GIC initialisation call in a > > > generic irqchip_init() just looks weird. Can we do anything better here? > > > > Yes this was discussed, please have a look at: > > https://lkml.org/lkml/2014/9/1/555 > > We had this in init_IRQ() in previous patch set, then we got feedback > > irqchip_init() is more appropriate. We can move it back to init_IRQ() > > and I am sold on this. > > The irqchip_init() is indeed the place to call other interrupt > controller initialisation functions but what I don't particularly like > is calling the GIC one directly while the OF ones are checked against a > match string. For GICv3 and later, do you plan to use the same > acpi_gic_init() functions? Otherwise we could do something like > ACPI_IRQCHIP_DECLARE() similar to the OF ones and a common function that > probes whatever is built into the kernel. I talked abouto this with Marc Z the other day, and I think it really comes down to how we expect this to develop in the future: If this is going to stay with the GICv2/v3/v4 line of interrupt controllers, I see the ACPI_IRQCHIP_DECLARE() as total overdesign, since we wouldn't ever need more than two entry points. Doing ACPI_IRQCHIP_DECLARE() makes it possible to deal with other incompatible irqchips as they come along, but also seems to invite those. Marc believes that it's inevitable that people will add lots of crazy interrupt controllers to systems using ACPI and at that point I agree it would be the right way to deal with it. However, I also think that as long as people expect to be able to add lots of crazy interrupt controller drivers, we are not ready to merge ACPI in the first place, because it must first be clear to everybody that we are not going to allow those nonstandard controller drivers to get merged. Arnd
On Thu, Sep 18, 2014 at 03:25:29AM +0100, Arnd Bergmann wrote: > On Wednesday 17 September 2014, Catalin Marinas wrote: > > > > I think it gets worse, this function is called from irqchip_init(). I > > > > would have been slightly happier if it was called from the arm64 > > > > init_IRQ(). But putting an ARM specific GIC initialisation call in a > > > > generic irqchip_init() just looks weird. Can we do anything better here? > > > > > > Yes this was discussed, please have a look at: > > > https://lkml.org/lkml/2014/9/1/555 > > > We had this in init_IRQ() in previous patch set, then we got feedback > > > irqchip_init() is more appropriate. We can move it back to init_IRQ() > > > and I am sold on this. > > > > The irqchip_init() is indeed the place to call other interrupt > > controller initialisation functions but what I don't particularly like > > is calling the GIC one directly while the OF ones are checked against a > > match string. For GICv3 and later, do you plan to use the same > > acpi_gic_init() functions? Otherwise we could do something like > > ACPI_IRQCHIP_DECLARE() similar to the OF ones and a common function that > > probes whatever is built into the kernel. > > I talked abouto this with Marc Z the other day, and I think it really > comes down to how we expect this to develop in the future: > > If this is going to stay with the GICv2/v3/v4 line of interrupt controllers, > I see the ACPI_IRQCHIP_DECLARE() as total overdesign, since we wouldn't > ever need more than two entry points. I agree, if we are going to have a single acpi_gic_init() function handling all versions of GIC then a macro isn't needed. > Doing ACPI_IRQCHIP_DECLARE() makes it possible to deal with other > incompatible irqchips as they come along, but also seems to invite > those. > > Marc believes that it's inevitable that people will add lots of crazy > interrupt controllers to systems using ACPI and at that point I agree > it would be the right way to deal with it. However, I also think that > as long as people expect to be able to add lots of crazy interrupt > controller drivers, we are not ready to merge ACPI in the first place, > because it must first be clear to everybody that we are not going to > allow those nonstandard controller drivers to get merged. Sounds fine to me. So we leave this call in irqchip_init() and ignore ACPI for platforms with non-standard interrupt controllers.
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c index 5b3546b..9869377 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> @@ -312,6 +313,28 @@ 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; + + 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 4b959e6..8aba096 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> @@ -1029,3 +1031,107 @@ 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; + + 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(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(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); + 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(); } 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@linaro.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_ */