[PATCH 0/6] Add video damage tracking

[Mark Kettenis]

> Date: Thu, 9 Jun 2022 21:04:37 +0200
> From: Alexander Graf <agraf at csgraf.de>
> 
> On 07.06.22 10:28, Heinrich Schuchardt wrote:
> > On 6/7/22 01:43, Alexander Graf wrote:
> >> This patch set speeds up graphics output on ARM by a factor of 60x.
> >>
> >> On most ARM SBCs, we keep the frame buffer in DRAM and map it as cached,
> >> but need it accessible by the display controller which reads directly
> >> from a later point of consistency. Hence, we flush the frame buffer to
> >> DRAM on every change. The full frame buffer.
> >
> > Isn't a similar problem already solved by CONFIG_VIDEO_COPY?
> >
> > Leaving the frame buffer uncached would convert the ARM problem into the
> > X86 case?
> 
> 
> It solves a similar problem, yes. However, it requires us to allocate 
> the frame buffer size twice, and we would need to dynamically toggle the 
> MMU mappings of the frame buffer to WC instead of cached. That's code we 
> don't have today.

For the Apple M1 the framebuffer is covered by the "memory map" and
maps it as Normal-NC, but that is because the framebuffer is already
set up at the point where u-boot takes control.