Hello Cristian,

在 2025-07-22 14:16:26,"Cristian Ciocaltea" <cristian.ciocal...@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.ciocal...@collabora.com> wrote:
>>> Take the bits per color channel into consideration when computing DCLK
>>> rate.
>>>
>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocal...@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@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

Reply via email to