Attention is currently required from: Nico Huber, Furquan Shaikh, Martin Roth, Duncan Laurie, Aamir Bohra, Srinidhi N Kaushik, Patrick Rudolph. Tim Wawrzynczak has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/49408 )
Change subject: soc/intel/common: Add new IRQ block ......................................................................
Patch Set 3:
(1 comment)
Patchset:
PS3:
Before we start down this road, can you provide an accurate […]
Sure Nico, I understand, Intel honestly hasn't made this very easy...
Since for the foreseeable future, the FSP is in charge of programming PCI IRQs, the goal here is to move *away* from board-specific tables, and instead use the constraints that certain IPs have (ror a given SoC) for assigning IRQs to dynamically generate a PCI routing table at runtime. This frees up the developer from having to worry about IOAPIC IRQ assignments at all, given the SoC-level code provides the correct constraints.
To answer your question, both Volteer and Brya as it stands have potential IOAPIC conflicts between GPIOs and PCI devices, when using the FSP default PCI IRQ assignments. We could just avoid routing GPIOs to IOAPIC, and use GPIO_DRIVER ownership instead, but that adds unnecessary latency to the IRQ handler, therefore we would prefer to use the IOAPIC IRQs for certain peripherals where lower latency IRQs are preferable (using GPI_INT means using the GPIO controller's IRQ, i.e. #14 for TGL, and means the IRQ handler has to go search to find which GPIO triggered the IRQ).
Volteer: The fingerprint MCU interrupt is on GPP_C20, which TGL hardcodes, via PAD_CFG_DW1:INTESL (which is RO) as 0x22. TGL FSP hardcodes UART0 to use the same IOAPIC IRQ.
Brya: One of the SAR peripherals is using GPP_B3, and ADL-P hardcodes INTSEL here to be 0x1B; the ADL FSP hardcodes I2C0 to use this same IRQ, therefore we have to use GPI_INT here.
The point of this patch series is to give coreboot back the freedom to choose PCI IRQs, instead of having them forced by the FSP when none are provided; this gives us flexibility and prevents problems in the future w/r/t conflicting PCI/GPIO IRQs.