Hi Am 12.05.20 um 12:30 schrieb Emil Velikov: > On Tue, 12 May 2020 at 09:43, Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: >> >> The VRAM helpers managed the framebuffer memory for mgag200. This came >> with several problems, as some MGA device require the scanout address >> to be located at VRAM offset 0. It's incompatible with the page-flip >> semantics of DRM's atomic modesettting. With atomic modesetting, old and >> new framebuffers have to be located in VRAM at the same time. So at least >> one of them has to reside at a non-0 offset. >> >> This patch replaces VRAM helpers with SHMEM helpers. GEM SHMEM buffers >> reside in system memory, and are shadow-copied into VRAM during page >> flips. The shadow copy always starts at VRAM offset 0. >> > I suspect MGAG200_FLAG_HW_BUG_NO_STARTADD is left around for > documentation purposes? Yes. For now, that flag seems to be the best documentation of the HW issue. Besides, there's another known bug in several MGAs: scanlines may not cross the 4 MiB boundary. If we ever have to work around that problem, NO_STARTADD might become useful again. One can either scanout from 0, or align FB scanlines around the 4 MiB boundary; but not both. > > I've made a few small comments, but regardless the series is: > Acked-by: Emil Velikov <emil.velikov@xxxxxxxxxxxxx> Thanks! Best regards Thomas > > -Emil > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
