From: Ville Syrjala <ville.syrjala@linux.intel.com> To: dri-devel@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Subject: [PATCH 25/26] drm/i915: Try to probe DP++ dongles on DP++ downstream facing ports Date: Mon, 3 Feb 2020 17:13:42 +0200 [thread overview] Message-ID: <20200203151343.14378-26-ville.syrjala@linux.intel.com> (raw) In-Reply-To: <20200203151343.14378-1-ville.syrjala@linux.intel.com> From: Ville Syrjälä <ville.syrjala@linux.intel.com> In order to get accurate TMDS clocks limits for the DP++ ports we can try to probe the DP dual mode adapter registers. Unfortunately I've not yet seen a DP->DP++ branch device that would actually forward these i2c accesses to the dual mode dongle downstream. But we don't lose much by trying and maybe it'll work on some branch devices, if not now then maybe in the future. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> --- .../drm/i915/display/intel_display_types.h | 1 + drivers/gpu/drm/i915/display/intel_dp.c | 41 +++++++++++++++++++ 2 files changed, 42 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h index 0d135859e9d4..5cd052f55662 100644 --- a/drivers/gpu/drm/i915/display/intel_display_types.h +++ b/drivers/gpu/drm/i915/display/intel_display_types.h @@ -1316,6 +1316,7 @@ struct intel_dp { u8 max_bpc; bool ycbcr_444_to_420; } dfp; + struct intel_dp_dual_mode dp_dual_mode; }; enum lspcon_vendor { diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 3bf19d691fd5..5143c1b0fd92 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -608,6 +608,10 @@ intel_dp_mode_valid_downstream(struct intel_connector *connector, tmds_clock > intel_dp->dfp.max_tmds_clock) return MODE_CLOCK_HIGH; + if (intel_dp->dp_dual_mode.max_tmds_clock && + tmds_clock > intel_dp->dp_dual_mode.max_tmds_clock) + return MODE_CLOCK_HIGH; + return MODE_OK; } @@ -1762,6 +1766,8 @@ intel_dp_aux_init(struct intel_dp *intel_dp) aux_ch_name(dig_port->aux_ch), port_name(encoder->port)); intel_dp->aux.transfer = intel_dp_aux_transfer; + + intel_dp->dp_dual_mode.adapter = &intel_dp->aux.ddc; } bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp) @@ -1950,6 +1956,10 @@ static bool intel_dp_hdmi_tmds_clock_valid(struct intel_dp *intel_dp, tmds_clock > intel_dp->dfp.max_tmds_clock) return false; + if (intel_dp->dp_dual_mode.max_tmds_clock && + tmds_clock > intel_dp->dp_dual_mode.max_tmds_clock) + return false; + return true; } @@ -5850,6 +5860,35 @@ intel_dp_set_edid(struct intel_dp *intel_dp) intel_dp_update_dfp(intel_dp, edid); intel_dp_update_420(intel_dp); + if (drm_dp_downstream_is_tmds(intel_dp->dpcd, + intel_dp->downstream_ports, + edid)) { + /* + * Most branch devices don't seem to forward the + * DP dual mode i2c accesses to the dongle, so even + * when you have a type2 HDMI dongle with a high TMDS + * clock limit we may not be able to detect it :( + * To avoid users complaining about losing high + * resolution modes let's not assume type1 DVI + * dongle presence when the access fails. There + * doesn't seem to be any way to read the CONFIG1 + * pin state from the branch device. + */ + intel_dp_dual_mode_detect(connector, &intel_dp->dp_dual_mode, false); + + /* + * We drive LSPCON DP dual mode adaptors in PCON mode + * so we should just ignore the HDMI side of it. + */ + if (intel_dp->dp_dual_mode.type == DRM_DP_DUAL_MODE_LSPCON) { + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Ignoring LSPCON DP dual mode adaptor presence\n", + connector->base.base.id, + connector->base.name); + + intel_dp_dual_mode_reset(&intel_dp->dp_dual_mode); + } + } + if (edid && edid->input & DRM_EDID_INPUT_DIGITAL) { intel_dp->has_hdmi_sink = drm_detect_hdmi_monitor(edid); intel_dp->has_audio = drm_detect_monitor_audio(edid); @@ -5877,6 +5916,8 @@ intel_dp_unset_edid(struct intel_dp *intel_dp) intel_dp->dfp.ycbcr_444_to_420 = false; connector->base.ycbcr_420_allowed = false; + + intel_dp_dual_mode_reset(&intel_dp->dp_dual_mode); } static int -- 2.24.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Ville Syrjala <ville.syrjala@linux.intel.com> To: dri-devel@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] [PATCH 25/26] drm/i915: Try to probe DP++ dongles on DP++ downstream facing ports Date: Mon, 3 Feb 2020 17:13:42 +0200 [thread overview] Message-ID: <20200203151343.14378-26-ville.syrjala@linux.intel.com> (raw) In-Reply-To: <20200203151343.14378-1-ville.syrjala@linux.intel.com> From: Ville Syrjälä <ville.syrjala@linux.intel.com> In order to get accurate TMDS clocks limits for the DP++ ports we can try to probe the DP dual mode adapter registers. Unfortunately I've not yet seen a DP->DP++ branch device that would actually forward these i2c accesses to the dual mode dongle downstream. But we don't lose much by trying and maybe it'll work on some branch devices, if not now then maybe in the future. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> --- .../drm/i915/display/intel_display_types.h | 1 + drivers/gpu/drm/i915/display/intel_dp.c | 41 +++++++++++++++++++ 2 files changed, 42 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h index 0d135859e9d4..5cd052f55662 100644 --- a/drivers/gpu/drm/i915/display/intel_display_types.h +++ b/drivers/gpu/drm/i915/display/intel_display_types.h @@ -1316,6 +1316,7 @@ struct intel_dp { u8 max_bpc; bool ycbcr_444_to_420; } dfp; + struct intel_dp_dual_mode dp_dual_mode; }; enum lspcon_vendor { diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 3bf19d691fd5..5143c1b0fd92 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -608,6 +608,10 @@ intel_dp_mode_valid_downstream(struct intel_connector *connector, tmds_clock > intel_dp->dfp.max_tmds_clock) return MODE_CLOCK_HIGH; + if (intel_dp->dp_dual_mode.max_tmds_clock && + tmds_clock > intel_dp->dp_dual_mode.max_tmds_clock) + return MODE_CLOCK_HIGH; + return MODE_OK; } @@ -1762,6 +1766,8 @@ intel_dp_aux_init(struct intel_dp *intel_dp) aux_ch_name(dig_port->aux_ch), port_name(encoder->port)); intel_dp->aux.transfer = intel_dp_aux_transfer; + + intel_dp->dp_dual_mode.adapter = &intel_dp->aux.ddc; } bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp) @@ -1950,6 +1956,10 @@ static bool intel_dp_hdmi_tmds_clock_valid(struct intel_dp *intel_dp, tmds_clock > intel_dp->dfp.max_tmds_clock) return false; + if (intel_dp->dp_dual_mode.max_tmds_clock && + tmds_clock > intel_dp->dp_dual_mode.max_tmds_clock) + return false; + return true; } @@ -5850,6 +5860,35 @@ intel_dp_set_edid(struct intel_dp *intel_dp) intel_dp_update_dfp(intel_dp, edid); intel_dp_update_420(intel_dp); + if (drm_dp_downstream_is_tmds(intel_dp->dpcd, + intel_dp->downstream_ports, + edid)) { + /* + * Most branch devices don't seem to forward the + * DP dual mode i2c accesses to the dongle, so even + * when you have a type2 HDMI dongle with a high TMDS + * clock limit we may not be able to detect it :( + * To avoid users complaining about losing high + * resolution modes let's not assume type1 DVI + * dongle presence when the access fails. There + * doesn't seem to be any way to read the CONFIG1 + * pin state from the branch device. + */ + intel_dp_dual_mode_detect(connector, &intel_dp->dp_dual_mode, false); + + /* + * We drive LSPCON DP dual mode adaptors in PCON mode + * so we should just ignore the HDMI side of it. + */ + if (intel_dp->dp_dual_mode.type == DRM_DP_DUAL_MODE_LSPCON) { + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Ignoring LSPCON DP dual mode adaptor presence\n", + connector->base.base.id, + connector->base.name); + + intel_dp_dual_mode_reset(&intel_dp->dp_dual_mode); + } + } + if (edid && edid->input & DRM_EDID_INPUT_DIGITAL) { intel_dp->has_hdmi_sink = drm_detect_hdmi_monitor(edid); intel_dp->has_audio = drm_detect_monitor_audio(edid); @@ -5877,6 +5916,8 @@ intel_dp_unset_edid(struct intel_dp *intel_dp) intel_dp->dfp.ycbcr_444_to_420 = false; connector->base.ycbcr_420_allowed = false; + + intel_dp_dual_mode_reset(&intel_dp->dp_dual_mode); } static int -- 2.24.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-02-03 15:15 UTC|newest] Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-03 15:13 [PATCH 00/26] drm/i915: Pimp DP DFP handling Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 01/26] drm/i915: Nuke pre-production GLK HDMI w/a 1139 Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 02/26] drm/i915: Limit display Wa_1405510057 to gen11 Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 03/26] drm/i915: Drop WaDDIIOTimeout:glk Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 04/26] drm/i915: Add glk to intel_detect_preproduction_hw() Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 05/26] drm/dp: Include the AUX CH name in the debug messages Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 06/26] drm/i915/lspcon: Do not send infoframes to non-HDMI sinks Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 07/26] drm/dp: Define protocol converter DPCD registers Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 08/26] drm/dp: Define more downstream facing port caps Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 09/26] drm/i915: Reworkd DFP max bpc handling Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 10/26] drm/dp: Add helpers to identify downstream facing port types Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 11/26] drm/dp: Pimp drm_dp_downstream_max_bpc() Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 12/26] drm/dp: Redo drm_dp_downstream_max_clock() as drm_dp_downstream_max_dotclock() Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 13/26] drm/i915: Reworkd DP DFP clock handling Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 14/26] drm/i915: Dump downstream facing port caps Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 15/26] drm/dp: Add drm_dp_downstream_{min,max}_tmds_clock() Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] [PATCH 15/26] drm/dp: Add drm_dp_downstream_{min, max}_tmds_clock() Ville Syrjala 2020-02-03 15:13 ` [PATCH 16/26] drm/i915: Deal with TMDS DFP clock limits Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 17/26] drm/i915: Configure DP 1.3+ protocol converted HDMI mode Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 18/26] drm/dp: Add drm_dp_downstream_mode() Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 19/26] drm/i915: Handle downstream facing ports w/o EDID Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 20/26] drm/i915: Extract intel_hdmi_has_audio() Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 21/26] drm/i915: DP->HDMI TMDS clock limits vs. deep color Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 22/26] drm/dp: Add helpers for DFP YCbCr 4:2:0 handling Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 23/26] drm/i915: Do YCbCr 444->420 conversion via DP protocol converters Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` [PATCH 24/26] drm/i915: Decouple DP++ from the HDMI code Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-03 15:13 ` Ville Syrjala [this message] 2020-02-03 15:13 ` [Intel-gfx] [PATCH 25/26] drm/i915: Try to probe DP++ dongles on DP++ downstream facing ports Ville Syrjala 2020-02-03 15:13 ` [PATCH 26/26] drm/i915: Try to frob the TMDS buffer enable knob on DP++ dongles on DP DFPs Ville Syrjala 2020-02-03 15:13 ` [Intel-gfx] " Ville Syrjala 2020-02-04 19:20 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Pimp DP DFP handling Patchwork
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200203151343.14378-26-ville.syrjala@linux.intel.com \ --to=ville.syrjala@linux.intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.