Hi Thomas. On Thu, Dec 05, 2019 at 05:01:38PM +0100, Thomas Zimmermann wrote: > A full-screen memcpy() moves the console's shadow buffer to hardware; with > possibly significant runtime overhead. [1] Synchronizing the screen update > with VBLANK events can hopefully reduce the number of screen updates. > > The patchset first adds vblank support to mgag200 as the problem was > initially reported for Matrox hardware. > > The console's dirty worker now waits for the vblank to rate limit the > output frequency. Screen output can pile up while waiting and there's a > chance that multiple screen updates can be handled with a single memcpy(). > Note that this has no effect on tearing: while the dirty worker updates > the hardware buffer, new data can still arrive in the shadow buffer. This > can create a tearing effcet, even though console output is synchronized > to vblank. > > In version 2 of this patchset, fbdev emulation missed the first vblank > event because mgag200 initialized the fbdev console before the irq. > Initializing fbdev last fixes this problem. If other drivers now start > reporting a missed vblank during boot, this might be the reason. > > The patchset was tested by running fbdev emulation and Gnome (X11) on > mgag200 HW. > > v3: > * fbdev: hold helper->mutex > * fbdev: acquire DRM master so other masters cannot interfere > * mgag200: init fbdev after irq avoids missing first vblank > * mgag200: trigger irq at <vdisplay> + 1 matches vblank > v2: > * remove locking from fbdev patch > * use constants for mgag200 register names and fields > * double-check that VLINE irq is active on mgag200 > * only signal vblank on CRTC 0 of mgag200 > * coding-style fixes > > [1] https://lists.freedesktop.org/archives/dri-devel/2019-July/228663.html > > Thomas Zimmermann (4): > drm/mgag200: Create fbdev console after registering device > drm/mgag200: Rename constant MGAREG_Status to MGAREG_STATUS > drm/mgag200: Add vblank support > drm/fb-helper: Synchronize dirty worker with vblank Whole series is: Acked-by: Sam Ravnborg <sam@xxxxxxxxxxxx> The code all looked good, but I am not familiar enough with the code to say I reviewed it all. A few nits in one patch sent in a separate mail. Sam _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel