[PATCH 1/5] drm/rockchip: vop2: Add high color depth support

Cristian Ciocaltea cristian.ciocaltea at collabora.com
Mon Jul 21 23:16:26 PDT 2025


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 at collabora.com> wrote:
>> Take the bits per color channel into consideration when computing DCLK
>> rate.
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.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 at 60Hz, 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



More information about the Linux-rockchip mailing list