[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c5624dad-93cb-4cc3-88ad-808dcc43274d@collabora.com>
Date: Tue, 22 Jul 2025 09:16:26 +0300
From: Cristian Ciocaltea <cristian.ciocaltea@...labora.com>
To: Andy Yan <andyshrk@....com>, Algea Cao <algea.cao@...k-chips.com>
Cc: Sandy Huang <hjc@...k-chips.com>, Heiko Stübner
<heiko@...ech.de>, Andy Yan <andy.yan@...k-chips.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Andrzej Hajda <andrzej.hajda@...el.com>,
Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
Jonas Karlman <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>,
kernel@...labora.com, dri-devel@...ts.freedesktop.org,
linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/5] drm/rockchip: vop2: Add high color depth support
Hi Andy,
On 7/22/25 5:24 AM, Andy Yan wrote:
>
> Hello Cristian,
>
> At 2025-07-22 01:39:04, "Cristian Ciocaltea" <cristian.ciocaltea@...labora.com> wrote:
>> Take the bits per color channel into consideration when computing DCLK
>> rate.
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@...labora.com>
>> ---
>> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>> index 186f6452a7d359f079662bc580850929632ea8fe..a714bcbb02de16267e7febbaeb1eb270c70aaef2 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>> @@ -1731,6 +1731,9 @@ static void vop2_crtc_atomic_enable(struct drm_crtc *crtc,
>> clock *= 2;
>> }
>>
>> + if (vcstate->output_bpc > 8)
>> + clock = DIV_ROUND_CLOSEST(clock * vcstate->output_bpc, 8);
>
>
> This seems not right, regardless of the value of bpc, the dclk of VOP must be
> consistent with mode->crtc_clock.
> If the dclk of VOP is increased in accordance with the BPC ratio here, then the refresh rate of VOP will also increase proportionally.
> This would be inconsistent with the timing described in the mode.
> For a hight color depth, the frequency needs to be increased for the HDMI PHY's clock.
The HDMI PHY's clock is actually computed at HDMI connector framework level
[1], taking into account the current bpc value, which is determined as part
of hdmi_compute_config() [2].
That means conn_state->hdmi.tmds_char_rate in
dw_hdmi_qp_rockchip_encoder_atomic_check() does already include the bpc
related adjustment, and we pass that directly to the PHY via
phy_configure(). Note there's still the need to handle bpc separately via
phy_configure_opts in order to setup CMN_REG(0086) [3].
Since VOP2 switches to PHY PLL as DCLK source for modes up to 4K@...z, it
needs to take color depth into account, to keep them in sync. As a matter
of fact, the clock adjustment in VOP2 is mainly necessary for legacy
reasons, since HDPTX PHY allowed changing TMDS char rate via the Common
Clock Framework API. We landed a proper solution for that via the HDMI PHY
API, hence the plan would be to make CCF API readonly after the switch to
PHY API is completed, which means VOP2 shouldn't deal anymore with clock
calculations when using the PHY PLL as DCLK source.
Regardless, I should probably move this clock adjustment to the conditional
block handling DCLK source switch.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/display/drm_hdmi_state_helper.c?h=v6.16-rc7#n525
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/display/drm_hdmi_state_helper.c?h=v6.16-rc7#n608
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c?h=v6.16-rc7#n1034
Powered by blists - more mailing lists