drm/plane-helper: Don't fake-implement primary plane disabling
After thinking about this topic a bit more I've reached the conclusion
that implementing this doesn't make sense:
- The locking is all wrong: set_config(NULL) will also unlink encoders
and connectors, but those links are protected with the mode_config
mutex. In the ->disable_plane callback we only hold all modeset
locks, but eventually we want to switch to just grabbing the
per-crtc (and maybe per-plane) locks as needed, maybe based on
ww_mutexes. Having a callback which absolutely needs all modeset
locks is bad for this conversion.
Note that the same isn't true for the provided ->update_plane since
we've audited the crtc helpers to make sure that not encoder or
connector links are changed.
- There's no way to re-enable the plane with an ->update_plane: The
connectors/encoder links are lost and so we can't re-enable the
CRTC. Even without that issue the driver might have reassigned some
shared resources (as opposed to e.g. DPMS off, where drivers are not
allowed to do that to make sure the CRTC can be enabled again).
- The semantics don't make much sense: Userspace asked to scan out
black (or some other color if the driver supports a background
color), not that the screen be disabled.
- Implementing proper primary plane support (i.e. actually disabling
the primary plane without disabling the CRTC) is really simple, at
least if all the hw needs is flipping a bit. The big task is
auditing all the interactions with other ioctls when the CRTC is on
but there's no primary plane (e.g. pageflips). And some of that work
still needs to be done.
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
1 file changed