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 ---
drivers/video/broadwell_igd.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/video/broadwell_igd.c b/drivers/video/broadwell_igd.c index 6aa4e27071..83b6c908a8 100644 --- a/drivers/video/broadwell_igd.c +++ b/drivers/video/broadwell_igd.c @@ -693,13 +693,9 @@ static int broadwell_igd_probe(struct udevice *dev)
/* 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);