From 2e2b96ef7a9b71e1bf08439e363c18cf700bafec Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Wed, 8 Nov 2017 21:30:07 +0100 Subject: 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 Reviewed-by: Manasi Navare Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20171108203007.12274-1-daniel.vetter@ffwll.ch --- include/drm/drm_connector.h | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'include/drm/drm_connector.h') diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index b34904dc8b9b..b81b7fb846f9 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -699,7 +699,6 @@ struct drm_cmdline_mode { * @force: a DRM_FORCE_ 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 */ -- cgit v1.2.1 From f1781e9bb2dd2305d8d7ffbede1888ae22119557 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= Date: Mon, 13 Nov 2017 19:04:19 +0200 Subject: drm/edid: Allow HDMI infoframe without VIC or S3D MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from 3D to 2D mode in a timely fashion if the source simply stops sending the HDMI infoframe. The suggested workaround is to keep sending the infoframe even when strictly not necessary (ie. no VIC and no S3D). HDMI 1.4 does allow for this behaviour, stating that sending the infoframe is optional in this case. The infoframe was first specified in HDMI 1.4, so in theory sinks predating that may not appreciate us sending an uknown infoframe their way. To avoid regressions let's try to determine if the sink supports the infoframe or not. Unfortunately there's no direct way to do that, so instead we'll just check if we managed to parse any HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the sink will accept the infoframe. Also if the EDID contains the HDMI 2.0 HDMI Forum VSDB we can assume the sink is prepared to receive the infoframe. v2: Fix getting has_hdmi_infoframe from display_info Always fail constructing the infoframe if the display possibly can't handle it Cc: Shashank Sharma Cc: Andrzej Hajda Cc: Laurent Pinchart Signed-off-by: Ville Syrjälä Reviewed-by: Shashank Sharma Link: https://patchwork.freedesktop.org/patch/msgid/20171113170427.4150-3-ville.syrjala@linux.intel.com --- include/drm/drm_connector.h | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'include/drm/drm_connector.h') diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index 2b97d1e28f60..1543212b0449 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -269,6 +269,11 @@ struct drm_display_info { */ bool dvi_dual; + /** + * @has_hdmi_infoframe: Does the sink support the HDMI infoframe? + */ + bool has_hdmi_infoframe; + /** * @edid_hdmi_dc_modes: Mask of supported hdmi deep color modes. Even * more stuff redundant with @bus_formats. -- cgit v1.2.1