As reported by Jeremy, the recently introduced accelerated memcpy/memset
routines are causing problems when used on framebuffer memory. While
framebuffers are arguably right on the blurry line between MMIO (with
side effects that are sensitive to ordering) and memory, mapping VRAM
as device memory is unnecessary to begin with, and so we can improve
our situation by using memory semantics for the VRAM mappings. (Whether
we end up reverting to the unaccelerated memcpy/memset routines is a
separate matter)
So fix both the FVP case, which has a separate VRAM region, and TC2, which
allocates VRAM from normal memory and changes the mapping attributes.
Note to Ryan: this fixes FVP Base model for me, but not the Foundation model
(whose PL111 support I never saw working to begin with, so I am not sure what
is going on there)
Ard Biesheuvel (5):
ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory
ArmPlatformPkg/HdLcdArmVExpressLib: fix incorrect FreePool () call
ArmPlatformPkg/PL111LcdArmVExpressLib: fix incorrect FreePool () call
ArmPlatformPkg/HdLcdArmVExpressLib: use write-combine mapping for VRAM
ArmPlatformPkg/PL111LcdArmVExpressLib: use write-combine mapping for
VRAM
ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
| 10 ++++++----
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
| 8 +++++++-
ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
| 14 +++++---------
ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
| 3 ++-
ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
| 14 +++++---------
ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
| 3 ++-
6 files changed, 27 insertions(+), 25 deletions(-)
--
2.9.3
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
