Bin Meng 3dfa411501 x86: fsp: Use mtrr_set_next_var() for graphics memory ... At present this uses mtrr_add_request() & mtrr_commit() combination to program the MTRR for graphics memory. This usage has two major issues as below: - mtrr_commit() will re-initialize all MTRR registers from index 0, using the settings previously added by mtrr_add_request() and saved in gd->arch.mtrr_req[], which won't cause any issue but is unnecessary - The way such combination works is based on the assumption that U-Boot has full control with MTRR programming (e.g.: U-Boot without any blob that does all low-level initialization on its own, or using FSP2 which does not touch MTRR), but this is not the case with FSP. FSP programs some MTRRs during its execution but U-Boot does not have the settings saved in gd->arch.mtrr_req[] and when doing mtrr_commit() it will corrupt what was already programmed previously. Correct this to use mtrr_set_next_var() instead. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>		2023-08-01 10:06:46 +08:00
..
fsp_common.c	x86: fsp: Only compile fsp_save_s3_stack if (SPL_)DM_RTC is enabled	2022-12-09 14:10:28 -05:00
fsp_dram.c	x86: Correct Chrromebook typo	2023-02-09 16:32:25 -05:00
fsp_graphics.c	x86: fsp: Use mtrr_set_next_var() for graphics memory	2023-08-01 10:06:46 +08:00
fsp_support.c	common: Drop log.h from common header	2020-05-18 21:19:18 -04:00
Makefile	x86: fsp: Make graphics support common to FSP1/2	2019-12-15 11:44:16 +08:00