On 6 April 2017 at 17:29, Jeremy Linton <[email protected]> wrote: > Hi, > > On 04/06/2017 08:15 AM, Ard Biesheuvel wrote: >> >> 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) > > > So, I applied a similar set of patches against the juno, and everything > continues to work. The change also looks good. > > So, > > Reviewed-by: Jeremy Linton <[email protected]> >
Thanks! > > But I'm still concerned in general, since the HDLCD frame buffer is odd in > that its just system memory rather than being attached to an IO bus of some > form. AKA its not actually a "VRAM" (cue discussion about GDDR not having > multiple ports/etc)... > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
