drm: Add atomic driver interface definitions for objects
Heavily based upon Rob Clark's atomic series. - Dropped the connector state from the crtc state, instead opting for a full-blown connector state. The only thing it has is the desired crtc, but drivers which have connector properties have now a data-structure to subclass. - Rename create_state to duplicate_state. Especially for legacy ioctls we want updates on top of existing state, so we need a way to get at the current state. We need to be careful to clear the backpointers to the global state correctly though. - Drop property values. Drivers with properties simply need to subclass the datastructures and track the decoded values in there. I also think that common properties (like rotation) should be decoded and stored in the core structures. - Create a new set of ->atomic_set_prop functions, for smoother transitions from legacy to atomic operations. - Pass the ->atomic_set_prop ioctl the right structure to avoid chasing pointers in drivers. - Drop temporary boolean state for now until we resurrect them with the helper functions. - Drop invert_dimensions. For now we don't need any checking since that's done by the higher-level legacy ioctls. But even then we should also add rotation/flip tracking to the core drm_crtc_state, not just whether the dimensions are inverted. - Track crtc state with an enable/disable. That's equivalent to mode_valid, but a bit clearer that it means the entire crtc. The global interface will follow in subsequent patches. v2: We need to allow drivers to somehow set up the initial state and clear it on resume. So add a plane->reset callback for that. Helpers will be provided with default behaviour for all these. v3: Split out the plane->reset into a separate patch. v4: Improve kerneldoc in drm_crtc.h v5: Remove unused inline functions for handling state objects, those callbacks are now mandatory for full atomic support. v6: Fix commit message nit Sean noticed. Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Showing
Please register or sign in to comment