[PATCH 0/3] qcom: videocc: Fix sleep clock on Glymur/SM8750

[PATCH 0/3] qcom: videocc: Fix sleep clock on Glymur/SM8750

[Shawn Guo]

videocc-glymur.c (qcom,glymur-videocc, qcom,nord-videocc) and
videocc-sm8750.c both declare three DT clock inputs, DT_BI_TCXO,
DT_BI_TCXO_AO and DT_SLEEP_CLK, and parent video_cc_sleep_clk_src on
DT_SLEEP_CLK.

qcom,sm8450-videocc.yaml, which covers both drivers, documents exactly
two inputs: a board XO and a video AHB clock from GCC. No device tree
can therefore supply the third input, and video_cc_sleep_clk_src can
never resolve its parent. It registers as an orphan clock:
clk_set_rate() on it fails, and it appears parentless in clk_summary.

Nothing breaks at runtime today, for two reasons worth recording:
qcom_cc_probe() does not fail on an unresolved parent_data.index, it
just orphans the clock; and VIDEO_CC_SLEEP_CLK (0x8138) is listed in
the critical CBCRs of both drivers, so the branch is force enabled
through regmap and bypasses the clock framework entirely. The sleep
source keeps whatever rate the bootloader programmed. The orphan still
blocks any future rate management of the video sleep path.

The two-input description is not wrong for every compatible in that
schema. videocc-hawi.c, videocc-kaanapali.c and videocc-maili.c really
do take DT_BI_TCXO and DT_AHB_CLK, and sm8450/sm8550/x1p42100 never
resolve index 1 at all. So this series narrows the description per
compatible rather than changing it for everyone:

  - patch 1 lets the Glymur, Nord and SM8750 compatibles take three
    inputs, described as board XO, board always-on XO and sleep clock,
    and leaves the rest at two.
  - patch 2 adds the sleep clock to the Glymur videocc node.
  - patch 3 does the same for SM8750, and also moves its second input
    from GCC_VIDEO_AHB_CLK to bi_tcxo_ao_div2, which is what the driver
    expects at that index.

The sibling qcom,glymur-evacc.yaml on the same SoC is the precedent:
evacc-glymur.c has the same shape, its schema documents a sleep clock,
and the glymur evacc node already passes one.

The Glymur and SM8750 changes are not tested on those boards. The
equivalent change was verified on Nord, which binds the same
videocc-glymur.c: before it, video_cc_sleep_clk_src appears in
/sys/kernel/debug/clk/clk_orphan_summary; after it, the orphan is gone
and the RCG is parented to the board sleep clock at 32 kHz. The SM8750
change is by inspection of videocc-sm8750.c, which declares the same
three DT inputs. Both should be runtime no-ops otherwise, since the
sleep branch is force enabled as a critical CBCR and index 1 is not
resolved by either driver.

Shawn Guo (3):
  dt-bindings: clock: qcom,sm8450-videocc: Fix clock inputs for Glymur
  arm64: dts: qcom: glymur: Add videocc sleep clock
  arm64: dts: qcom: sm8750: Fix videocc clock inputs

 .../bindings/clock/qcom,sm8450-videocc.yaml   | 26 ++++++++++++++++---
 arch/arm64/boot/dts/qcom/glymur.dtsi          |  3 ++-
 arch/arm64/boot/dts/qcom/sm8750.dtsi          |  3 ++-
 3 files changed, 27 insertions(+), 5 deletions(-)

-- 
2.43.0

[PATCH 1/3] dt-bindings: clock: qcom,sm8450-videocc: Fix clock inputs for Glymur

[Shawn Guo]

The schema describes exactly two clock inputs for every compatible it
covers, a board XO and a video AHB clock from GCC. That is only true
for part of the drivers bound to these compatibles. videocc-glymur.c,
which handles qcom,glymur-videocc and qcom,nord-videocc, and
videocc-sm8750.c both declare their DT inputs as DT_BI_TCXO,
DT_BI_TCXO_AO and DT_SLEEP_CLK, and parent video_cc_sleep_clk_src on
DT_SLEEP_CLK.

Because the schema stops at two items, no device tree can supply the
third input, so video_cc_sleep_clk_src can never resolve its parent
and registers as an orphan clock. It also documents the second input
as an AHB clock, which no device tree using these two drivers passes,
and which those drivers would interpret as the always-on XO.

Describe three inputs for the Glymur, Nord and SM8750 compatibles,
keeping the existing two-input description for the rest. The sibling
qcom,glymur-evacc.yaml, whose driver has the same shape, already
documents a sleep clock this way.

Fixes: ed9ca8296147 ("dt-bindings: clock: qcom: Add video clock controller on Glymur SoC")
Fixes: b190eaea5780 ("dt-bindings: clock: qcom: Add SM8750 video clock controller")
Assisted-by: LLM
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
 .../bindings/clock/qcom,sm8450-videocc.yaml   | 26 ++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml
index e985a450451d..9bd746afbc11 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml
@@ -42,9 +42,8 @@ properties:
       - qcom,x1p42100-videocc
 
   clocks:
-    items:
-      - description: Board XO source
-      - description: Video AHB clock from GCC
+    minItems: 2
+    maxItems: 3
 
   power-domains:
     description:
@@ -79,6 +78,27 @@ allOf:
     then:
       required:
         - required-opps
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - qcom,glymur-videocc
+              - qcom,nord-videocc
+              - qcom,sm8750-videocc
+    then:
+      properties:
+        clocks:
+          items:
+            - description: Board XO source
+            - description: Board always-on XO source
+            - description: Sleep clock source
+    else:
+      properties:
+        clocks:
+          items:
+            - description: Board XO source
+            - description: Video AHB clock from GCC
 
 unevaluatedProperties: false
 
-- 
2.43.0

[PATCH 2/3] arm64: dts: qcom: glymur: Add videocc sleep clock

[Shawn Guo]

The videocc node supplies only the two XO inputs. videocc-glymur.c
expects a third input, DT_SLEEP_CLK, and uses it as the parent of
video_cc_sleep_clk_src, so that RCG cannot resolve its parent and ends
up as an orphan clock: any clk_set_rate() on it fails, and it shows up
parentless in /sys/kernel/debug/clk/clk_summary.

Nothing is broken at runtime today because VIDEO_CC_SLEEP_CLK (0x8138)
is listed in video_cc_glymur_critical_cbcrs and is therefore force
enabled through regmap, bypassing the clock framework; the sleep source
simply keeps whatever rate the bootloader left. The orphan still blocks
any future rate management of the video sleep path.

Pass the board sleep clock as the third input. The sibling evacc node
on the same SoC already does this.

Fixes: 675fec65df73 ("arm64: dts: qcom: Add support for MM clock controllers for Glymur")
Assisted-by: LLM
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/glymur.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index de7c395d9c35..26c15092bcba 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -5758,7 +5758,8 @@ videocc: clock-controller@aaf0000 {
 			compatible = "qcom,glymur-videocc";
 			reg = <0x0 0x0aaf0000 0x0 0x10000>;
 			clocks = <&rpmhcc RPMH_CXO_CLK>,
-				 <&rpmhcc RPMH_CXO_CLK_A>;
+				 <&rpmhcc RPMH_CXO_CLK_A>,
+				 <&sleep_clk>;
 
 			power-domains = <&rpmhpd RPMHPD_MMCX>,
 					<&rpmhpd RPMHPD_MXC>;
-- 
2.43.0

Re: [PATCH 2/3] arm64: dts: qcom: glymur: Add videocc sleep clock

[Abel Vesa]

On 26-09-25 00:11:51, Shawn Guo wrote:
> The videocc node supplies only the two XO inputs. videocc-glymur.c
> expects a third input, DT_SLEEP_CLK, and uses it as the parent of
> video_cc_sleep_clk_src, so that RCG cannot resolve its parent and ends
> up as an orphan clock: any clk_set_rate() on it fails, and it shows up
> parentless in /sys/kernel/debug/clk/clk_summary.
> 
> Nothing is broken at runtime today because VIDEO_CC_SLEEP_CLK (0x8138)
> is listed in video_cc_glymur_critical_cbcrs and is therefore force
> enabled through regmap, bypassing the clock framework; the sleep source
> simply keeps whatever rate the bootloader left. The orphan still blocks
> any future rate management of the video sleep path.
> 
> Pass the board sleep clock as the third input. The sibling evacc node
> on the same SoC already does this.

Same question as on the 3rd patch.

Re: [PATCH 2/3] arm64: dts: qcom: glymur: Add videocc sleep clock

[Shawn Guo]

On Fri, Sep 25, 2026 at 12:48:07PM +0300, Abel Vesa wrote:
> On 26-09-25 00:11:51, Shawn Guo wrote:
> > The videocc node supplies only the two XO inputs. videocc-glymur.c
> > expects a third input, DT_SLEEP_CLK, and uses it as the parent of
> > video_cc_sleep_clk_src, so that RCG cannot resolve its parent and ends
> > up as an orphan clock: any clk_set_rate() on it fails, and it shows up
> > parentless in /sys/kernel/debug/clk/clk_summary.
> > 
> > Nothing is broken at runtime today because VIDEO_CC_SLEEP_CLK (0x8138)
> > is listed in video_cc_glymur_critical_cbcrs and is therefore force
> > enabled through regmap, bypassing the clock framework; the sleep source
> > simply keeps whatever rate the bootloader left. The orphan still blocks
> > any future rate management of the video sleep path.
> > 
> > Pass the board sleep clock as the third input. The sibling evacc node
> > on the same SoC already does this.
> 
> Same question as on the 3rd patch.

This patch doesn't drop GCC_VIDEO_AHB_CLK or any videocc input clock
like 3rd patch but only adding the board sleep clock as the third input.
So it shouldn't break videocc either. It would nice if you can give it a
test on your X2 laptop though :)

Shawn

Re: [PATCH 2/3] arm64: dts: qcom: glymur: Add videocc sleep clock

[Jagadeesh Kona]

On 9/24/2026 9:41 PM, Shawn Guo wrote:
> The videocc node supplies only the two XO inputs. videocc-glymur.c
> expects a third input, DT_SLEEP_CLK, and uses it as the parent of
> video_cc_sleep_clk_src, so that RCG cannot resolve its parent and ends
> up as an orphan clock: any clk_set_rate() on it fails, and it shows up
> parentless in /sys/kernel/debug/clk/clk_summary.
> 
> Nothing is broken at runtime today because VIDEO_CC_SLEEP_CLK (0x8138)
> is listed in video_cc_glymur_critical_cbcrs and is therefore force
> enabled through regmap, bypassing the clock framework; the sleep source
> simply keeps whatever rate the bootloader left. The orphan still blocks
> any future rate management of the video sleep path.
> 

Hi Shawn,

The sleep clock supports only a fixed 32KHz frequency and does not support
any other frequencies. Additionally, this clock is not currently used or voted
on by any consumers. Therefore, leaving it in its default bootloader configured
rate should be sufficient, and this change isn't really required.

Thanks,
Jagadeesh

[PATCH 3/3] arm64: dts: qcom: sm8750: Fix videocc clock inputs

[Shawn Guo]

The videocc node passes GCC_VIDEO_AHB_CLK as its second input and stops
there. videocc-sm8750.c declares its DT inputs as DT_BI_TCXO,
DT_BI_TCXO_AO and DT_SLEEP_CLK, so the second input is the always-on
board XO rather than an AHB clock, and the sleep clock is missing
entirely.

The missing third input leaves video_cc_sleep_clk_src unable to resolve
its parent, so it registers as an orphan clock and cannot be rated.
The AHB phandle in the always-on XO slot is not resolved by the driver
today, but it implies a parent relationship the hardware does not have.

Pass bi_tcxo_ao_div2 and the board sleep clock instead.

Fixes: c0d11ff90475 ("arm64: dts: qcom: sm8750: Add Iris VPU v3.5")
Assisted-by: LLM
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm8750.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
index 28cf22da854d..e092222fd8cf 100644
--- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
@@ -3117,7 +3117,8 @@ videocc: clock-controller@aaf0000 {
 			compatible = "qcom,sm8750-videocc";
 			reg = <0x0 0x0aaf0000 0x0 0x10000>;
 			clocks = <&bi_tcxo_div2>,
-				 <&gcc GCC_VIDEO_AHB_CLK>;
+				 <&bi_tcxo_ao_div2>,
+				 <&sleep_clk>;
 			power-domains = <&rpmhpd RPMHPD_MMCX>,
 					<&rpmhpd RPMHPD_MXC>;
 			required-opps = <&rpmhpd_opp_low_svs>,
-- 
2.43.0

Re: [PATCH 3/3] arm64: dts: qcom: sm8750: Fix videocc clock inputs

[Abel Vesa]

On 26-09-25 00:11:52, Shawn Guo wrote:
> The videocc node passes GCC_VIDEO_AHB_CLK as its second input and stops
> there. videocc-sm8750.c declares its DT inputs as DT_BI_TCXO,
> DT_BI_TCXO_AO and DT_SLEEP_CLK, so the second input is the always-on
> board XO rather than an AHB clock, and the sleep clock is missing
> entirely.
> 
> The missing third input leaves video_cc_sleep_clk_src unable to resolve
> its parent, so it registers as an orphan clock and cannot be rated.
> The AHB phandle in the always-on XO slot is not resolved by the driver
> today, but it implies a parent relationship the hardware does not have.
> 
> Pass bi_tcxo_ao_div2 and the board sleep clock instead.

So videocc can still function properly without the GCC video AHB clock then?

Re: [PATCH 3/3] arm64: dts: qcom: sm8750: Fix videocc clock inputs

[Shawn Guo]

On Fri, Sep 25, 2026 at 12:47:16PM +0300, Abel Vesa wrote:
> On 26-09-25 00:11:52, Shawn Guo wrote:
> > The videocc node passes GCC_VIDEO_AHB_CLK as its second input and stops
> > there. videocc-sm8750.c declares its DT inputs as DT_BI_TCXO,
> > DT_BI_TCXO_AO and DT_SLEEP_CLK, so the second input is the always-on
> > board XO rather than an AHB clock, and the sleep clock is missing
> > entirely.
> > 
> > The missing third input leaves video_cc_sleep_clk_src unable to resolve
> > its parent, so it registers as an orphan clock and cannot be rated.
> > The AHB phandle in the always-on XO slot is not resolved by the driver
> > today, but it implies a parent relationship the hardware does not have.
> > 
> > Pass bi_tcxo_ao_div2 and the board sleep clock instead.
> 
> So videocc can still function properly without the GCC video AHB clock then?

I do not have a sm8750 device to test, but I did verify the same change
on Nord, and videocc can still function properly.

Dropping gcc_video_ahb_clk as a videocc input clock shouldn't break
sm8750 videocc from what I can see.

- The AHB clock isn't a videocc input at all. The videocc clocks array is
  positional and the driver maps index 0/1/2 to
  DT_BI_TCXO/DT_BI_TCXO_AO/DT_SLEEP_CLK.

- gcc_video_ahb_clk cannot be consumed anyway. gcc_sm8750_probe() leaves
  it always enabled in probe and never registers it as a clk at all. So
  <&gcc GCC_VIDEO_AHB_CLK> resolves to nothing.

Shawn