From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=192.198.163.13 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793360201; b=btTY6mDegIgHJBy7EfMsuMbln7dZFeweTtQj2IM0O13mPOIKuNkCCoUJeIoE00V1aYuD JU/OYmwPSdxVCKfbIn/qP9ZiooEzk3EVwJVzf7Lkhs8rdvFBXINF1Rtiga14E4So6jM0x O0OWP9kORqiUR34cm7IGj3y9UBB5Xe9PpJocS5xG7QTzsxO1PQadvYhNUjiLJnJqYa/9u FfP6LbHoC9TdQFT7F04T9WbX7ZmMcGSl+nZrHd0EGx5Rb4mbdlXRsDRpYASCdwAXfH+Wi 7qfphg0Wni8sykXDOlO3h5dZk7CYa+z6pKou0FNeGJt/4SNq/ecWnWf2RCDNtUPrfIg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793360201; h=DMARC-Filter:DKIM-Signature:X-CSE-ConnectionGUID:X-CSE-MsgGUID: X-IronPort-AV:X-IronPort-AV:Received:X-CSE-ConnectionGUID: X-CSE-MsgGUID:X-ExtLoop1:X-IronPort-AV:Received:From:To:Cc:Subject: In-Reply-To:Organization:References:Date:Message-ID:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=8QuubPiuk6wEOliVDccBxjXQ7fh0FoVKqkHUK2T+A6E=; b=AKTgqsUkK3BStqa52FE48gn5HFCeAHsIqVVWlkR5nP5o1HXuyAEREK+o0NftVuLt2IqW M6Vhp+j67b/h8nMk4l8PWUQKB+tCM/VhXfDo+XA9Qtz48QQ84IB0AufW/I0t402qxGy1e anh/TAhVzz5PKAbXAGZBtDgUkmyCuRjZX1ixtEgoJZOz+SWwFBNpMqRZnXDy+cpNNjuoP 5SOis/0KnuzOWoT8BP7uIvNRjDMoPMMUVZ3xiEIfcC6Gz9XYwl0t6Dzc2Z2I0Qas1t4en 4k//VPzUOgk8hZSObIyy6Gq17CaxkKD88OfIwbhodbQTl4tAXAUL3TvSbo8BT8lRsRw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=Aa+n9PXJ; arc=none smtp.remote-ip=192.198.163.13 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BD988606A31C for ; Fri, 30 Oct 2026 11:36:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org BD988606A31C Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=Aa+n9PXJ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1793360200; x=1824896200; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=aadIw4rhulzpa6Y/ZdQ+M80PL9e0mgGB24qkPVmslLE=; b=Aa+n9PXJza882rwIYAPcQ2N9oVgbsrZcR8vz7xof4y8jrlVLVCnPYhXf uAaffLWa+CfL4VHSgGxPeBxRWOGukgge/japOwATIqVLAVIQn2+MLwG7F QwzxnC98pZZ+Jr33QF0/b8wt0Sau9egdltc8y5pWmXYRZ9sBejKc5Q4rd oKla2IjYUEouabzLcwypuRdZ2FDJLWmGU9T9Fz3hoc5kbLDeVS6T0ry/Z b4AfHInMtrzRMfpqgxVeEwZb9bp9X7FvBbN0vM5/+P2NjMvveFY1WGYzW 9KxQcAACoNv5MgGKGk6XyQ/sdxliUvsbtiFvJ/7/J6ReZG0BZ6HgoyTLG Q==; X-CSE-ConnectionGUID: s8U8hQG2QNiyZiwMhrKgqw== X-CSE-MsgGUID: ivtab1CIQ+SnsAhKbBe5Kg== X-IronPort-AV: E=McAfee;i="6800,10657,11950"; a="2115249" X-IronPort-AV: E=Sophos;i="6.27,186,1787036400"; d="scan'208";a="2115249" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Oct 2026 04:36:39 -0700 X-CSE-ConnectionGUID: g+orv7JlT+urDFKI9tyaUA== X-CSE-MsgGUID: xJVcYvSyRoGD2TgzkWSP4w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,186,1787036400"; d="scan'208";a="5509613" Received: from ijarvine-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.244.13]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Oct 2026 04:36:34 -0700 From: Jani Nikula To: Ville =?utf-8?B?U3lyasOkbMOk?= , Dmytro Malovanyi Cc: dri-devel@lists.freedesktop.org, Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Harry Wentland , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Luca Ceresoli , Patrik Jakobsson , Lyude Paul , Danilo Krummrich , nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/5] drm/dp: Always use enhanced framing for DPCD r1.2+ In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs Bertel Jungin Aukio 5, 02600 Espoo, Finland References: <20261029101826.72773-1-dmitrymalovanyy@gmail.com> <20261029101826.72773-2-dmitrymalovanyy@gmail.com> Date: Fri, 30 Oct 2026 13:36:31 +0200 Message-ID: <59106a36510e33e851f76c877f41952b11a8c774@intel.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, 30 Oct 2026, Ville Syrj=C3=A4l=C3=A4 wrote: > On Thu, Oct 29, 2026 at 11:18:22AM +0100, Dmytro Malovanyi wrote: >> DP 1.2 section 2.2.1.1 says "An upstream device interoperating with a >> downstream device with DPCD Revision of 1.2 or higher must enable >> Enhanced Framing Mode". So for r1.2+ the DPCD revision is enough, the >> DP_ENHANCED_FRAME_CAP bit does not need to be checked. >>=20 >> Some sinks get this bit wrong. The Xiaomi Monitor A24i (P24FBA-RAGL) >> sets it in the base receiver caps, but clears it in the extended >> receiver caps at 0x2200, which are the ones we use: >>=20 >> base: 12 0a c4 01 01 00 01 80 02 00 06 00 00 00 81 >> extended: 14 0a 44 00 01 00 01 80 02 02 06 00 00 00 81 >>=20 >> Through a USB4 dock (CalDigit Element 5) the link trains without >> enhanced framing (0x202-0x204: 77 77 81), but the sink never syncs to >> the stream (SINK_STATUS 0x205: 00) and shows "No signal". Forcing RBR >> does not change it. Connected directly to the laptop the same sink >> syncs without enhanced framing, at RBR, HBR and HBR2. >>=20 >> Make drm_dp_enhanced_frame_cap() return true for DPCD r1.2+. This >> changes behaviour for every driver using the helper, but only for sinks >> which already violate the spec by not setting the bit. >>=20 >> Tested on i915 (Arrow Lake-U), with the dock the link now uses enhanced >> framing (0x101: 84) and the sink syncs (0x205: 03). >>=20 >> Fixes: a1d926527b79 ("drm/i915: implement EXTENDED_RECEIVER_CAPABILITY_F= IELD_PRESENT") >> Cc: stable@vger.kernel.org >> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/17719 >> Suggested-by: Jani Nikula >> Signed-off-by: Dmytro Malovanyi >> --- >> include/drm/display/drm_dp_helper.h | 4 ++++ >> 1 file changed, 4 insertions(+) >>=20 >> diff --git a/include/drm/display/drm_dp_helper.h b/include/drm/display/d= rm_dp_helper.h >> index 5b05a7fbe..4f20f60db 100644 >> --- a/include/drm/display/drm_dp_helper.h >> +++ b/include/drm/display/drm_dp_helper.h >> @@ -160,6 +160,10 @@ drm_dp_max_lane_count(const u8 dpcd[DP_RECEIVER_CAP= _SIZE]) >> static inline bool >> drm_dp_enhanced_frame_cap(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) >> { >> + /* DP 1.2 2.2.1.1: enhanced framing is mandatory for DPCD r1.2+ */ > > DP_ENHANCED_FRAME_CAP is also mandatory so I think this needs > a bit more detailed explanation. Commit message not enough? I think the wording in the specs suggest that with DPCD r1.2+ you should just enable enhanced framing regardless of the cap. BR, Jani. > >> + if (dpcd[DP_DPCD_REV] >=3D 0x12) >> + return true; >> + >> return dpcd[DP_DPCD_REV] >=3D 0x11 && >> (dpcd[DP_MAX_LANE_COUNT] & DP_ENHANCED_FRAME_CAP); >> } >> --=20 >> 2.50.1 (Apple Git-155) --=20 Jani Nikula, Intel