Re: [PATCH v2 0/5] ArmPlatformPkg: map VRAM using memory semantics

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 6 April 2017 at 17:29, Jeremy Linton <jeremy.linton@arm.com> 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 <jeremy.linton@arm.com>
>

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)...
>