summaryrefslogtreecommitdiff
path: root/drivers/mfd
diff options
context:
space:
mode:
authorDaniel Vetter <daniel.vetter@ffwll.ch>2021-07-23 11:34:56 +0300
committerDaniel Vetter <daniel.vetter@ffwll.ch>2021-07-27 13:21:22 +0300
commitc7fcbf2513973208c03a2173cd25a2c48fec6605 (patch)
tree0f3e9140e750934a0825e4c8d3767dae90d42fce /drivers/mfd
parent6f11f37459d8f9f74ff1c299c0bedd50b458057a (diff)
downloadlinux-c7fcbf2513973208c03a2173cd25a2c48fec6605.tar.xz
drm/plane: check that fb_damage is set up when used
There's two stages of manual upload/invalidate displays: - just handling dirtyfb and uploading the entire fb all the time - looking at damage clips In the latter case we support it through fbdev emulation (with fb_defio), atomic property, and with the dirtfy clip rects. Make sure at least the atomic property is set up as the main official interface for this. Ideally we'd also check that drm_atomic_helper_dirtyfb() is used and that fbdev defio is set up, but that's quite a bit harder to do. Ideas very much welcome. From a cursor audit drivers seem to be getting this right mostly, but better to make sure. At least no one is bypassing the accessor function. v2: - use drm_warn_once with a meaningful warning string (José) - don't splat in the atomic check code for everyone (intel-gfx-ci) Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (v1) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210723083457.696939-2-daniel.vetter@ffwll.ch
Diffstat (limited to 'drivers/mfd')
0 files changed, 0 insertions, 0 deletions