> Date: Thu, 9 Jun 2022 21:04:37 +0200 > From: Alexander Graf <ag...@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.