Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/33189 )
Change subject: soc/intel/common: Skip SoC GT programming based on CONFIG_SKIP_GRAPHICS_ENABLING ......................................................................
Patch Set 1:
(1 comment)
https://review.coreboot.org/#/c/33189/1/src/soc/intel/icelake/graphics.c File src/soc/intel/icelake/graphics.c:
https://review.coreboot.org/#/c/33189/1/src/soc/intel/icelake/graphics.c@48 PS1, Line 48: DDI_A_4_LANES
It's more of enabling the software to deal with the realities of bringing up new silicon.
I think it's rather about the reality of readable code and working together.
What exactly do you mean here?
There is obviously a transition between hobbled and non-hobbled silicon in which there's a logistical problem in supporting everything. It's helpful to have a consistent code base w/ a few knobs vs forking builds and code bases to accommodate the various populations.
There is already a knob. The PCI ID in `src/soc/intel/common/blocks/graphics/graphics.c`. Why does it need an additional 12 line knob???
Do you mean someone modifying the src by removing and putting in a pci id based on builds? If so, that's definitely one way to do it, but it requires modifying this driver as opposed to placing a select in a mainboard or something.
I'm assuming the pci id doesn't change across such working silicon and non-working silicon. That situation does inherently require 2 different builds, but once there's no way to identify such a scenario it's needed. I guess the question is how aesthetically ugly one scenario is vs another. That said, I'm not sure it's clear if this whole driver should be ran or just part of it. Subrata needs to explain that bit better about the internal granularity of this driver needed.