LoongArch is a new RISC ISA, which is a bit like MIPS or RISC-V.
LoongArch includes a reduced 32-bit version (LA32R), a standard 32-bit
version (LA32S) and a 64-bit version (LA64). LoongArch use ACPI as its
boot protocol LoongArch-specific interrupt controllers (similar to APIC)
are already added in the ACPI Specification 6.5(which may be published in
early June this year and the board is reviewing the draft).

Currently, LoongArch based processors (e.g. Loongson-3A5000) can only
work together with LS7A chipsets. The irq chips in LoongArch computers
include CPUINTC (CPU Core Interrupt Controller), LIOINTC (Legacy I/O
Interrupt Controller), EIOINTC (Extended I/O Interrupt Controller), PCH-PIC
(Main Interrupt Controller in LS7A chipset), PCH-LPC (LPC Interrupt Controller
in LS7A chipset) and PCH-MSI (MSI Interrupt Controller).

CPUINTC is a per-core controller (in CPU), LIOINTC/EIOINTC are
per-package controllers (in CPU), while PCH-PIC/PCH-LPC/PCH-MSI are all
controllers out of CPU (i.e., in chipsets). These controllers (in other
words, irqchips) are linked in a hierarchy way.

The IPI (Inter-Processor Interrupt) and CPU Local Timer
interrupt go to CPUINTC directly, CPU UARTS interrupts go to LIOINTC,
while all other devices interrupts go to PCH-PIC/PCH-LPC/PCH-MSI and
gathered by EIOINTC, and then go to to CPUINTC directly.

 +--------------------------------------------------------+
 |                                                        |
 |         +-----+     +---------+     +-------+          |
 |         | IPI | --> | CPUINTC | <-- | Timer |          |
 |         +-----+     +---------+     +-------+          |
 |                      ^       ^                         |
 |                      |       |                         |
 |               +---------+ +---------+     +-------+    |
 |               | EIOINTC | | LIOINTC | <-- | UARTs |    |
 |               +---------+ +---------+     +-------+    |
 |                ^       ^                               |
 |                |       |                               |
 |         +---------+ +---------+                        |
 |         | PCH-PIC | | PCH-MSI |                        |
 |         +---------+ +---------+                        |
 |           ^     ^           ^                          |
 |           |     |           |                          |
 |   +---------+ +---------+ +---------+                  |
 |   | PCH-LPC | | Devices | | Devices |                  |
 |   +---------+ +---------+ +---------+                  |
 |        ^                                               |
 |        |                                               |
 |   +---------+                                          |
 |   | Devices |                                          |
 |   +---------+                                          |
 |                                                        |
 |                                                        |
 +--------------------------------------------------------+

The hierarchy model is constructed by parsing irq contronler structures
in MADT.

Example of irqchip topology in a system with  two chipsets:

 +------------------------------------------------------------+
 |                                                            |
 |                     +------------------+                   |
 |                     |      CPUINTC     |                   |
 |                     +------------------+                   |
 |                     ^                  ^                   |
 |                     |                  |                   |
 |          +----------+                  +----------+        |
 |          | EIOINTC 0|                  | EIOINTC 1|        |
 |          +----------+                  +----------+        |
 |          ^          ^                  ^          ^        |
 |          |          |                  |          |        |
 | +----------+   +----------+   +----------+    +----------+ |
 | | PCH-PIC 0|   | PCH-MSI 0|   | PCH-PIC 1|    | PCH-MSI 1| |
 | +----------+   +----------+   +----------+    +----------+ |
 |                                                            |
 |                                                            |
 +------------------------------------------------------------+

For systems with two chipsets, there are tow group(consists of EIOINTC, PCH-PIC and PCH-MSI) irqdomains, 
and each group has same node id. So we defined a structure to mantain the relation of node and it's parent irqdomain.

struct acpi_vector_group {
        int node;
	int pci_segment;
        struct irq_domain *parent;
};

The initialization and use of acpi_vector_group array are following:

1 Entry of struct acpi_vector_group array initialization:

By parsing MCFG, the node id（from bit44-47 of Base Address）and pci segment are extracted. And from MADT, we have the node id of each EIOINTC.

entry.node = node id of pci segment
entry.pci_segment = pci segment (only for msi irqdomain)

By matching node id of entry and EIOINTC to set parent.

entry.parent = EIOINTC irqdomain(node id of EIOINTC == node id of pci segment)

2 Get parent irqdomain for PCH-PIC:

From MADT, we have the node id of each PCH-PIC(from bit44-47 of Base Address).
if (node of entry i == node of PCH-PIC)
	return entrys[i].parent;

3 Get parent irqdomain for PCH-MSI of pci segment:

	return entrys[i].parent; (i is the index of msi irqdomain)

4 How to select a correct irqdomain to map irq for a device?
For devices using legacy irq behind PCH-PIC, GSI is used to select correct PCH-PIC irqdomain.
For devices using msi irq behind PCH-MSI, the pci segmen of the device is used to select correct PCH-MSI irqdomain.

V1 -> V2:
1, Remove queued patches;
2, Move common logic of DT/ACPI probing to common functions;
3, Split .suspend()/.resume() functions to separate patches.

V2 -> V3:
1, Fix a bug for loongson-pch-pic probe;
2, Some minor improvements for LPC controller.

V3 -> V4:
1, Rework the CPU interrupt controller driver;
2, Some minor improvements for other controllers.

V4 -> V5:
1, Add a description of LoonArch's IRQ model;
2, Support multiple EIOINTCs in one system;
3, Some minor improvements for other controllers.

V5 -> V6:
1, Attach a fwnode to CPUINTC irq domain;
2, Use raw spinlock instead of generic spinlock;
3, Improve the method of restoring EIOINTC state;
4, Update documentation, comments and commit messages.

V6 -> V7:
1, Fix build warnings reported by kernel test robot.

V7 -> V8:
1, Add arguments sanity checking for irqchip init functions;
2, Support Loongson-3C5000 (One NUMA Node includes 4 EIOINTC Node).

V8 -> V9:
1, Rebase on 5.17-rc5;
2, Update cover letter;
3, Some small improvements.

V9 -> V10:
1, Rebase on 5.17-rc6;
2, Fix build warnings reported by kernel test robot.

V10 -> V11:
1, Rebase on 5.18-rc4;
2, Fix irq affinity setting for EIOINTC;
3, Fix hwirq allocation failure for EIOINTC.

V11 -> RFC:
1, Refactored the way to build irqchip hierarchy topology.

RFC -> RFC V2:
1, Move all IO-interrupt related code to driver/irqchip from arch directory.
2. Add description for an example of two chipsets system.

RFC V2 -> RFC V3:
1, Add support for multiple GSI domains
2, Use ACPI_GENERIC_GSI for GSI handling
3, Drop suspend-resume stuff
4, Export fwnode handles instead of irq domain handles

RFC V3 -> V12:
1, Address patch attributions of the patch series

V12 -> V13
1 Based on 5.19-rc2
2 Remove arch specified gsi code
3 Split some 'common' code into the various drivers where they belong.
4 Allow acpi_gsi_to_irq() to have an arch-specific fallback

V13 -> V14
1 Add LoongArch-specified APICs definition
2 Use the way in CPUINTC driver to call pch-pic and pch-msi entry
3 Fix compiling and regression issue for OF path

V14 -> V15
1 Expose fwnode_handle of CPUINTC domain instead of using get_xxx_irq() for CPUINTC driver
2 Fix EIOINTC driver: delete parent_data referencing and fix set_affinity bug
3 Use acpi_disabled for DT and ACPI runtime code path
4 Fix return type of arch-specific acpi_gsi_to_irq fallback 
5 Fix compile bug tested by kernel test robot

V15 -> V16

1 Merge entry function to make code simpler for cpuintc driver
2 Provisionally add ACPICA data structures
3 Drop "Legacy" model support
4 Fix compiling error

V16 - V17

1 Adjust order of the patch preparing to support multiple bridges
2 Split the patch removing COMPLE_TEST into pch-pic and pch-msi patches
3 Change some function name for consistency and remove a redundant blank

V17 - V18

1 Merge code into two lines when using IRQCHIP_ACPI_DECLARE
2 Move GSI_MIN_CPU_IRQ to .h of mips arch

Huacai Chen (6):
  irqchip: Add Loongson PCH LPC controller support
  irqchip/loongson-pch-pic: Add ACPI init support
  irqchip/loongson-pch-msi: Add ACPI init support
  irqchip/loongson-liointc: Add ACPI init support
  irqchip: Add Loongson Extended I/O interrupt controller support
  irqchip: Add LoongArch CPU interrupt controller support

Jianmin Lv (4):
  genirq/generic_chip: export irq_unmap_generic_chip
  LoongArch: Use ACPI_GENERIC_GSI for gsi handling
  LoongArch: Prepare to support multiple pch-pic and pch-msi irqdomain
  irqchip / ACPI: Introduce ACPI_IRQ_MODEL_LPIC for LoongArch

Marc Zyngier (3):
  LoongArch: Provisionally add ACPICA data structures
  APCI: irq: Add support for multiple GSI domains
  ACPI: irq: Allow acpi_gsi_to_irq() to have an arch-specific fallback

 arch/loongarch/Kconfig                      |   1 +
 arch/loongarch/include/asm/acpi.h           | 142 ++++++++++
 arch/loongarch/include/asm/irq.h            |  51 ++--
 arch/loongarch/kernel/acpi.c                |  65 -----
 arch/loongarch/kernel/irq.c                 |  58 +++-
 arch/loongarch/kernel/time.c                |  14 +-
 arch/mips/include/asm/mach-loongson64/irq.h |   3 +-
 drivers/acpi/bus.c                          |   3 +
 drivers/acpi/irq.c                          |  58 ++--
 drivers/irqchip/Kconfig                     |  32 ++-
 drivers/irqchip/Makefile                    |   3 +
 drivers/irqchip/irq-gic-v3.c                |  18 +-
 drivers/irqchip/irq-gic.c                   |  18 +-
 drivers/irqchip/irq-loongarch-cpu.c         | 148 +++++++++++
 drivers/irqchip/irq-loongson-eiointc.c      | 395 ++++++++++++++++++++++++++++
 drivers/irqchip/irq-loongson-liointc.c      | 203 ++++++++------
 drivers/irqchip/irq-loongson-pch-lpc.c      | 205 +++++++++++++++
 drivers/irqchip/irq-loongson-pch-msi.c      | 127 ++++++---
 drivers/irqchip/irq-loongson-pch-pic.c      | 177 ++++++++++---
 include/linux/acpi.h                        |   4 +-
 include/linux/cpuhotplug.h                  |   1 +
 include/linux/irq.h                         |   1 +
 kernel/irq/generic-chip.c                   |   2 +-
 23 files changed, 1450 insertions(+), 279 deletions(-)
 create mode 100644 drivers/irqchip/irq-loongarch-cpu.c
 create mode 100644 drivers/irqchip/irq-loongson-eiointc.c
 create mode 100644 drivers/irqchip/irq-loongson-pch-lpc.c

-- 
1.8.3.1

On Wed, 20 Jul 2022 11:51:19 +0100,
Jianmin Lv <lvjianmin@loongson.cn> wrote:
> 
> LoongArch is a new RISC ISA, which is a bit like MIPS or RISC-V.
> LoongArch includes a reduced 32-bit version (LA32R), a standard 32-bit
> version (LA32S) and a 64-bit version (LA64). LoongArch use ACPI as its
> boot protocol LoongArch-specific interrupt controllers (similar to APIC)
> are already added in the ACPI Specification 6.5(which may be published in
> early June this year and the board is reviewing the draft).
> 
> Currently, LoongArch based processors (e.g. Loongson-3A5000) can only
> work together with LS7A chipsets. The irq chips in LoongArch computers
> include CPUINTC (CPU Core Interrupt Controller), LIOINTC (Legacy I/O
> Interrupt Controller), EIOINTC (Extended I/O Interrupt Controller), PCH-PIC
> (Main Interrupt Controller in LS7A chipset), PCH-LPC (LPC Interrupt Controller
> in LS7A chipset) and PCH-MSI (MSI Interrupt Controller).

[...]

OK, that's 4 versions in quick succession, so I suggest we stop the
bikeshedding and focus on getting this actually merged.

I'm going to stick this in a branch and throw it at -next. Any change
will need to go on top of it, no rebasing. If anything that breaks
cannot be fixed easily, I will drop the branch.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Hi, Marc,

On Wed, Jul 20, 2022 at 7:03 PM Marc Zyngier <maz@kernel.org> wrote:
>
> On Wed, 20 Jul 2022 11:51:19 +0100,
> Jianmin Lv <lvjianmin@loongson.cn> wrote:
> >
> > LoongArch is a new RISC ISA, which is a bit like MIPS or RISC-V.
> > LoongArch includes a reduced 32-bit version (LA32R), a standard 32-bit
> > version (LA32S) and a 64-bit version (LA64). LoongArch use ACPI as its
> > boot protocol LoongArch-specific interrupt controllers (similar to APIC)
> > are already added in the ACPI Specification 6.5(which may be published in
> > early June this year and the board is reviewing the draft).
> >
> > Currently, LoongArch based processors (e.g. Loongson-3A5000) can only
> > work together with LS7A chipsets. The irq chips in LoongArch computers
> > include CPUINTC (CPU Core Interrupt Controller), LIOINTC (Legacy I/O
> > Interrupt Controller), EIOINTC (Extended I/O Interrupt Controller), PCH-PIC
> > (Main Interrupt Controller in LS7A chipset), PCH-LPC (LPC Interrupt Controller
> > in LS7A chipset) and PCH-MSI (MSI Interrupt Controller).
>
> [...]
>
> OK, that's 4 versions in quick succession, so I suggest we stop the
> bikeshedding and focus on getting this actually merged.
>
> I'm going to stick this in a branch and throw it at -next. Any change
> will need to go on top of it, no rebasing. If anything that breaks
> cannot be fixed easily, I will drop the branch.
Thank you very much for this series finally get merged.
But there is a question that has puzzled me for a long time so I want
to consult with you: Why exporting fwnode_handle in the driver is
acceptable but exporting irqdomain is not? In my opinion, exporting
irqdomain is more simple and direct because it can avoid
irq_find_matching_fwnode() in the consumer side.

Huacai
>
> Thanks,
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.
>

Hi Huacai,

On Fri, 22 Jul 2022 03:25:23 +0100,
Huacai Chen <chenhuacai@kernel.org> wrote:
> 
> Hi, Marc,
> 
> On Wed, Jul 20, 2022 at 7:03 PM Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Wed, 20 Jul 2022 11:51:19 +0100,
> > Jianmin Lv <lvjianmin@loongson.cn> wrote:
> > >
> > > LoongArch is a new RISC ISA, which is a bit like MIPS or RISC-V.
> > > LoongArch includes a reduced 32-bit version (LA32R), a standard 32-bit
> > > version (LA32S) and a 64-bit version (LA64). LoongArch use ACPI as its
> > > boot protocol LoongArch-specific interrupt controllers (similar to APIC)
> > > are already added in the ACPI Specification 6.5(which may be published in
> > > early June this year and the board is reviewing the draft).
> > >
> > > Currently, LoongArch based processors (e.g. Loongson-3A5000) can only
> > > work together with LS7A chipsets. The irq chips in LoongArch computers
> > > include CPUINTC (CPU Core Interrupt Controller), LIOINTC (Legacy I/O
> > > Interrupt Controller), EIOINTC (Extended I/O Interrupt Controller), PCH-PIC
> > > (Main Interrupt Controller in LS7A chipset), PCH-LPC (LPC Interrupt Controller
> > > in LS7A chipset) and PCH-MSI (MSI Interrupt Controller).
> >
> > [...]
> >
> > OK, that's 4 versions in quick succession, so I suggest we stop the
> > bikeshedding and focus on getting this actually merged.
> >
> > I'm going to stick this in a branch and throw it at -next. Any change
> > will need to go on top of it, no rebasing. If anything that breaks
> > cannot be fixed easily, I will drop the branch.
> Thank you very much for this series finally get merged.
> But there is a question that has puzzled me for a long time so I want
> to consult with you: Why exporting fwnode_handle in the driver is
> acceptable but exporting irqdomain is not? In my opinion, exporting
> irqdomain is more simple and direct because it can avoid
> irq_find_matching_fwnode() in the consumer side.

The idea is that creating a mapping is normally driven by the code
that parses firmware tables, be it DT or ACPI. That code normally only
has access to something that eventually derives into a fwnode.
irqdomains should only be a concern for the IRQ stack itself, and not
the firmware interface.

Now, your architecture breaks some of the fundamentals of what we have
tried to do over the past 10 years, which is to separate the FW
interface from the IRQ code, because you can't describe the topology
in the firmware tables and are stuck with some in-code flow.

We have two choices:

- Either we let you break the above separation and start exposing
  irqdomains everywhere outside of the IRQ stack,

- Or we turn your arch code into its own firmware interface, and make
  it drive the IRQ code as DT/ACPI would normally do.

I have decided to go for the latter, because I don't think the
LoongArch model is a good one. I'm convinced that eventually you will
have to redesign a FW interface that allows full topology discovery
(probably similar to IORT, should you stick with the ACPI model), and
that the current code will become a historical artefact.

And I really don't want this legacy in the core code.

	M.

-- 
Without deviation from the norm, progress is not possible.

Hi, Marc,

On Fri, Jul 22, 2022 at 4:07 PM Marc Zyngier <maz@kernel.org> wrote:
>
> Hi Huacai,
>
> On Fri, 22 Jul 2022 03:25:23 +0100,
> Huacai Chen <chenhuacai@kernel.org> wrote:
> >
> > Hi, Marc,
> >
> > On Wed, Jul 20, 2022 at 7:03 PM Marc Zyngier <maz@kernel.org> wrote:
> > >
> > > On Wed, 20 Jul 2022 11:51:19 +0100,
> > > Jianmin Lv <lvjianmin@loongson.cn> wrote:
> > > >
> > > > LoongArch is a new RISC ISA, which is a bit like MIPS or RISC-V.
> > > > LoongArch includes a reduced 32-bit version (LA32R), a standard 32-bit
> > > > version (LA32S) and a 64-bit version (LA64). LoongArch use ACPI as its
> > > > boot protocol LoongArch-specific interrupt controllers (similar to APIC)
> > > > are already added in the ACPI Specification 6.5(which may be published in
> > > > early June this year and the board is reviewing the draft).
> > > >
> > > > Currently, LoongArch based processors (e.g. Loongson-3A5000) can only
> > > > work together with LS7A chipsets. The irq chips in LoongArch computers
> > > > include CPUINTC (CPU Core Interrupt Controller), LIOINTC (Legacy I/O
> > > > Interrupt Controller), EIOINTC (Extended I/O Interrupt Controller), PCH-PIC
> > > > (Main Interrupt Controller in LS7A chipset), PCH-LPC (LPC Interrupt Controller
> > > > in LS7A chipset) and PCH-MSI (MSI Interrupt Controller).
> > >
> > > [...]
> > >
> > > OK, that's 4 versions in quick succession, so I suggest we stop the
> > > bikeshedding and focus on getting this actually merged.
> > >
> > > I'm going to stick this in a branch and throw it at -next. Any change
> > > will need to go on top of it, no rebasing. If anything that breaks
> > > cannot be fixed easily, I will drop the branch.
> > Thank you very much for this series finally get merged.
> > But there is a question that has puzzled me for a long time so I want
> > to consult with you: Why exporting fwnode_handle in the driver is
> > acceptable but exporting irqdomain is not? In my opinion, exporting
> > irqdomain is more simple and direct because it can avoid
> > irq_find_matching_fwnode() in the consumer side.
>
> The idea is that creating a mapping is normally driven by the code
> that parses firmware tables, be it DT or ACPI. That code normally only
> has access to something that eventually derives into a fwnode.
> irqdomains should only be a concern for the IRQ stack itself, and not
> the firmware interface.
>
> Now, your architecture breaks some of the fundamentals of what we have
> tried to do over the past 10 years, which is to separate the FW
> interface from the IRQ code, because you can't describe the topology
> in the firmware tables and are stuck with some in-code flow.
>
> We have two choices:
>
> - Either we let you break the above separation and start exposing
>   irqdomains everywhere outside of the IRQ stack,
>
> - Or we turn your arch code into its own firmware interface, and make
>   it drive the IRQ code as DT/ACPI would normally do.
>
> I have decided to go for the latter, because I don't think the
> LoongArch model is a good one. I'm convinced that eventually you will
> have to redesign a FW interface that allows full topology discovery
> (probably similar to IORT, should you stick with the ACPI model), and
> that the current code will become a historical artefact.
>
> And I really don't want this legacy in the core code.
OK, I know, thank you very much.

Huacai
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.

On 2022/7/20 下午7:03, Marc Zyngier wrote:
> On Wed, 20 Jul 2022 11:51:19 +0100,
> Jianmin Lv <lvjianmin@loongson.cn> wrote:
>>
>> LoongArch is a new RISC ISA, which is a bit like MIPS or RISC-V.
>> LoongArch includes a reduced 32-bit version (LA32R), a standard 32-bit
>> version (LA32S) and a 64-bit version (LA64). LoongArch use ACPI as its
>> boot protocol LoongArch-specific interrupt controllers (similar to APIC)
>> are already added in the ACPI Specification 6.5(which may be published in
>> early June this year and the board is reviewing the draft).
>>
>> Currently, LoongArch based processors (e.g. Loongson-3A5000) can only
>> work together with LS7A chipsets. The irq chips in LoongArch computers
>> include CPUINTC (CPU Core Interrupt Controller), LIOINTC (Legacy I/O
>> Interrupt Controller), EIOINTC (Extended I/O Interrupt Controller), PCH-PIC
>> (Main Interrupt Controller in LS7A chipset), PCH-LPC (LPC Interrupt Controller
>> in LS7A chipset) and PCH-MSI (MSI Interrupt Controller).
> 
> [...]
> 
> OK, that's 4 versions in quick succession, so I suggest we stop the
> bikeshedding and focus on getting this actually merged.
> 
> I'm going to stick this in a branch and throw it at -next. Any change
> will need to go on top of it, no rebasing. If anything that breaks
> cannot be fixed easily, I will drop the branch.
> 
> Thanks,
> 
> 	M.
> 

Ok, Marc, thanks very much!