diff options
author | Bin Meng <bmeng.cn@gmail.com> | 2023-07-31 09:01:07 +0300 |
---|---|---|
committer | Bin Meng <bmeng.cn@gmail.com> | 2023-08-01 05:06:46 +0300 |
commit | bff002d45b0d006458613790eb43397c37f93ae8 (patch) | |
tree | f62155c0f3c8ddc63f138cc8dfd5f7370e6bc0be | |
parent | 0f497b2b8cb2c448cef70460d466c4ad1459f5ec (diff) | |
download | u-boot-bff002d45b0d006458613790eb43397c37f93ae8.tar.xz |
video: vesa: 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>
-rw-r--r-- | drivers/video/vesa.c | 3 |
1 files changed, 1 insertions, 2 deletions
diff --git a/drivers/video/vesa.c b/drivers/video/vesa.c index cac3bb0c33..50912c5c8b 100644 --- a/drivers/video/vesa.c +++ b/drivers/video/vesa.c @@ -23,8 +23,7 @@ static int vesa_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; } |