Take the bits per color channel into consideration when computing DCLK
rate.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@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);
+
vop2_vp_write(vp, RK3568_VP_MIPI_CTRL, 0);
/*
--
2.50.0Hello Cristian， At 2025-07-22 01:39:04, "Cristian Ciocaltea" <cristian.ciocaltea@collabora.com> wrote: >Take the bits per color channel into consideration when computing DCLK >rate. > >Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@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. >+ > vop2_vp_write(vp, RK3568_VP_MIPI_CTRL, 0); > > /* > >-- >2.50.0
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@collabora.com> wrote: >> Take the bits per color channel into consideration when computing DCLK >> rate. >> >> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@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. 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
Hello Cristian，
在 2025-07-22 14:16:26，"Cristian Ciocaltea" <cristian.ciocaltea@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@collabora.com> wrote:
>>> Take the bits per color channel into consideration when computing DCLK
>>> rate.
>>>
>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@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
There might be a misunderstanding here. The values of hdmi.tmds_char_rate and vop dclk are not always equal in all cases.
For vop dclk always match mode->clock, hdmi.tmds_char_rate will adjust with bpc.
For example, for a 4KP30 YUV444 8 bit, vop->dclk = hdmi.tmds_char_rate = 297MHZ,
for 4KP30 YUV444 10 bit, hdmi.tmds_char_rate = 1.25 * vop->dclk.
In fact, for the HDMI PHY, there are two clocks. One is a clock with the same frequency as the HDMI PLL, namely.tmds_char_rate,
and the other is a clock obtained by further frequency division of the HDMI PLL, which can be supplied to the vop dclk.
----------------------- >tmds_char_rate
|
PHY PLL------|
|
------DIV(REG0086[3-1])-->vop dclk.
So in this case, my suggestion is still to follow the implementation of our BSP kernel:
On the crtc side, it shoud set dclk as the mode->clock.
At the PHY side(rk_hdptx_phy_clk_set_rate) when set the vop dclk, it should adjust the PLL clock according to the bpc:
if (bpc > 8)
bit_rate = clock * 10 / 8;
>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
Hi Andy, On 7/24/25 11:56 AM, Andy Yan wrote: > > > > Hello Cristian， > 在 2025-07-22 14:16:26，"Cristian Ciocaltea" <cristian.ciocaltea@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@collabora.com> wrote: >>>> Take the bits per color channel into consideration when computing DCLK >>>> rate. >>>> >>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@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 > > > There might be a misunderstanding here. The values of hdmi.tmds_char_rate and vop dclk are not always equal in all cases. > For vop dclk always match mode->clock, hdmi.tmds_char_rate will adjust with bpc. > For example, for a 4KP30 YUV444 8 bit, vop->dclk = hdmi.tmds_char_rate = 297MHZ, > for 4KP30 YUV444 10 bit, hdmi.tmds_char_rate = 1.25 * vop->dclk. > > In fact, for the HDMI PHY, there are two clocks. One is a clock with the same frequency as the HDMI PLL, namely.tmds_char_rate, > and the other is a clock obtained by further frequency division of the HDMI PLL, which can be supplied to the vop dclk. > > ----------------------- >tmds_char_rate > | > PHY PLL------| > > | > ------DIV(REG0086[3-1])-->vop dclk. Oh, I missed the fact there's a divider between PLL and DCLK. All this makes sense now, thanks for clarifying! Regards, Cristian > So in this case, my suggestion is still to follow the implementation of our BSP kernel: > On the crtc side, it shoud set dclk as the mode->clock. > At the PHY side(rk_hdptx_phy_clk_set_rate) when set the vop dclk, it should adjust the PLL clock according to the bpc: > if (bpc > 8) > bit_rate = clock * 10 / 8; > > > >> 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
Hello Cristian,
在 2025-07-22 14:16:26，"Cristian Ciocaltea" <cristian.ciocaltea@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@collabora.com> wrote:
>>> Take the bits per color channel into consideration when computing DCLK
>>> rate.
>>>
>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@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
Hi Andy, On 7/22/25 9:55 AM, Andy Yan wrote: > > Hello Cristian, > > 在 2025-07-22 14:16:26，"Cristian Ciocaltea" <cristian.ciocaltea@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@collabora.com> wrote: >>>> Take the bits per color channel into consideration when computing DCLK >>>> rate. >>>> >>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@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. Oh, I wrongly assumed high color depth is not currently supported/in use for vop2. In that case my suggestion below is actually a mandatory thing to do, as it should correctly reduce the scope to RK3576 & RK3588 only. >> >> 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
© 2016 - 2025 Red Hat, Inc.