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>

diff --git a/arch/x86/lib/fsp/fsp_graphics.c b/arch/x86/lib/fsp/fsp_graphics.c
index 2bcc49f6051267ae173efa08ff48f108efd0acb0..09d5da8c841a0113e7e899a73440971ab077a2cb 100644 (file)
--- a/arch/x86/lib/fsp/fsp_graphics.c
+++ b/arch/x86/lib/fsp/fsp_graphics.c
@@ -110,8 +110,7 @@ static int fsp_video_probe(struct udevice *dev)
        if (ret)
                goto err;
 
-       mtrr_add_request(MTRR_TYPE_WRCOMB, vesa->phys_base_ptr, 256 << 20);
-       mtrr_commit(true);
+       mtrr_set_next_var(MTRR_TYPE_WRCOMB, vesa->phys_base_ptr, 256 << 20);
 
        printf("%dx%dx%d @ %x\n", uc_priv->xsize, uc_priv->ysize,
               vesa->bits_per_pixel, vesa->phys_base_ptr);