video: broadwell: 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>
diff --git a/drivers/video/broadwell_igd.c b/drivers/video/broadwell_igd.c
index 6aa4e27..83b6c90 100644
--- a/drivers/video/broadwell_igd.c
+++ b/drivers/video/broadwell_igd.c
@@ -693,13 +693,9 @@
/* Use write-combining for the graphics memory, 256MB */
fbbase = IS_ENABLED(CONFIG_VIDEO_COPY) ? plat->copy_base : plat->base;
- ret = mtrr_add_request(MTRR_TYPE_WRCOMB, fbbase, 256 << 20);
- if (!ret)
- ret = mtrr_commit(true);
- if (ret && ret != -ENOSYS) {
- printf("Failed to add MTRR: Display will be slow (err %d)\n",
- ret);
- }
+ ret = mtrr_set_next_var(MTRR_TYPE_WRCOMB, fbbase, 256 << 20);
+ if (ret)
+ printf("Failed to add MTRR: Display will be slow (err %d)\n", ret);
debug("fb=%lx, size %x, display size=%d %d %d\n", plat->base,
plat->size, uc_priv->xsize, uc_priv->ysize, uc_priv->bpix);