From patchwork Mon Feb 3 15:13:42 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?VmlsbGUgU3lyasOkbMOk?= X-Patchwork-Id: 11362971 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E587E138D for ; Mon, 3 Feb 2020 15:15:07 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CE17B21927 for ; Mon, 3 Feb 2020 15:15:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CE17B21927 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 036836EC52; Mon, 3 Feb 2020 15:15:06 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id C18336EC39; Mon, 3 Feb 2020 15:15:03 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Feb 2020 07:15:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,398,1574150400"; d="scan'208";a="278765805" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by FMSMGA003.fm.intel.com with SMTP; 03 Feb 2020 07:15:00 -0800 Received: by stinkbox (sSMTP sendmail emulation); Mon, 03 Feb 2020 17:15:00 +0200 From: Ville Syrjala To: dri-devel@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 Message-Id: <20200203151343.14378-26-ville.syrjala@linux.intel.com> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20200203151343.14378-1-ville.syrjala@linux.intel.com> References: <20200203151343.14378-1-ville.syrjala@linux.intel.com> MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" From: Ville Syrjälä 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ä --- .../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