Change in coreboot[master]: soc/intel/tigerlake: Do initial SoC commit

[Subrata Banik (Code Review)]

Subrata Banik 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:
> > 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.

its been problem for validation across team (as we have seen in past developed might break other soc without proper knowledge of usage), when multiple soc are getting hooks inside as parent soc (unnecessarily like ICL and TGL), Folks who are using ICL coreboot code might bother about TGL code pieces and vice versa without any reason as these are 2 completely different generation product. we always like to maintain to same generation product under same parent soc directory like CNL/CFL/WHL as an example
> > 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:
> This SOC is so different that it requires new code. In this case copying code makes no sense.

its not completely different i agree but don't fully agree that copy code might not be a solution here.
> 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.

its not "small" for that matter either but we can assured that we have visibility of amount of code went in by copy and how do we plan to use those codes.
> > 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.

no its intel common code spec not the FSP spec. where we analysis the common block inside soc and optimize the porting effort
> 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.

the view we have about common code and the effort might require to comprehend the same might not meet the timeline what we are looking at to enable TGL at upsteam as per customer request.