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

[Andy Yan]

Hello Cristian,

在 2025-07-22 14:16:26，"Cristian Ciocaltea" <cristian.ciocaltea at collabora.com> 写道：
>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.

What I want to emphasize is that on the vop/crtc side, what we should be concerned about is mode -> clock, 
not the HDMI PHY clock. The HDMI PHY clock is something that the HDMI bridge or the HDMI PHY driver needs to pay attention to.

This patch works just because currently, on RK3576 and RK3588, the HDMI PHY PLL can be used as the dclk source for the vop.
After correctly setting CMN_REG0086, it can precisely adjust the HDMI HPY PLL clock adjusted according to the bpc further to
the frequency of mode->clock, and then use it as the dclk for the vop.
However, we also need to be aware of the following situations:

1) When we are using HDMI, we can still choose the system PLL instead of the HDMI PHY PLL as
    the clock source for dclk. In this case, this patch will cause incorrect mode->clock.
2)  When we are using HDMI above the 4K60 mode(4K120), we can only use the system PLL instead
     of the HDMIPHY PLL as the clock source for the vop dclk,  this patch will cause incorrect mode->clock.
3) For RK3576 and RK3588,  interfaces such as DP, eDP, and DSI also support 10-bit mode. 
    However, in most cases, they will choose the system PLL as the vop dclk clock source,this patch will cause incorrect mode->clock.
4) There are also other platforms, such as RK3568, even for HDMI , it still uses the system PLL as the dclk clock source for vop.
     this patch will cause incorrect mode->clock.


>
>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