Nathaniel L Desimone has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/49055 )
Change subject: soc/intel/tigerlake: Add Kconfig options for each platform ......................................................................
Patch Set 3:
(1 comment)
https://review.coreboot.org/c/coreboot/+/49055/3/src/mainboard/intel/tglrvp/... File src/mainboard/intel/tglrvp/Kconfig:
https://review.coreboot.org/c/coreboot/+/49055/3/src/mainboard/intel/tglrvp/... PS3, Line 16: select SOC_INTEL_TIGERLAKE_IOT if BOARD_INTEL_TGLRVP_UP3 : select SOC_INTEL_TIGERLAKE_CLIENT if BOARD_INTEL_TGLRVP_UP4 Most of the time we should use the client FSP for TGLRVP_UP3. The comment in that table is trying to point out that the IoT SKUs of TGL are 100% UP3 (there are no UP4 IoT SKUs) whereas the client SKUs have both UP3 and UP4. I wrote the following snippet in README.md to describe when the IoT FSP should be used:
Client and IoT (Internet of Things) SKUs of 11th Generation Intel® Core™ (formerly Tiger Lake) processors can be differentiated by checking the processor number. Processor numbers ending in a "E" are IoT SKUs, processor numbers that do not end in "E" are client SKUs. For example, the Intel® Core™ i7-1185G7 is a client SKU and the Intel® Core™ i7-1185G7E is an IoT SKU.
The vast majority of TGL UP3 RVPs will be built with a client SKU, so client FSP should definitely be the default. I think it would be reasonable to provide a mechanism for someone to override this with the IoT FSP because ~5% of TGL UP3 RVPs will be built with an IoT SKU. The client FSP will still boot on an IoT SKU, however IoT SKU specific chipset features like TCC (Time Coordinated Computing) won't work without the IoT FSP. So I think keeping client as default makes sense. Using the IoT FSP should be an explicit Kconfig override for the rare cases where you want it.