From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1CCDF2FD69D; Sun, 20 Sep 2026 09:44:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789897455; cv=none; b=H+l5z+8jqT6VRUg/EHWBuF2CktUAH1vEtI77dIsKqkD7pm+ReKOWYu7PcZVdmNyzMJTBFzWpI9Tfh2tY7gz2sZbg0x6rnTuuI0J2SJ8vSSztJjhozJoTtKXKoxQLwf1D+SsG8mZYFrriBnq1waWztB1kIjZw+ySLsa9Pl+snbuQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789897455; c=relaxed/simple; bh=VaCHIbqayKHpuRvZbdiid0ApzeVrHRM1euobbTzlPRc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LzeM64xDbDwXADnL+ClCgDs+aNxqyVXhMqzGuQcJYK99DUjDB8AlFiuh/icn2DdDKquIMCDsTdj2JiBJlAwEQeVwvxvwFrhouGkCdhF5uCAgFtsvbcftluF+fXqiP+oRggbxv+EX67/6/vjGpv4cvmZj3HBZ3Ewho68eUYbXbvk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=peMEUP+Y; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="peMEUP+Y" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1789897452; bh=VaCHIbqayKHpuRvZbdiid0ApzeVrHRM1euobbTzlPRc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=peMEUP+Yy1BaYtTRZVdeYhHiwtL+emnJv+XSfsBsP0TW2HZHy3+OOhAonCgfrNZ6S BzizMfHPTWfyeI+HWchhwSCwHYtP3BWE8ZQ0gXX8OF6XatXDvwNE+RbWihJ3fJTl3a Q4Wk6lz2+tya3mYVne4ryXQSzpRjYYmWOzIyTwX6Bmjze5DwzXuBceSOJu7t6YcafJ eu/oHb/IqBziro+swTA9msKOM8PibldK5ml919xoioItvmhl8XFD1XGPBXsbLp3dd/ WZca0ZjGKg1lzihFUT7mcbsuP/XtjoIF/h5A5Y1pzj5468Gt/MTI8LI1v7S3g0HuGF /T1UTs74TSTpw== Received: from [100.64.0.241] (unknown [100.64.0.241]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: cristicc) by bali.collaboradmins.com (Postfix) with ESMTPSA id 4598517E00C9; Sun, 20 Sep 2026 11:44:09 +0200 (CEST) Message-ID: <9e21c5c3-f8e6-4343-b4cc-52c9e84316ef@collabora.com> Date: Sun, 20 Sep 2026 12:44:08 +0300 Precedence: bulk X-Mailing-List: linux-fbdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 00/74] Add HDMI 2.0 support to DW HDMI QP TX To: Maxime Ripard Cc: Maarten Lankhorst , Thomas Zimmermann , David Airlie , Simona Vetter , Dave Stevenson , Dmitry Baryshkov , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Luca Ceresoli , Chen-Yu Tsai , Samuel Holland , =?UTF-8?Q?Ma=C3=ADra_Canal?= , Raspberry Pi Kernel Maintenance , Raphael Gallais-Pou , Sandy Huang , =?UTF-8?Q?Heiko_St=C3=BCbner?= , Andy Yan , Algea Cao , Daniel Stone , Liu Ying , Phong LE , Helge Deller , kernel@collabora.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-rockchip@lists.infradead.org, linux-fbdev@vger.kernel.org, Dmitry Baryshkov , Sashiko , Diederik de Haas , Maud Spierings References: <20260901-dw-hdmi-qp-scramb-v11-0-bc12954a0688@collabora.com> Content-Language: en-US From: Cristian Ciocaltea In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Maxime, On 9/8/26 12:48 PM, Maxime Ripard wrote: > Hi, > > On Tue, Sep 01, 2026 at 09:50:24PM +0300, Cristian Ciocaltea wrote: >> Enable HDMI 2.0 display modes (e.g. 4K@60Hz) on the Synopsys DW HDMI QP >> TX controller, as found in Rockchip RK3576 & RK3588 SoCs, by adding SCDC >> management for high TMDS clock ratio and scrambling. Since SCDC state >> is lost on sink disconnects, the bridge driver needs to trigger a CRTC >> reset during connector detection. >> >> To support this at the DRM infrastructure level, the series first >> introduces the HDMI version enum, then prepares for changing the >> signature of drmm_connector_hdmi_init(), i.e. dropping the vendor, >> product, supported_formats and max_bpc arguments, which are being moved >> into struct drm_connector_hdmi_funcs, by temporarily renaming the helper >> to drmm_connector_hdmi_ini2(). This lets the new signature be >> introduced under the original name while callers are converted >> incrementally. Note the transitional name matches the original's length >> so continuation-line arguments stay aligned to the opening parenthesis, >> keeping the diff to the identifier itself and avoiding re-alignment >> churn. >> >> Appending more HDMI-specific arguments to the init function would not >> scale well, hence the hdmi_funcs struct is extended with new fields: >> supported_hdmi_ver, supported_tmds_char_rate. These are used to >> infer and/or limit the maximum TMDS character rate permitted for the >> connector. >> >> Patches 6-11 build the connector and bridge scrambling infrastructure on >> top: the connector scrambler callbacks/flags, the scdc-helper >> additions (connector-prefixed debug macro and SCDC version helper), and >> the HDMI scrambling management helpers including SCDC source-version >> advertisement. >> >> Patches 12-25 wires this up through the hdmi-state-helper and bridge >> connector layers: source TMDS rate validation, hotplug SCDC state sync >> and the scrambling requirement, new source-side scrambling bridge ops, >> the switch to a cached-status, atomic-aware .detect_ctx() connector >> helper, and finally hooking up the HDMI 2.0 scrambler callbacks. >> >> The SCDC scrambling feature itself is implemented in the DW HDMI QP >> bridge driver, alongside i2c error-message rate limiting, >> .enable_hpd()/.disable_hpd() PHY ops and a dw_hdmi_qp_hpd_notify() >> helper (patches 26-30). >> >> Patches 31-41 cover the Rockchip platform driver and HPD handling: bug >> fixes, minor cleanups, avoiding spurious HDP IRQ wakeups, masking the >> RK3576 HPD IRQ in io_init, implementing the .{enable|disable}_hpd() PHY >> ops, switching HPD reports to dw_hdmi_qp_hpd_notify() to restrict events >> to the affected connector, dropping the now-unused .setup_hpd() PHY op. >> >> Patches 42-48 convert VC4 HDMI to the common infrastructure as a proof >> of reuse: adopting the shared TMDS char rate constants, switching to >> drm_hdmi_mode_needs_scrambling() and force_ctx(), proper -EDEADLK >> handling, and replacing the driver-local scrambling implementation with >> the common SCDC scrambling helpers. >> >> Patches 50-57 advertise supported version for all HDMI >> connectors/bridges, except the MediaTek HDMI driver (for now), as it >> requires non-trivial changes: there's a core library shared between two >> drivers, one being HDMI 2.0 compliant. >> >> Patches 58-67 add KUnit tests: HDMI caps-based init coverage and >> source-side scrambler validation for the connector, conversion of >> hdmi_state_helper to the new drmm_connector_hdmi_init() with >> max_tmds_char_rate validation, a new 4K@60Hz 600MHz TMDS EDID, >> source-side scrambling decision coverage, and conformity fixes for the >> existing 1080p+4K YUV420 200MHz and 4K RGB/YUV 340MHz test EDID blobs. >> >> Patches 68-71 remove the now unused drmm_connector_hdmi_ini2() helper >> and redundant hdmi fields from connector structs: vendor, product, >> supported_formats and max_bpc. >> >> Eventually patches 72-74 consolidate SPD InfoFrame handling of >> vendor/product. >> >> This has been tested on the following boards: >> >> * Radxa ROCK 5B (RK3588) >> * Radxa ROCK 4D (RK3576) >> * Raspberry Pi 5 Model B Rev 1.1 (BCM2712 D0) > > This series is getting a bit insane. You have preliminary patches that > have been reviewed/acked already, you should merge them, and possibly > split the rest into preliminary series. Thanks for the additional reviews, and sorry for my late reply - I've been on leave and traveling. I've merged the preliminary patches and will handle the split upon my return, in about a week. I plan to send separate series for vc4, dw-hdmi-qp, the rest of the bridge drivers, kunit & final cleanup. Regards, Cristian