| Message ID | 1426077587-1561-17-git-send-email-hanjun.guo@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hey Grant, On Wed, Mar 11, 2015 at 06:04:50PM +0000, Grant Likely wrote: > On 11 Mar 2015 12:42, "Hanjun Guo" <hanjun.guo@linaro.org> 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. > > While now simple GICv2 init call is used, any further GIC features > > require generic infrastructure for proper ACPI irqchip initialization. > > That mechanism and stacked irqdomains to support GICv2 MSI/virtualization > > extension, GICv3/4 and its ITS are considered as next steps. > > > > CC: Jason Cooper <jason@lakedaemon.net> > > CC: Marc Zyngier <marc.zyngier@arm.com> > > CC: Thomas Gleixner <tglx@linutronix.de> > > BTW, Thomas is taking a bit of a break, do he is unlikely to give an ack > here in a timely manner. I've not heard from Jason. Personally, I think we > can proceed without their ack if everything else is in order (heck, I used > to help with the irq subsystem, use me as an ack of you want). The patch is > low impact and only had effect for ARM ACPI builds. I'm not talking much, but I am tracking and collecting everything for irqchip. We do have some other changes in this driver this time around. So it'd be nice if I could take this. I had reached out to Olof for his thoughts on this and he hasn't had enough cycles to look at it. iirc, Marc reviewed a previous version and was happy with the changes. My only question I had for Olof I'll put below: > > diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c > > index 0fe2f71..afd1af3 100644 > > --- a/drivers/irqchip/irqchip.c > > +++ b/drivers/irqchip/irqchip.c > > @@ -8,6 +8,7 @@ > > * warranty of any kind, whether express or implied. > > */ > > > > +#include <linux/acpi_irq.h> > > #include <linux/init.h> > > #include <linux/of_irq.h> > > #include <linux/irqchip.h> > > @@ -26,4 +27,6 @@ extern struct of_device_id __irqchip_of_table[]; > > void __init irqchip_init(void) > > { > > of_irq_init(__irqchip_of_table); > > + > > + acpi_irq_init(); > > } Is this in line with Olof's idea that providing a dtb would override ACPI? I have no strong opinion on the matter personally. I haven't been able to follow the ACPI discussion as closely as I would have liked, what with the new job and all. Just let me know and I can pull it in with other GIC changes for this cycle. I'll do a topic branch in case other branches need to depend on this. thx, Jason.
On 2015/3/12 7:11, Jason Cooper wrote: > Hey Grant, > > On Wed, Mar 11, 2015 at 06:04:50PM +0000, Grant Likely wrote: >> On 11 Mar 2015 12:42, "Hanjun Guo" <hanjun.guo@linaro.org> 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. >>> While now simple GICv2 init call is used, any further GIC features >>> require generic infrastructure for proper ACPI irqchip initialization. >>> That mechanism and stacked irqdomains to support GICv2 MSI/virtualization >>> extension, GICv3/4 and its ITS are considered as next steps. >>> >>> CC: Jason Cooper <jason@lakedaemon.net> >>> CC: Marc Zyngier <marc.zyngier@arm.com> >>> CC: Thomas Gleixner <tglx@linutronix.de> >> BTW, Thomas is taking a bit of a break, do he is unlikely to give an ack >> here in a timely manner. I've not heard from Jason. Personally, I think we >> can proceed without their ack if everything else is in order (heck, I used >> to help with the irq subsystem, use me as an ack of you want). The patch is >> low impact and only had effect for ARM ACPI builds. > I'm not talking much, but I am tracking and collecting everything for irqchip. > We do have some other changes in this driver this time around. So it'd be nice > if I could take this. > > I had reached out to Olof for his thoughts on this and he hasn't had enough > cycles to look at it. iirc, Marc reviewed a previous version and was happy with > the changes. My only question I had for Olof I'll put below: Please allow me to explain a little bit before Olof's confirmation, please don't mind if any offended. > >>> diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c >>> index 0fe2f71..afd1af3 100644 >>> --- a/drivers/irqchip/irqchip.c >>> +++ b/drivers/irqchip/irqchip.c >>> @@ -8,6 +8,7 @@ >>> * warranty of any kind, whether express or implied. >>> */ >>> >>> +#include <linux/acpi_irq.h> >>> #include <linux/init.h> >>> #include <linux/of_irq.h> >>> #include <linux/irqchip.h> >>> @@ -26,4 +27,6 @@ extern struct of_device_id __irqchip_of_table[]; >>> void __init irqchip_init(void) >>> { >>> of_irq_init(__irqchip_of_table); >>> + >>> + acpi_irq_init(); >>> } > Is this in line with Olof's idea that providing a dtb would override ACPI? Yes, it will. Since ACPI is default OFF (disabled), if a dtb provided, and no acpi=force passed in the early command line, dtb will be used as system configuration for boot (dtb is always the prior one for now) [1]. In acpi_gic_init() which called by acpi_irq_init(), it will return immediately if acpi disabled, so it will not parse any ACPI table for device configuration. [1]: [patch 08/21] ARM64 / ACPI: Introduce early_param "acpi=" to enable/disable ACPI Thanks Hanjun
On Thu, Mar 12, 2015 at 09:46:39AM +0800, Hanjun Guo wrote: > On 2015/3/12 7:11, Jason Cooper wrote: > > Hey Grant, > > > > On Wed, Mar 11, 2015 at 06:04:50PM +0000, Grant Likely wrote: > >> On 11 Mar 2015 12:42, "Hanjun Guo" <hanjun.guo@linaro.org> 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. > >>> While now simple GICv2 init call is used, any further GIC features > >>> require generic infrastructure for proper ACPI irqchip initialization. > >>> That mechanism and stacked irqdomains to support GICv2 MSI/virtualization > >>> extension, GICv3/4 and its ITS are considered as next steps. > >>> > >>> CC: Jason Cooper <jason@lakedaemon.net> > >>> CC: Marc Zyngier <marc.zyngier@arm.com> > >>> CC: Thomas Gleixner <tglx@linutronix.de> > >> BTW, Thomas is taking a bit of a break, do he is unlikely to give an ack > >> here in a timely manner. I've not heard from Jason. Personally, I think we > >> can proceed without their ack if everything else is in order (heck, I used > >> to help with the irq subsystem, use me as an ack of you want). The patch is > >> low impact and only had effect for ARM ACPI builds. > > I'm not talking much, but I am tracking and collecting everything for irqchip. > > We do have some other changes in this driver this time around. So it'd be nice > > if I could take this. > > > > I had reached out to Olof for his thoughts on this and he hasn't had enough > > cycles to look at it. iirc, Marc reviewed a previous version and was happy with > > the changes. My only question I had for Olof I'll put below: > > Please allow me to explain a little bit before Olof's confirmation, please don't mind if > any offended. I'm not sure I parse this correctly, but fwiw, I'm not easily offended. :-) > >>> diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c > >>> index 0fe2f71..afd1af3 100644 > >>> --- a/drivers/irqchip/irqchip.c > >>> +++ b/drivers/irqchip/irqchip.c > >>> @@ -8,6 +8,7 @@ > >>> * warranty of any kind, whether express or implied. > >>> */ > >>> > >>> +#include <linux/acpi_irq.h> > >>> #include <linux/init.h> > >>> #include <linux/of_irq.h> > >>> #include <linux/irqchip.h> > >>> @@ -26,4 +27,6 @@ extern struct of_device_id __irqchip_of_table[]; > >>> void __init irqchip_init(void) > >>> { > >>> of_irq_init(__irqchip_of_table); > >>> + > >>> + acpi_irq_init(); > >>> } > > Is this in line with Olof's idea that providing a dtb would override ACPI? > > Yes, it will. Since ACPI is default OFF (disabled), if a dtb provided, and no acpi=force > passed in the early command line, dtb will be used as system configuration for > boot (dtb is always the prior one for now) [1]. In acpi_gic_init() which called by > acpi_irq_init(), it will return immediately if acpi disabled, so it will not parse > any ACPI table for device configuration. Ok, that matches my recollection. Thanks for refreshing my memory. I'll apply this on a topic branch for irqchip/gic when I return from travel. Most likely Friday or over the weekend. thx, Jason.
On 2015/3/12 13:12, Jason Cooper wrote: > On Thu, Mar 12, 2015 at 09:46:39AM +0800, Hanjun Guo wrote: >> On 2015/3/12 7:11, Jason Cooper wrote: >>> Hey Grant, >>> >>> On Wed, Mar 11, 2015 at 06:04:50PM +0000, Grant Likely wrote: >>>> On 11 Mar 2015 12:42, "Hanjun Guo" <hanjun.guo@linaro.org> wrote: [...] >>>>> diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c >>>>> index 0fe2f71..afd1af3 100644 >>>>> --- a/drivers/irqchip/irqchip.c >>>>> +++ b/drivers/irqchip/irqchip.c >>>>> @@ -8,6 +8,7 @@ >>>>> * warranty of any kind, whether express or implied. >>>>> */ >>>>> >>>>> +#include <linux/acpi_irq.h> >>>>> #include <linux/init.h> >>>>> #include <linux/of_irq.h> >>>>> #include <linux/irqchip.h> >>>>> @@ -26,4 +27,6 @@ extern struct of_device_id __irqchip_of_table[]; >>>>> void __init irqchip_init(void) >>>>> { >>>>> of_irq_init(__irqchip_of_table); >>>>> + >>>>> + acpi_irq_init(); >>>>> } >>> Is this in line with Olof's idea that providing a dtb would override ACPI? >> Yes, it will. Since ACPI is default OFF (disabled), if a dtb provided, and no acpi=force >> passed in the early command line, dtb will be used as system configuration for >> boot (dtb is always the prior one for now) [1]. In acpi_gic_init() which called by >> acpi_irq_init(), it will return immediately if acpi disabled, so it will not parse >> any ACPI table for device configuration. > Ok, that matches my recollection. Thanks for refreshing my memory. I'll apply > this on a topic branch for irqchip/gic when I return from travel. Most likely > Friday or over the weekend. Thank you very much! But this patch can't be applied without previous ones in this patch set, how about you ack this patch and Catalin takes it via ARM64 tree? I'm not sure for this, it depends on your decision. Thanks Hanjun
On 11/03/15 23:11, Jason Cooper wrote: > Hey Grant, > > On Wed, Mar 11, 2015 at 06:04:50PM +0000, Grant Likely wrote: >> On 11 Mar 2015 12:42, "Hanjun Guo" <hanjun.guo@linaro.org> 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. >>> While now simple GICv2 init call is used, any further GIC features >>> require generic infrastructure for proper ACPI irqchip initialization. >>> That mechanism and stacked irqdomains to support GICv2 MSI/virtualization >>> extension, GICv3/4 and its ITS are considered as next steps. >>> >>> CC: Jason Cooper <jason@lakedaemon.net> >>> CC: Marc Zyngier <marc.zyngier@arm.com> >>> CC: Thomas Gleixner <tglx@linutronix.de> >> >> BTW, Thomas is taking a bit of a break, do he is unlikely to give an ack >> here in a timely manner. I've not heard from Jason. Personally, I think we >> can proceed without their ack if everything else is in order (heck, I used >> to help with the irq subsystem, use me as an ack of you want). The patch is >> low impact and only had effect for ARM ACPI builds. > > I'm not talking much, but I am tracking and collecting everything for irqchip. > We do have some other changes in this driver this time around. So it'd be nice > if I could take this. > > I had reached out to Olof for his thoughts on this and he hasn't had enough > cycles to look at it. iirc, Marc reviewed a previous version and was happy with > the changes. FWIW, and given the prominent "NOTE" in the commit message, please have my: Acked-by: Marc Zyngier <marc.zyngier@arm.com> Thanks, M.
Hanjun, Catalin, On Thu, Mar 12, 2015 at 03:31:57PM +0800, Hanjun Guo wrote: > On 2015/3/12 13:12, Jason Cooper wrote: > > On Thu, Mar 12, 2015 at 09:46:39AM +0800, Hanjun Guo wrote: > >> On 2015/3/12 7:11, Jason Cooper wrote: > >>> Hey Grant, > >>> > >>> On Wed, Mar 11, 2015 at 06:04:50PM +0000, Grant Likely wrote: > >>>> On 11 Mar 2015 12:42, "Hanjun Guo" <hanjun.guo@linaro.org> wrote: > [...] > >>>>> diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c > >>>>> index 0fe2f71..afd1af3 100644 > >>>>> --- a/drivers/irqchip/irqchip.c > >>>>> +++ b/drivers/irqchip/irqchip.c > >>>>> @@ -8,6 +8,7 @@ > >>>>> * warranty of any kind, whether express or implied. > >>>>> */ > >>>>> > >>>>> +#include <linux/acpi_irq.h> > >>>>> #include <linux/init.h> > >>>>> #include <linux/of_irq.h> > >>>>> #include <linux/irqchip.h> > >>>>> @@ -26,4 +27,6 @@ extern struct of_device_id __irqchip_of_table[]; > >>>>> void __init irqchip_init(void) > >>>>> { > >>>>> of_irq_init(__irqchip_of_table); > >>>>> + > >>>>> + acpi_irq_init(); > >>>>> } > >>> Is this in line with Olof's idea that providing a dtb would override ACPI? > >> Yes, it will. Since ACPI is default OFF (disabled), if a dtb provided, and no acpi=force > >> passed in the early command line, dtb will be used as system configuration for > >> boot (dtb is always the prior one for now) [1]. In acpi_gic_init() which called by > >> acpi_irq_init(), it will return immediately if acpi disabled, so it will not parse > >> any ACPI table for device configuration. > > Ok, that matches my recollection. Thanks for refreshing my memory. I'll apply > > this on a topic branch for irqchip/gic when I return from travel. Most likely > > Friday or over the weekend. > > Thank you very much! But this patch can't be applied without previous ones in this > patch set, how about you ack this patch and Catalin takes it via ARM64 tree? I'm > not sure for this, it depends on your decision. Is this a build dependency or a boot dependency? I only received this patch in the series and I apologize, I'm a bit swamped atm. Catalin, would an immutable irqchip/gic topic branch with this in it work for you? thx, Jason.
On Fri, Mar 13, 2015 at 5:15 PM, Jason Cooper <jason@lakedaemon.net> wrote: > Hanjun, Catalin, > > On Thu, Mar 12, 2015 at 03:31:57PM +0800, Hanjun Guo wrote: >> On 2015/3/12 13:12, Jason Cooper wrote: >> > On Thu, Mar 12, 2015 at 09:46:39AM +0800, Hanjun Guo wrote: >> >> On 2015/3/12 7:11, Jason Cooper wrote: >> >>> Hey Grant, >> >>> >> >>> On Wed, Mar 11, 2015 at 06:04:50PM +0000, Grant Likely wrote: >> >>>> On 11 Mar 2015 12:42, "Hanjun Guo" <hanjun.guo@linaro.org> wrote: >> [...] >> >>>>> diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c >> >>>>> index 0fe2f71..afd1af3 100644 >> >>>>> --- a/drivers/irqchip/irqchip.c >> >>>>> +++ b/drivers/irqchip/irqchip.c >> >>>>> @@ -8,6 +8,7 @@ >> >>>>> * warranty of any kind, whether express or implied. >> >>>>> */ >> >>>>> >> >>>>> +#include <linux/acpi_irq.h> >> >>>>> #include <linux/init.h> >> >>>>> #include <linux/of_irq.h> >> >>>>> #include <linux/irqchip.h> >> >>>>> @@ -26,4 +27,6 @@ extern struct of_device_id __irqchip_of_table[]; >> >>>>> void __init irqchip_init(void) >> >>>>> { >> >>>>> of_irq_init(__irqchip_of_table); >> >>>>> + >> >>>>> + acpi_irq_init(); >> >>>>> } >> >>> Is this in line with Olof's idea that providing a dtb would override ACPI? >> >> Yes, it will. Since ACPI is default OFF (disabled), if a dtb provided, and no acpi=force >> >> passed in the early command line, dtb will be used as system configuration for >> >> boot (dtb is always the prior one for now) [1]. In acpi_gic_init() which called by >> >> acpi_irq_init(), it will return immediately if acpi disabled, so it will not parse >> >> any ACPI table for device configuration. >> > Ok, that matches my recollection. Thanks for refreshing my memory. I'll apply >> > this on a topic branch for irqchip/gic when I return from travel. Most likely >> > Friday or over the weekend. >> >> Thank you very much! But this patch can't be applied without previous ones in this >> patch set, how about you ack this patch and Catalin takes it via ARM64 tree? I'm >> not sure for this, it depends on your decision. > > Is this a build dependency or a boot dependency? I only received this patch in > the series and I apologize, I'm a bit swamped atm. Catalin, would an immutable > irqchip/gic topic branch with this in it work for you? Jason, For a series like this I strongly recommend you provide an ack and let the whole series go in via a single branch. Trying to split it up only to reassemble it again creates more work for everyone. There is also very little likelyhood that this will create a complex conflict with your tree. g.
On Sat, Mar 14, 2015 at 08:47:49AM +0000, Grant Likely wrote: > On Fri, Mar 13, 2015 at 5:15 PM, Jason Cooper <jason@lakedaemon.net> wrote: > > Hanjun, Catalin, > > > > On Thu, Mar 12, 2015 at 03:31:57PM +0800, Hanjun Guo wrote: > >> On 2015/3/12 13:12, Jason Cooper wrote: > >> > On Thu, Mar 12, 2015 at 09:46:39AM +0800, Hanjun Guo wrote: > >> >> On 2015/3/12 7:11, Jason Cooper wrote: > >> >>> Hey Grant, > >> >>> > >> >>> On Wed, Mar 11, 2015 at 06:04:50PM +0000, Grant Likely wrote: > >> >>>> On 11 Mar 2015 12:42, "Hanjun Guo" <hanjun.guo@linaro.org> wrote: > >> [...] > >> >>>>> diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c > >> >>>>> index 0fe2f71..afd1af3 100644 > >> >>>>> --- a/drivers/irqchip/irqchip.c > >> >>>>> +++ b/drivers/irqchip/irqchip.c > >> >>>>> @@ -8,6 +8,7 @@ > >> >>>>> * warranty of any kind, whether express or implied. > >> >>>>> */ > >> >>>>> > >> >>>>> +#include <linux/acpi_irq.h> > >> >>>>> #include <linux/init.h> > >> >>>>> #include <linux/of_irq.h> > >> >>>>> #include <linux/irqchip.h> > >> >>>>> @@ -26,4 +27,6 @@ extern struct of_device_id __irqchip_of_table[]; > >> >>>>> void __init irqchip_init(void) > >> >>>>> { > >> >>>>> of_irq_init(__irqchip_of_table); > >> >>>>> + > >> >>>>> + acpi_irq_init(); > >> >>>>> } > >> >>> Is this in line with Olof's idea that providing a dtb would override ACPI? > >> >> Yes, it will. Since ACPI is default OFF (disabled), if a dtb provided, and no acpi=force > >> >> passed in the early command line, dtb will be used as system configuration for > >> >> boot (dtb is always the prior one for now) [1]. In acpi_gic_init() which called by > >> >> acpi_irq_init(), it will return immediately if acpi disabled, so it will not parse > >> >> any ACPI table for device configuration. > >> > Ok, that matches my recollection. Thanks for refreshing my memory. I'll apply > >> > this on a topic branch for irqchip/gic when I return from travel. Most likely > >> > Friday or over the weekend. > >> > >> Thank you very much! But this patch can't be applied without previous ones in this > >> patch set, how about you ack this patch and Catalin takes it via ARM64 tree? I'm > >> not sure for this, it depends on your decision. > > > > Is this a build dependency or a boot dependency? I only received this patch in > > the series and I apologize, I'm a bit swamped atm. Catalin, would an immutable > > irqchip/gic topic branch with this in it work for you? > > Jason, > > For a series like this I strongly recommend you provide an ack and let > the whole series go in via a single branch. Trying to split it up only > to reassemble it again creates more work for everyone. There is also > very little likelyhood that this will create a complex conflict with > your tree. I would prefer this approach as well since we only enable ACPI on arm64 on patch 19. If we are to rework this, we probably end up with 3 branches: one for the base ACPI, another for irqchip and yet another to enable ACPI on arm64 (that's unless we enable APCI on arm64 but without any irqchip support which makes it pretty useless for testing).
On Wed, Mar 11, 2015 at 08:39:42PM +0800, 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. > While now simple GICv2 init call is used, any further GIC features > require generic infrastructure for proper ACPI irqchip initialization. > That mechanism and stacked irqdomains to support GICv2 MSI/virtualization > extension, GICv3/4 and its ITS are considered as next steps. > > CC: Jason Cooper <jason@lakedaemon.net> > CC: Marc Zyngier <marc.zyngier@arm.com> > CC: Thomas Gleixner <tglx@linutronix.de> > Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> > Tested-by: Yijing Wang <wangyijing@huawei.com> > Tested-by: Mark Langsdorf <mlangsdo@redhat.com> > Tested-by: Jon Masters <jcm@redhat.com> > Tested-by: Timur Tabi <timur@codeaurora.org> > Tested-by: Robert Richter <rrichter@cavium.com> > Acked-by: Robert Richter <rrichter@cavium.com> > Reviewed-by: Grant Likely <grant.likely@linaro.org> > Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org> > Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> > --- > arch/arm64/include/asm/acpi.h | 2 + > arch/arm64/include/asm/irq.h | 13 +++++ > arch/arm64/kernel/acpi.c | 25 +++++++++ > drivers/irqchip/irq-gic.c | 102 +++++++++++++++++++++++++++++++++++ > drivers/irqchip/irqchip.c | 3 ++ > include/linux/acpi_irq.h | 10 ++++ > include/linux/irqchip/arm-gic-acpi.h | 31 +++++++++++ > 7 files changed, 186 insertions(+) > create mode 100644 include/linux/acpi_irq.h > create mode 100644 include/linux/irqchip/arm-gic-acpi.h Acked-by: Jason Cooper <jason@lakedaemon.net> thx, Jason.
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h index eea0bc3..59c05d8 100644 --- a/arch/arm64/include/asm/acpi.h +++ b/arch/arm64/include/asm/acpi.h @@ -13,6 +13,8 @@ #define _ASM_ACPI_H #include <linux/mm.h> +#include <linux/irqchip/arm-gic-acpi.h> + #include <asm/cputype.h> #include <asm/smp_plat.h> diff --git a/arch/arm64/include/asm/irq.h b/arch/arm64/include/asm/irq.h index 94c5367..bbb251b 100644 --- a/arch/arm64/include/asm/irq.h +++ b/arch/arm64/include/asm/irq.h @@ -1,6 +1,8 @@ #ifndef __ASM_IRQ_H #define __ASM_IRQ_H +#include <linux/irqchip/arm-gic-acpi.h> + #include <asm-generic/irq.h> struct pt_regs; @@ -8,4 +10,15 @@ struct pt_regs; extern void migrate_irqs(void); extern void set_handle_irq(void (*handle_irq)(struct pt_regs *)); +static inline void acpi_irq_init(void) +{ + /* + * Hardcode ACPI IRQ chip initialization to GICv2 for now. + * Proper irqchip infrastructure will be implemented along with + * incoming GICv2m|GICv3|ITS bits. + */ + acpi_gic_init(); +} +#define acpi_irq_init acpi_irq_init + #endif diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c index dec6f8a..6468f88 100644 --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@ -359,3 +359,28 @@ void __init acpi_boot_table_init(void) pr_err("Can't find 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); +} diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c index 4634cf7..929d668 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> @@ -1086,3 +1088,103 @@ 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 __initdata; + +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; + static int cpu_base_assigned; + + 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 -EINVAL; + + 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("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("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..afd1af3 100644 --- a/drivers/irqchip/irqchip.c +++ b/drivers/irqchip/irqchip.c @@ -8,6 +8,7 @@ * warranty of any kind, whether express or implied. */ +#include <linux/acpi_irq.h> #include <linux/init.h> #include <linux/of_irq.h> #include <linux/irqchip.h> @@ -26,4 +27,6 @@ extern struct of_device_id __irqchip_of_table[]; void __init irqchip_init(void) { of_irq_init(__irqchip_of_table); + + acpi_irq_init(); } diff --git a/include/linux/acpi_irq.h b/include/linux/acpi_irq.h new file mode 100644 index 0000000..e4e8a81 --- /dev/null +++ b/include/linux/acpi_irq.h @@ -0,0 +1,10 @@ +#ifndef _LINUX_ACPI_IRQ_H +#define _LINUX_ACPI_IRQ_H + +#include <asm/irq.h> + +#ifndef acpi_irq_init +static inline void acpi_irq_init(void) { } +#endif + +#endif /* _LINUX_ACPI_IRQ_H */ diff --git a/include/linux/irqchip/arm-gic-acpi.h b/include/linux/irqchip/arm-gic-acpi.h new file mode 100644 index 0000000..de3419e --- /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; + +int gic_v2_acpi_init(struct acpi_table_header *table); +void acpi_gic_init(void); +#else +static inline void acpi_gic_init(void) { } +#endif + +#endif /* ARM_GIC_ACPI_H_ */