drm: Update docs for legacy kms state

Point at the equivalent atomic state and explain that atomic drivers
shouldn't really depend upon legacy state.

Motivated by questions from Manasi about how this all is supposed to
work.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171108203007.12274-1-daniel.vetter@ffwll.ch
This commit is contained in:
Daniel Vetter 2017-11-08 21:30:07 +01:00
parent 71469385db
commit 2e2b96ef7a
4 changed files with 28 additions and 5 deletions

View File

@ -907,6 +907,12 @@ disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state)
*
* Drivers can use this for building their own atomic commit if they don't have
* a pure helper-based modeset implementation.
*
* Since these updates are not synchronized with lockings, only code paths
* called from &drm_mode_config_helper_funcs.atomic_commit_tail can look at the
* legacy state filled out by this helper. Defacto this means this helper and
* the legacy state pointers are only really useful for transitioning an
* existing driver to the atomic world.
*/
void
drm_atomic_helper_update_legacy_modeset_state(struct drm_device *dev,

View File

@ -699,7 +699,6 @@ struct drm_cmdline_mode {
* @force: a DRM_FORCE_<foo> state for forced mode sets
* @override_edid: has the EDID been overwritten through debugfs for testing?
* @encoder_ids: valid encoders for this connector
* @encoder: encoder driving this connector, if any
* @eld: EDID-like data, if present
* @latency_present: AV delay info from ELD, if found
* @video_latency: video latency info from ELD, if found
@ -869,7 +868,13 @@ struct drm_connector {
#define DRM_CONNECTOR_MAX_ENCODER 3
uint32_t encoder_ids[DRM_CONNECTOR_MAX_ENCODER];
struct drm_encoder *encoder; /* currently active encoder */
/**
* @encoder: Currently bound encoder driving this connector, if any.
* Only really meaningful for non-atomic drivers. Atomic drivers should
* instead look at &drm_connector_state.best_encoder, and in case they
* need the CRTC driving this output, &drm_connector_state.crtc.
*/
struct drm_encoder *encoder;
#define MAX_ELD_BYTES 128
/* EDID bits */

View File

@ -88,7 +88,6 @@ struct drm_encoder_funcs {
* @head: list management
* @base: base KMS object
* @name: human readable name, can be overwritten by the driver
* @crtc: currently bound CRTC
* @bridge: bridge associated to the encoder
* @funcs: control functions
* @helper_private: mid-layer private data
@ -166,6 +165,11 @@ struct drm_encoder {
*/
uint32_t possible_clones;
/**
* @crtc: Currently bound CRTC, only really meaningful for non-atomic
* drivers. Atomic drivers should instead check
* &drm_connector_state.crtc.
*/
struct drm_crtc *crtc;
struct drm_bridge *bridge;
const struct drm_encoder_funcs *funcs;

View File

@ -474,8 +474,6 @@ enum drm_plane_type {
* @format_types: array of formats supported by this plane
* @format_count: number of formats supported
* @format_default: driver hasn't supplied supported formats for the plane
* @crtc: currently bound CRTC
* @fb: currently bound fb
* @old_fb: Temporary tracking of the old fb while a modeset is ongoing. Used by
* drm_mode_set_config_internal() to implement correct refcounting.
* @funcs: helper functions
@ -512,7 +510,17 @@ struct drm_plane {
uint64_t *modifiers;
unsigned int modifier_count;
/**
* @crtc: Currently bound CRTC, only really meaningful for non-atomic
* drivers. Atomic drivers should instead check &drm_plane_state.crtc.
*/
struct drm_crtc *crtc;
/**
* @fb: Currently bound framebuffer, only really meaningful for
* non-atomic drivers. Atomic drivers should instead check
* &drm_plane_state.fb.
*/
struct drm_framebuffer *fb;
struct drm_framebuffer *old_fb;