Messages in this thread |  | | Date | Fri, 20 May 2022 16:04:28 +0100 | Subject | Re: [PATCH V11 00/10] irqchip: Add LoongArch-related irqchip drivers | From | Jiaxun Yang <> |
| |
在 2022/5/5 16:58, Marc Zyngier 写道: >> LoongArch use ACPI, but ACPI tables cannot describe the hierarchy of >> irqchips, so we initilize the irqchip subsystem in this way (from arch >> code): >> >> cpu_domain = loongarch_cpu_irq_init(); >> liointc_domain = liointc_acpi_init(cpu_domain, acpi_liointc); >> eiointc_domain = eiointc_acpi_init(cpu_domain, acpi_eiointc); >> pch_pic_domain = pch_pic_acpi_init(eiointc_domain, acpi_pchpic); >> pch_msi_domain = pch_msi_acpi_init(eiointc_domain, acpi_pchmsi); > I said no to this in the past, and I'm going to reiterate: this is > *not* acceptable. This obviously doesn't scale and isn't manageable in > the long run. Hardcoding the topology and the probing order in the > kernel code has repeatedly proved to be a disaster, and yet you refuse > to take any input from past experience. This is pretty worrying. Just my two cents here.
Those drivers have such a topology just because this was my design to handle irqchip differences between RS780E and LS7A for MIPS-era Loongson.
TBH, for LoongArch-era Loongson, they should be handled by the same driver, cuz the topology behind them just looks like GIC PPI SPI and MSI for Arm GIC.
PCH PIC and eiointc in combination relays interrupts from peripherals just like SPI. liointc is doing the PPI job. They are not separated modules in hardware, they are interlocked.
The system should be treated as a whole, pretty much like how we see Arm's GIC. The topology will last forever for every ACPI enabled LoongArch PC.
I see no reason they should be described separately. Adding complicities to ACPI bindings brings no benefit. Changing ACPI binding which is already in final draft stage can only leave us with chaos.
Disclaimer: I don't have any connections with Loongson currently. I'm standing at contributor's approach to make statement above.
Thanks. - Jiaxun
|  |