From: Bin Meng Date: Mon, 31 Jul 2023 06:01:06 +0000 (+0800) Subject: video: ivybridge: Use mtrr_set_next_var() for graphics memory X-Git-Tag: v2023.10~58^2~3 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=0f497b2b8cb2c448cef70460d466c4ad1459f5ec;p=platform%2Fkernel%2Fu-boot.git video: ivybridge: 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 Reviewed-by: Simon Glass --- diff --git a/drivers/video/ivybridge_igd.c b/drivers/video/ivybridge_igd.c index 9264dd6..c2cc976 100644 --- a/drivers/video/ivybridge_igd.c +++ b/drivers/video/ivybridge_igd.c @@ -774,8 +774,7 @@ static int bd82x6x_video_probe(struct udevice *dev) /* Use write-combining for the graphics memory, 256MB */ fbbase = IS_ENABLED(CONFIG_VIDEO_COPY) ? plat->copy_base : plat->base; - mtrr_add_request(MTRR_TYPE_WRCOMB, fbbase, 256 << 20); - mtrr_commit(true); + mtrr_set_next_var(MTRR_TYPE_WRCOMB, fbbase, 256 << 20); return 0; }