[M] Change in coreboot[master]: drivers/intel/gma: Hook up libgfxinit in romstage

[Subrata Banik (Code Review)]

Attention is currently required from: Bora Guvendik, Zhixing Ma, Anil Kumar K, Hannah Williams, Cliff Huang, Tarun Tuli, Nico Huber, Michał Żygowski, Jérémy Compostella, Paul Menzel, Angel Pons, Arthur Heymans.

Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/70276 )

Change subject: drivers/intel/gma: Hook up libgfxinit in romstage
......................................................................

Patch Set 25:

(1 comment)

File src/soc/intel/common/block/graphics/graphics.c:

https://review.coreboot.org/c/coreboot/+/70276/comment/b0423935_3f32e526 
PS23, Line 181: 	if (CONFIG(HWBASE_STATIC_MMIO)) {
> But I am very curious, since we are clearing BAR 0 between romstage and ramstage

Ideally we shouldn't clean BAR0 now with this usecase where coreboot is actually assigning the BAR0 and would expect FSP won't reassign the BAR and simply use it (similar as UART scenario that FSP just use the BAR w/o reassigning it).

As you are now binding static BAR allocation for IGD between romstage and ramstage together, I think it make sense that we shouldn't free it up and make sure FSP also doesn't overrides it rather just use it as is.
> Is there sone FSP-M UPD data persistence I am unaware of ?

FSP actually keep some of the useful data structure into the memory and do the migration into DRAM as it might be still useful during FSP-S.
> can't see how this address is being saved.

if you are wondering about how 0xfa00_0000 address would persist across fsp-m and fsp-s, you don't need to worry as long as the BAR0 is claimed and valid (this address will remain valid across different stages).