From: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
To: "Sandy Huang" <hjc@rock-chips.com>,
"Heiko Stübner" <heiko@sntech.de>,
"Andy Yan" <andy.yan@rock-chips.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"Daniel Stone" <daniels@collabora.com>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"Andrzej Hajda" <andrzej.hajda@intel.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Robert Foss" <rfoss@kernel.org>,
"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
"Jonas Karlman" <jonas@kwiboo.se>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Luca Ceresoli" <luca.ceresoli@bootlin.com>
Cc: kernel@collabora.com, Andy Yan <andyshrk@163.com>,
dri-devel@lists.freedesktop.org,
linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Igor Paunovic <royalnet026@gmail.com>
Subject: [PATCH v4 08/14] drm/rockchip: vop2: Avoid DCLK source switch for 10-bit YUV422 output
Date: Thu, 03 Sep 2026 01:54:15 +0300 [thread overview]
Message-ID: <20260903-dw-hdmi-qp-yuv-v4-8-fb45bf4147eb@collabora.com> (raw)
In-Reply-To: <20260903-dw-hdmi-qp-yuv-v4-0-fb45bf4147eb@collabora.com>
Currently the color depth is always factored into the DCLK source
decision for HDMI output, which can break certain modes when operating
with depths greater than 8 bpc.
When the required transmission rate exceeds the 600 MHz limit of the
HDMI PHY PLL, e.g. for 4K@60Hz 10-bit RGB output, VOP2 will normally
fall back to using the less accurate system CRU as a DCLK source,
assuming HDMI 2.1 FRL is supported by the pipeline, otherwise the mode
will be rejected. For YUV420 output format this never happens, as it
uses half of the RGB bandwidth, hence the rate remains within the PHY
PLL limits.
On the other hand, YUV422 always transmits two 12-bit components per
clock cycle, regardless of the color depth, which from a clock-rate
perspective is equivalent to three 8-bit RGB components. For example,
4K@60Hz 10-bit YUV422 requires the same bandwidth as 4K@60Hz 8-bit RGB,
typically 594 MHz. However, VOP2 wrongly assumes it needs 742.5 MHz
(594 * 10 / 8) and ends up switching the DCLK source.
As a consequence, the modes requiring uncommon pixel clocks, such as
those corresponding to fractional refresh rates, will fail. An example
is 3840x2160@59.94Hz, which would likely rely on the 593.407 MHz clock
rate unsupported by the system CRU.
Note this only affects YUV422 with color depths greater than 8 bpc; for
8-bit YUV422 the 8/bpc factor is unity and the bandwidth check is
already correct.
Prevent the incorrect switches of DCLK source to system CRU for YUV422
output format by forcing 8 bpc when checking the bandwidth.
Tested-by: Igor Paunovic <royalnet026@gmail.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 21b8a5960086..4b4346cf38cd 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -1954,7 +1954,15 @@ static void vop2_crtc_atomic_enable(struct drm_crtc *crtc,
* to 4K@60Hz, if available, otherwise keep using the system CRU.
*/
if (vop2->pll_hdmiphy0 || vop2->pll_hdmiphy1) {
- unsigned int bpc = vcstate->output_bpc ?: 8;
+ /*
+ * YUV422 always transmits two 12-bit components per clock
+ * cycle, regardless of the color depth, which from a rate
+ * perspective is equivalent to three 8-bit RGB components.
+ * Force 8 bpc here so the bandwidth check reflects the actual
+ * TMDS rate and avoids an unnecessary DCLK source switch.
+ */
+ unsigned int bpc = vcstate->output_mode == ROCKCHIP_OUT_MODE_YUV422 ?
+ 8 : (vcstate->output_bpc ?: 8);
unsigned long max_dclk = DIV_ROUND_CLOSEST_ULL(VOP2_MAX_DCLK_RATE * 8, bpc);
if (clock <= max_dclk) {
--
2.55.0
next prev parent reply other threads:[~2026-09-02 22:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 22:54 [PATCH v4 00/14] Support 10-bit YUV422 and 8/10-bit YUV420 color format on DW HDMI QP Cristian Ciocaltea
2026-09-02 22:54 ` [PATCH v4 01/14] dt-bindings: display: vop2: Add missing reset properties Cristian Ciocaltea
2026-09-02 22:54 ` [PATCH v4 02/14] drm/rockchip: vop2: Fix resource leak on vop2_enable() error path Cristian Ciocaltea
2026-09-02 23:03 ` sashiko-bot
2026-09-02 22:54 ` [PATCH v4 03/14] drm/rockchip: vop2: Balance state on atomic_enable() error paths Cristian Ciocaltea
2026-09-02 22:54 ` [PATCH v4 04/14] drm/rockchip: vop2: Send pending event when atomic_enable() fails Cristian Ciocaltea
2026-09-02 22:54 ` [PATCH v4 05/14] drm/rockchip: vop2: Avoid division by zero when computing max_dclk Cristian Ciocaltea
2026-09-02 22:54 ` [PATCH v4 06/14] drm/rockchip: vop2: Fix VOP2_MAX_DCLK_RATE overflow on 32-bit Cristian Ciocaltea
2026-09-02 23:01 ` sashiko-bot
2026-09-02 22:54 ` [PATCH v4 07/14] drm/rockchip: vop2: Reset AXI and DCLK to improve robustness Cristian Ciocaltea
2026-09-02 22:54 ` Cristian Ciocaltea [this message]
2026-09-02 22:54 ` [PATCH v4 09/14] drm/rockchip: vop2: Consolidate HDMI PHY PLL clock parent switch Cristian Ciocaltea
2026-09-02 23:01 ` sashiko-bot
2026-09-02 22:54 ` [PATCH v4 10/14] drm/rockchip: vop2: Switch to enum vop_csc_format Cristian Ciocaltea
2026-09-02 22:54 ` [PATCH v4 11/14] drm/bridge: dw-hdmi-qp: Log resolution and refresh rate in atomic_enable() Cristian Ciocaltea
2026-09-02 22:54 ` [PATCH v4 12/14] drm/rockchip: dw_hdmi_qp: Support 10-bit YUV422 output format Cristian Ciocaltea
2026-09-02 23:06 ` sashiko-bot
2026-09-02 22:54 ` [PATCH v4 13/14] drm/rockchip: dw_hdmi_qp: Enable YUV420 " Cristian Ciocaltea
2026-09-02 23:08 ` sashiko-bot
2026-09-02 22:54 ` [PATCH v4 14/14] arm64: dts: rockchip: Add RK3588 VOP2 resets Cristian Ciocaltea
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=20260903-dw-hdmi-qp-yuv-v4-8-fb45bf4147eb@collabora.com \
--to=cristian.ciocaltea@collabora.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=andy.yan@rock-chips.com \
--cc=andyshrk@163.com \
--cc=conor+dt@kernel.org \
--cc=daniels@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=heiko@sntech.de \
--cc=hjc@rock-chips.com \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=kernel@collabora.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=luca.ceresoli@bootlin.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=p.zabel@pengutronix.de \
--cc=rfoss@kernel.org \
--cc=robh@kernel.org \
--cc=royalnet026@gmail.com \
--cc=s.hauer@pengutronix.de \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox