[PATCH v5 01/10] dt-bindings: display: rockchip: analogix-dp: Fix hclk as third clock for RK3588
Damon Ding
damon.ding at rock-chips.com
Thu May 14 19:36:32 PDT 2026
Hi Krzysztof,
On 5/14/2026 6:03 PM, Krzysztof Kozlowski wrote:
> On Wed, May 13, 2026 at 03:44:05PM +0800, Damon Ding wrote:
>> RK3588 eDP controller requires HCLK_VO1 (video output bus clock)
>> to access the VO1 GRF registers and enable the video datapath.
>
> To access GRF? Then it is the same clock input.
Not the same as RK3399 case.
(The same as the descriptions in [0])
RK3588 hclk_vo1 related NOC design:
PD_VO1
hclk_vo1
└─ pclk_vo1_root
Then the clock tree design:
hclk_vo1 (200M)
├─ hclk_vo1_niu_en
│ └─ hclk_vo1_niu (200M)
├─ hclk_hdcp1_en
│ └─ hclk_hdcp1 (200M)
├─ hclk_i2s5_8ch_en
│ └─ hclk_i2s5_8ch (200M)
├─ hclk_spdif4_en
│ └─ hclk_spdif4 (200M)
├─ hclk_spdifrx1_en
│ └─ hclk_spdifrx1 (200M)
├─ hclk_i2s9_8ch_en
│ └─ hclk_i2s9_8ch (200M)
└─ hclk_i2s6_8ch_en
└─ hclk_i2s6_8ch (200M)
pclk_vo1_root (150M)
├─ pclk_edp0_en
│ └─ pclk_edp0 (150M)
├─ pclk_edp1_en
│ └─ pclk_edp1 (150M)
├─ pclk_hdmitx1_en
│ └─ pclk_hdmitx1 (150M)
├─ pclk_vo1grf_en
│ └─ pclk_vo1grf (150M)
├─ pclk_hdcp1_en
│ └─ pclk_hdcp1 (150M)
├─ pclk_hdmitx0_en
│ └─ pclk_hdmitx0 (150M)
└─ pclk_trng1_en
└─ pclk_trng1 (150M)
On RK3399, the 'grf' clock is only used exclusively for GRF register access.
But on RK3576/RK3588, the 'hclk' (HCLK_VO1) acts as the parent clock for
pclk_vo1_root in NOC design. Meanwhile pclk_vo1_root is further the
parent of pclk_vo1grf and pclk_edp0/pclk_edp1 in clock tree. So this
hclk affects both GRF register access and the overall APB clock domain
of the eDP controller, which makes it necessary to be listed independently.
>
> AGAIN (reiterated soooo many times by me): you describe here clock
> input, NOT OUTPUT.
>
You're absolutely right, thank you for the repeated clarification.
I used "video output bus clock" as a shorthand to refer to HCLK_VO1,
which clocks the entire video output domain including eDP and HDMI
interfaces.
I will rephrase the commit message more precisely in the next version.
>>
>> Previously, the clock was enabled implicitly via the 'rockchip,vo-grf'
>> phandle reference, which allowed the eDP to work without explicitly
>> managing the hclk_vo1 clock. However, this is not safe or explicit.
>>
>> Enforce the correct third clock name on a per-compatible basis to
>> standardize clock requirements per SoC. This makes the clock
>> dependency clear and removes reliance on implicit clock enablement
>> from GRF phandle.
>>
>> Fixes: f855146263b1 ("dt-bindings: display: rockchip: analogix-dp: Add support for RK3588")
>> Signed-off-by: Damon Ding <damon.ding at rock-chips.com>
>>
>> ---
>>
>> Changes in v4:
>> - Modify the commit msg.
>>
>> Changes in v5:
>> - Enforce the correct third clock name on a per-compatible basis.
>> - Modify the commit msg simultaneously.
>> ---
>> .../rockchip/rockchip,analogix-dp.yaml | 37 +++++++++++++++++--
>> 1 file changed, 33 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>> index d99b23b88cc5..8001c1facf98 100644
>> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>> @@ -23,10 +23,7 @@ properties:
>>
>> clock-names:
>> minItems: 2
>> - items:
>> - - const: dp
>> - - const: pclk
>> - - const: grf
>
> What is 'grf' clock in such case?
>
The 'grf' clock here was specifically for RK3399, which is only used for
GRF register access.
Moreover, the control logic for the new 'hclk' clock is different from
'grf' clock:
- The 'grf' clock was gated dynamically before/after GRF register access;
- The 'hclk' needs to be enabled during probe and kept running
continuously [1].
Best regards,
Damon
[0]
https://lore.kernel.org/all/c349eaf2-5852-4bb6-9dac-f7240e1c8098@rock-chips.com/
[1]
https://lore.kernel.org/all/20260513074414.2053435-6-damon.ding@rock-chips.com/
More information about the Linux-rockchip
mailing list