Nico Huber 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.
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???
i don't understand your point, you are telling not to work on early soc right ? then how do we enable and validate early soc?
That's about the opposite of my intention. It would be nice of both of you if you could stop bullying me for having an opinion that deviates from yours.
PCI enumeration is required because we might need to program GTTMMADR0 and GMADR to make use of sw rendering method even to bring chrome/chromium display on non-GT parts.
PCI enumeration is done anyway. You don't have to jump through hoops for it (in coreboot).
We are driving some initiatives where we can skip HW acceleration and still bring up display to continue our work.
Sorry, I have no idea what "HW acceleration" means in this content or what it has to do with display engine registers.