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 <[email protected]>
---
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/[email protected]/
[1]
https://lore.kernel.org/all/[email protected]/
