Change in coreboot[master]: soc/intel/common/block/irq: Add support for intel_write_pci0_PRT

[Tim Wawrzynczak (Code Review)]

Attention is currently required from: Nico Huber, Furquan Shaikh, Patrick Rudolph.
Tim Wawrzynczak has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/51159 )

Change subject: soc/intel/common/block/irq: Add support for intel_write_pci0_PRT
......................................................................

Patch Set 8:

(1 comment)

File src/soc/intel/common/block/irq/irq.c:

https://review.coreboot.org/c/coreboot/+/51159/comment/ddc091ab_2e8fd363 
PS7, Line 378: 		/* Map INTA->PIRQ_A, INTB->PIRQ_B, INTC->PIRQ_C, INTD->PIRQ_D */
> > Sorry I can make the comment a little more clear, this is how Intel does the mapping for PIC-mode  […]

You are correct, this recommendation comes from the BWG guides IIRC. However I agree with you that I think without the OS' ability to rewrite the PIRx, it is effectively locked out of being able to use legacy PIC mode. This patch currently just retains the legacy-mode table intact.

However, here is where things stand:
the respective soc/espi.c files call pch_pirq_init() in common/intel/block/lpc_lib, which attempts to program in the legacy IRQ settings, but AFAICT, the devices that require these unique IRQs ignore what is programmed in this register, and use what is programmed in the PCR space instead. In the OS, I can read config space PCI_INTERRUPT_LINE as 0xa or 0xb for an I2C device for example, but /proc/interrupts shows what the ACPI table included, and the IRQs are working. I will try an experiment with `noapic` with and without my patch train and see if it even works at all.