Andrey Petrov has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/38986 )
Change subject: WIP: xeonsp: Add common IIO-related code ......................................................................
Patch Set 10:
(2 comments)
The registers are relatively easy to get from EDS. In a nutshell we need to configure interleaved MMCFG decoder, assign bus number across different sockets (for that we need to either hardcode sockets number and topology or discover it programmatically).
https://review.coreboot.org/c/coreboot/+/38986/8/src/cpu/intel/xeonsp/iio.c File src/cpu/intel/xeonsp/iio.c:
https://review.coreboot.org/c/coreboot/+/38986/8/src/cpu/intel/xeonsp/iio.c@... PS8, Line 394: static void get_iiostack_info(struct iiostack_resource *info)
why is this data read from FSP instead of devicetree or PCI space?
I would think it shouldn't be possible to relay on FSP for this. We should be able to derive all these parameters based from topology of a given system (e.g sockets number and interconnect). In this case, we let FSP figure it all out on its own and populate the HOBs. Right now I have but cursory understanding of it.
https://review.coreboot.org/c/coreboot/+/38986/8/src/cpu/intel/xeonsp/iio.c@... PS8, Line 534: n
isn't a "stack" simply an MMCONF address area or a subregion of that?
so IIO is split into multiple units called "stacks". Each stack behaves as a root port and resides on its own physical bus. I am not quite sure but it may be that these stacks resemble "pci segment groups". These are, in turn, are just another dimension to bus/device/function so it is segment/bus/device/function. All of that is needed because 256 bues is not enough if you have a system with several sockets and you want every one of them to be able to access local MMCONF regions