Hi Simon,
On Mon, Jul 31, 2023 at 2:02 PM Bin Meng <bm...@tinylab.org> wrote:
>
> From: Bin Meng <bmeng...@gmail.com>
>
> 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...@gmail.com>
> ---
>
> (no changes since v1)
>
> arch/x86/lib/fsp/fsp_graphics.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/x86/lib/fsp/fsp_graphics.c b/arch/x86/lib/fsp/fsp_graphics.c
> index 2bcc49f605..09d5da8c84 100644
> --- 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);
> --
Would you give a Rb/Tb tag, if you will?
Regards,
Bin
