Provide a way for userspace to choose synchronous flushing/pageflips. This helps save CPU and power.

It is also useful for test scripts since userspace can know when a flush has happended and wait before doing the next visual test.

Cc: Peter Stuge peter@stuge.se Cc: Linus Walleij linus.walleij@linaro.org Signed-off-by: Noralf Trønnes noralf@tronnes.org --- drivers/gpu/drm/gud/gud_pipe.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c index e0fb6cc969a3..8f56bf618ac2 100644 --- a/drivers/gpu/drm/gud/gud_pipe.c +++ b/drivers/gpu/drm/gud/gud_pipe.c @@ -23,6 +23,19 @@

#include "gud_internal.h"

+/* + * Some userspace rendering loops runs all displays in the same loop. + * This means that a fast display will have to wait for a slow one. + * For this reason gud does flushing asynchronous by default. + * The down side is that in e.g. a single display setup userspace thinks + * the display is insanely fast since the driver reports back immediately + * that the flush/pageflip is done. This wastes CPU and power. + * Such users might want to set this module parameter to false. + */ +static bool gud_async_flush = true; +module_param_named(async_flush, gud_async_flush, bool, 0644); +MODULE_PARM_DESC(async_flush, "Enable asynchronous flushing [default=true]"); + /* * FIXME: The driver is probably broken on Big Endian machines. * See discussion: @@ -578,6 +591,8 @@ void gud_pipe_update(struct drm_simple_display_pipe *pipe, if (gdrm->flags & GUD_DISPLAY_FLAG_FULL_UPDATE) drm_rect_init(&damage, 0, 0, fb->width, fb->height); gud_fb_queue_damage(gdrm, fb, &damage); + if (!gud_async_flush) + flush_work(&gdrm->work); }

if (!crtc->state->enable)

Hi Noralf,

Noralf Trønnes wrote:

Add VID/PID for the Raspberry Pi Pico implementation. Source: https://github.com/notro/gud-pico

+++ b/drivers/gpu/drm/gud/gud_drv.c @@ -660,6 +660,7 @@ static int gud_resume(struct usb_interface *intf)

static const struct usb_device_id gud_id_table[] = { { USB_DEVICE_INTERFACE_CLASS(0x1d50, 0x614d, USB_CLASS_VENDOR_SPEC) },

• { USB_DEVICE_INTERFACE_CLASS(0x16d0, 0x10a9, USB_CLASS_VENDOR_SPEC) }, { }

};

A VID/PID isn't neccessarily tied to one implementation; as long as an implementation is in fact compatible with the driver I consider it okay to reuse a VID/PID, and the 0x1d50 conditions are met by gud-pico too. That said, there's no harm in adding another id. :)

Reviewed-by: Peter Stuge peter@stuge.se

//Peter