The Disp AHB clock is provided by the GCC but never registered. It is
instead enabled on probe as it is expected to be always-on. So it should
be dropped from Disp CC entirely.
Signed-off-by: Abel Vesa <[email protected]>
---
Abel Vesa (5):
dt-bindings: clock: sm8550-dispcc: Drop the Disp AHB clock
arm64: dts: qcom: sm8550: Drop the Disp AHB clock from dispcc node
arm64: dts: qcom: sm8650: Drop the Disp AHB clock from dispcc node
clk: qcom: dispcc-sm8550: Drop the Disp AHB DT provided clock
clk: qcom: dispcc-sm8650: Drop the Disp AHB DT provided clock
Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml | 2 --
arch/arm64/boot/dts/qcom/sm8550.dtsi | 1 -
arch/arm64/boot/dts/qcom/sm8650.dtsi | 1 -
drivers/clk/qcom/dispcc-sm8550.c | 1 -
drivers/clk/qcom/dispcc-sm8650.c | 1 -
5 files changed, 6 deletions(-)
---
base-commit: 01af33cc9894b4489fb68fa35c40e9fe85df63dc
change-id: 20240125-dispcc-sm8550-sm8650-drop-disp-ahb-clk-fa011f7be9fa
Best regards,
--
Abel Vesa <[email protected]>
The Disp AHB clock is not registered, but enabled on probe, by the SM8650 and
SM8550 GCC drivers. So drop the clock from dispcc node.
Fixes: 553f9bd45554 ("dt-bindings: clock: document SM8550 DISPCC clock controller")
Signed-off-by: Abel Vesa <[email protected]>
---
Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml | 2 --
1 file changed, 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml
index c129f8c16b50..6660d38bef86 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml
@@ -25,7 +25,6 @@ properties:
items:
- description: Board XO source
- description: Board Always On XO source
- - description: Display's AHB clock
- description: sleep clock
- description: Byte clock from DSI PHY0
- description: Pixel clock from DSI PHY0
@@ -82,7 +81,6 @@ examples:
reg = <0x0af00000 0x10000>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
<&rpmhcc RPMH_CXO_CLK_A>,
- <&gcc GCC_DISP_AHB_CLK>,
<&sleep_clk>,
<&dsi0_phy 0>,
<&dsi0_phy 1>,
--
2.34.1
The Disp AHB clock is not registered, but is enabled on probe, by the
GCC driver. So drop it from the dispcc node.
Fixes: d7da51db5b81 ("arm64: dts: qcom: sm8550: add display hardware devices")
Signed-off-by: Abel Vesa <[email protected]>
---
arch/arm64/boot/dts/qcom/sm8550.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index ee1ba5a8c8fc..59c23d0696a9 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -3026,7 +3026,6 @@ dispcc: clock-controller@af00000 {
reg = <0 0x0af00000 0 0x20000>;
clocks = <&bi_tcxo_div2>,
<&bi_tcxo_ao_div2>,
- <&gcc GCC_DISP_AHB_CLK>,
<&sleep_clk>,
<&mdss_dsi0_phy 0>,
<&mdss_dsi0_phy 1>,
--
2.34.1
The Disp AHB clock is not registered, but is enabled on probe, by the
GCC driver. So drop it from the dispcc node.
Fixes: d2350377997f ("arm64: dts: qcom: add initial SM8650 dtsi")
Signed-off-by: Abel Vesa <[email protected]>
---
arch/arm64/boot/dts/qcom/sm8650.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index 2df77123a8c7..1bf16636371c 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -3442,7 +3442,6 @@ dispcc: clock-controller@af00000 {
clocks = <&bi_tcxo_div2>,
<&bi_tcxo_ao_div2>,
- <&gcc GCC_DISP_AHB_CLK>,
<&sleep_clk>,
<&mdss_dsi0_phy 0>,
<&mdss_dsi0_phy 1>,
--
2.34.1
On 1/25/24 10:27, Abel Vesa wrote:
> The Disp AHB clock is provided by the GCC but never registered. It is
> instead enabled on probe as it is expected to be always-on. So it should
> be dropped from Disp CC entirely.
>
> Signed-off-by: Abel Vesa <[email protected]>
> ---
Abel, you just raised some concerns over my series doing this and now
you're doing the same, plus breaking backwards compatibility for no
good reason, instead of solving the problem.
The correct solution here is to register the AHB clock with GCC and
pm_clk_add() it from dispcc's .probe (and enable runtime PM on dispcc
if it's already not the case). Then the AHB clock will be gated when
no display hardware (= no dispcc consumer) is in use.
8[56]50 are in a good position for this, as they already have the
required DTS reference. Unfortunately, I still haven't fully dug
into this for platforms without one, but that's on me.
Konrad
The GCC doesn't even register the Disp AHB clock. It enables it
on probe though. So drop it from the list of DT provided clocks as well.
Fixes: 90114ca11476 ("clk: qcom: add SM8550 DISPCC driver")
Signed-off-by: Abel Vesa <[email protected]>
---
drivers/clk/qcom/dispcc-sm8550.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/clk/qcom/dispcc-sm8550.c b/drivers/clk/qcom/dispcc-sm8550.c
index f96d8b81fd9a..b33795f8e8cf 100644
--- a/drivers/clk/qcom/dispcc-sm8550.c
+++ b/drivers/clk/qcom/dispcc-sm8550.c
@@ -31,7 +31,6 @@
enum {
DT_BI_TCXO,
DT_BI_TCXO_AO,
- DT_AHB_CLK,
DT_SLEEP_CLK,
DT_DSI0_PHY_PLL_OUT_BYTECLK,
--
2.34.1
On 24-01-25 10:49:23, Konrad Dybcio wrote:
>
>
> On 1/25/24 10:27, Abel Vesa wrote:
> > The Disp AHB clock is provided by the GCC but never registered. It is
> > instead enabled on probe as it is expected to be always-on. So it should
> > be dropped from Disp CC entirely.
> >
> > Signed-off-by: Abel Vesa <[email protected]>
> > ---
>
> Abel, you just raised some concerns over my series doing this and now
> you're doing the same, plus breaking backwards compatibility for no
> good reason, instead of solving the problem.
Sorry but, during the off-list discussion, you convinced me that it is OK to drop
their registration as long as we enable them on probe.
I've not seen the following reply in time before sending current series:
https://lore.kernel.org/all/[email protected]/
Since this is blocking the patches for dispcc and dts for X1E80100, I
thought I'd just drop the clock as required from DT point of view.
But yeah, you're right, it breaks bindings ABI and that's wrong.
>
> The correct solution here is to register the AHB clock with GCC and
> pm_clk_add() it from dispcc's .probe (and enable runtime PM on dispcc
> if it's already not the case). Then the AHB clock will be gated when
> no display hardware (= no dispcc consumer) is in use.
I agree.
>
> 8[56]50 are in a good position for this, as they already have the
> required DTS reference. Unfortunately, I still haven't fully dug
> into this for platforms without one, but that's on me.
Since I need to do this for the X1E80100, I'll probably do it for the
other two as well.
Sorry for the misunderstanding.
>
> Konrad
On 1/25/24 11:44, Abel Vesa wrote:
> On 24-01-25 10:49:23, Konrad Dybcio wrote:
>>
>>
>> On 1/25/24 10:27, Abel Vesa wrote:
>>> The Disp AHB clock is provided by the GCC but never registered. It is
>>> instead enabled on probe as it is expected to be always-on. So it should
>>> be dropped from Disp CC entirely.
>>>
>>> Signed-off-by: Abel Vesa <[email protected]>
>>> ---
>>
>> Abel, you just raised some concerns over my series doing this and now
>> you're doing the same, plus breaking backwards compatibility for no
>> good reason, instead of solving the problem.
>
> Sorry but, during the off-list discussion, you convinced me that it is OK to drop
> their registration as long as we enable them on probe.
>
> I've not seen the following reply in time before sending current series:
> https://lore.kernel.org/all/[email protected]/
>
> Since this is blocking the patches for dispcc and dts for X1E80100, I
> thought I'd just drop the clock as required from DT point of view.
> But yeah, you're right, it breaks bindings ABI and that's wrong.
>
>>
>> The correct solution here is to register the AHB clock with GCC and
>> pm_clk_add() it from dispcc's .probe (and enable runtime PM on dispcc
>> if it's already not the case). Then the AHB clock will be gated when
>> no display hardware (= no dispcc consumer) is in use.
>
> I agree.
>
>>
>> 8[56]50 are in a good position for this, as they already have the
>> required DTS reference. Unfortunately, I still haven't fully dug
>> into this for platforms without one, but that's on me.
>
> Since I need to do this for the X1E80100, I'll probably do it for the
> other two as well.
Thanks!
>
> Sorry for the misunderstanding.
The story is confusing as per usual, perhaps I could have explained
it better in the first place..
Konrad