Arthur Heymans has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/36087 )
Change subject: soc/intel/tigerlake: Do initial SoC commit ......................................................................
Patch Set 8:
Patch Set 8:
Just to share the thought process behind the copy patch logic and creating newer directory for Intel latest SOC
- ICL and TGL are different SOC target for different launch year, what does that mean is that, FSP source tree version would be different in both cases so growing TGL inside ICL might be needs to deal with so many #IFDEF/if/#IF logic to guard between ICL and TGL specific changes if we consider UPD alone (which might be ~50% SOC/MB code touch point)
I don't think anyone has a problem with UPD's being handled separately.
- We have further analysis and design few coming SOC like JSL inside TGL SOC directory like CNL/WHL/CFL/CML existed due to the fact that JSL and TGL might have same product timeline. trying to making JSL/TGL co-exist inside ICL might looks unnecessarily requirement
The complaints are not about requesting co-existence. This copies 8K+ LoC, which makes one wonder about co-existence of at least some parts. There 2 options: 1) This SOC is so different that it requires new code. In this case copying code makes no sense. 2) This SOC is quite similar to ICL and a lot of code can be reused. Copying all the code and making small modifications is not the best strategy for reasons Nico explained.
- We are also working on common code 1.1 and 2.0 design which might focus on reducing 8K LOC from soc going forward. we had choice to complete common code 1.1 and 2.0 before landing TGL in that case it might not look 8K LOC for sure but looking at product timeline and effort needs to keep, we have decided to go with copy exist model first and then make TGL specific tree. Eventually with proposed common code effort we will see more thinner soc layer than now.
You are not talking about FSP1.1 and FSP2.0 I suppose? Common code is great and improves the quality of code a lot. To avoid a lot of reviewing effort and speed up development, please discuss the common design plans on the mailing list.
Making code common before landing platform support is most certainly going to help the timeline. Reviewing this 8K LOC will take a lot longer than reviewing smaller patches implementing common code.