Add bindings documentation for the Kaanapali Graphics Clock and Graphics
power domain Controller.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
---
.../bindings/clock/qcom,kaanapali-gxclkctl.yaml | 63 ++++++++++++++++++++++
.../bindings/clock/qcom,sm8450-gpucc.yaml | 2 +
include/dt-bindings/clock/qcom,kaanapali-gpucc.h | 47 ++++++++++++++++
.../dt-bindings/clock/qcom,kaanapali-gxclkctl.h | 12 +++++
4 files changed, 124 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml b/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..31398aec839d88007c9f1de7e1a248beae826640
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,kaanapali-gxclkctl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Graphics power domain Controller on Kaanapali
+
+maintainers:
+ - Taniya Das <taniya.das@oss.qualcomm.com>
+
+description: |
+ Qualcomm graphics power domain control module provides the power
+ domains on Qualcomm SoCs. This module exposes the GDSC power domain
+ which helps the recovery of Graphics subsystem.
+
+ See also::
+ include/dt-bindings/clock/qcom,kaanapali-gxclkctl.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,kaanapali-gxclkctl
+
+ power-domains:
+ description:
+ Power domains required for the clock controller to operate
+ items:
+ - description: GFX power domain
+ - description: GMXC power domain
+ - description: GPUCC(CX) power domain
+
+ '#power-domain-cells':
+ const: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - power-domains
+ - '#power-domain-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clock-controller@3d68024 {
+ compatible = "qcom,kaanapali-gxclkctl";
+ reg = <0 0x3d68024 0x0 0x8>;
+ power-domains = <&rpmhpd RPMHPD_GFX>,
+ <&rpmhpd RPMHPD_GMXC>,
+ <&gpucc 0>;
+ #power-domain-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml
index 44380f6f81368339c2b264bde4d8ad9a23baca72..6feaa32569f9a852c2049fee00ee7a2e2aefb558 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml
@@ -14,6 +14,7 @@ description: |
domains on Qualcomm SoCs.
See also::
+ include/dt-bindings/clock/qcom,kaanapali-gpucc.h
include/dt-bindings/clock/qcom,milos-gpucc.h
include/dt-bindings/clock/qcom,sar2130p-gpucc.h
include/dt-bindings/clock/qcom,sm4450-gpucc.h
@@ -26,6 +27,7 @@ description: |
properties:
compatible:
enum:
+ - qcom,kaanapali-gpucc
- qcom,milos-gpucc
- qcom,sar2130p-gpucc
- qcom,sm4450-gpucc
diff --git a/include/dt-bindings/clock/qcom,kaanapali-gpucc.h b/include/dt-bindings/clock/qcom,kaanapali-gpucc.h
new file mode 100644
index 0000000000000000000000000000000000000000..e8dc2009c71b705b4369a6c8cf83024a18c611d5
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,kaanapali-gpucc.h
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef _DT_BINDINGS_CLK_QCOM_GPU_CC_KAANAPALI_H
+#define _DT_BINDINGS_CLK_QCOM_GPU_CC_KAANAPALI_H
+
+/* GPU_CC clocks */
+#define GPU_CC_AHB_CLK 0
+#define GPU_CC_CB_CLK 1
+#define GPU_CC_CX_ACCU_SHIFT_CLK 2
+#define GPU_CC_CX_GMU_CLK 3
+#define GPU_CC_CXO_AON_CLK 4
+#define GPU_CC_CXO_CLK 5
+#define GPU_CC_DEMET_CLK 6
+#define GPU_CC_DPM_CLK 7
+#define GPU_CC_FF_CLK_SRC 8
+#define GPU_CC_FREQ_MEASURE_CLK 9
+#define GPU_CC_GMU_CLK_SRC 10
+#define GPU_CC_GPU_SMMU_VOTE_CLK 11
+#define GPU_CC_GX_ACCU_SHIFT_CLK 12
+#define GPU_CC_GX_GMU_CLK 13
+#define GPU_CC_HUB_AON_CLK 14
+#define GPU_CC_HUB_CLK_SRC 15
+#define GPU_CC_HUB_CX_INT_CLK 16
+#define GPU_CC_HUB_DIV_CLK_SRC 17
+#define GPU_CC_MEMNOC_GFX_CLK 18
+#define GPU_CC_PLL0 19
+#define GPU_CC_PLL0_OUT_EVEN 20
+#define GPU_CC_RSCC_HUB_AON_CLK 21
+#define GPU_CC_RSCC_XO_AON_CLK 22
+#define GPU_CC_SLEEP_CLK 23
+
+/* GPU_CC power domains */
+#define GPU_CC_CX_GDSC 0
+
+/* GPU_CC resets */
+#define GPU_CC_CB_BCR 0
+#define GPU_CC_CX_BCR 1
+#define GPU_CC_FAST_HUB_BCR 2
+#define GPU_CC_FF_BCR 3
+#define GPU_CC_GMU_BCR 4
+#define GPU_CC_GX_BCR 5
+#define GPU_CC_XO_BCR 6
+
+#endif
diff --git a/include/dt-bindings/clock/qcom,kaanapali-gxclkctl.h b/include/dt-bindings/clock/qcom,kaanapali-gxclkctl.h
new file mode 100644
index 0000000000000000000000000000000000000000..460e21881c4fec46f2b50ccf10fe504636a52ef1
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,kaanapali-gxclkctl.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef _DT_BINDINGS_CLK_QCOM_GX_CLKCTL_KAANAPALI_H
+#define _DT_BINDINGS_CLK_QCOM_GX_CLKCTL_KAANAPALI_H
+
+/* GX_CLKCTL power domains */
+#define GX_CLKCTL_GX_GDSC 0
+
+#endif
--
2.34.1On Tue, Nov 25, 2025 at 11:15:16PM +0530, Taniya Das wrote:
> Add bindings documentation for the Kaanapali Graphics Clock and Graphics
> power domain Controller.
>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> .../bindings/clock/qcom,kaanapali-gxclkctl.yaml | 63 ++++++++++++++++++++++
> .../bindings/clock/qcom,sm8450-gpucc.yaml | 2 +
> include/dt-bindings/clock/qcom,kaanapali-gpucc.h | 47 ++++++++++++++++
> .../dt-bindings/clock/qcom,kaanapali-gxclkctl.h | 12 +++++
> 4 files changed, 124 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml b/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..31398aec839d88007c9f1de7e1a248beae826640
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml
> @@ -0,0 +1,63 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/qcom,kaanapali-gxclkctl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Graphics power domain Controller on Kaanapali
"Power Domain"
> +
> +maintainers:
> + - Taniya Das <taniya.das@oss.qualcomm.com>
> +
> +description: |
> + Qualcomm graphics power domain control module provides the power
> + domains on Qualcomm SoCs. This module exposes the GDSC power domain
> + which helps the recovery of Graphics subsystem.
> +
> + See also::
Just one ':'
> + include/dt-bindings/clock/qcom,kaanapali-gxclkctl.h
> +
> +properties:
> + compatible:
> + enum:
> + - qcom,kaanapali-gxclkctl
> +
> + power-domains:
> + description:
> + Power domains required for the clock controller to operate
> + items:
> + - description: GFX power domain
> + - description: GMXC power domain
> + - description: GPUCC(CX) power domain
> +
> + '#power-domain-cells':
Power domain controllers do not belong to clocks, so this is:
1. Misplaced - wrong folder
2. Probably wrongly named. gxclkctl sounds like clock controller, but
this is domain controller?
> + const: 1
> +
> + reg:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - power-domains
> + - '#power-domain-cells'
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/power/qcom,rpmhpd.h>
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + clock-controller@3d68024 {
> + compatible = "qcom,kaanapali-gxclkctl";
> + reg = <0 0x3d68024 0x0 0x8>;
Keep consistent hex, so first 0 -> 0x0.
But the problem is that you defined a device for two registers,
basically one domain. I have doubts now whether this is complete and
real device.
> + power-domains = <&rpmhpd RPMHPD_GFX>,
> + <&rpmhpd RPMHPD_GMXC>,
> + <&gpucc 0>;
> + #power-domain-cells = <1>;
And cells 1 makes no sense in such case.
Best regards,
Krzysztof
On 11/26/2025 3:05 PM, Krzysztof Kozlowski wrote:
> On Tue, Nov 25, 2025 at 11:15:16PM +0530, Taniya Das wrote:
>> Add bindings documentation for the Kaanapali Graphics Clock and Graphics
>> power domain Controller.
>>
>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
>> ---
>> .../bindings/clock/qcom,kaanapali-gxclkctl.yaml | 63 ++++++++++++++++++++++
>> .../bindings/clock/qcom,sm8450-gpucc.yaml | 2 +
>> include/dt-bindings/clock/qcom,kaanapali-gpucc.h | 47 ++++++++++++++++
>> .../dt-bindings/clock/qcom,kaanapali-gxclkctl.h | 12 +++++
>> 4 files changed, 124 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml b/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..31398aec839d88007c9f1de7e1a248beae826640
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml
>> @@ -0,0 +1,63 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/clock/qcom,kaanapali-gxclkctl.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm Graphics power domain Controller on Kaanapali
>
> "Power Domain"
>
will fix in the next patch.
>> +
>> +maintainers:
>> + - Taniya Das <taniya.das@oss.qualcomm.com>
>> +
>> +description: |
>> + Qualcomm graphics power domain control module provides the power
>> + domains on Qualcomm SoCs. This module exposes the GDSC power domain
>> + which helps the recovery of Graphics subsystem.
>> +
>> + See also::
>
> Just one ':'
>
My bad, will fix it in the next series.
>> + include/dt-bindings/clock/qcom,kaanapali-gxclkctl.h
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - qcom,kaanapali-gxclkctl
>> +
>> + power-domains:
>> + description:
>> + Power domains required for the clock controller to operate
>> + items:
>> + - description: GFX power domain
>> + - description: GMXC power domain
>> + - description: GPUCC(CX) power domain
>> +
>> + '#power-domain-cells':
>
> Power domain controllers do not belong to clocks, so this is:
> 1. Misplaced - wrong folder
> 2. Probably wrongly named. gxclkctl sounds like clock controller, but
> this is domain controller?
>
The GFXCLKCTL is actually a clock controller which has PLLs, clocks and
Power domains (GDSC), but the requirement here is to use the GDSC from
the clock controller to recover the GPU firmware in case of any
failure/hangs. The rest of the resources of the clock controller are
being used by the firmware of GPU. The GDSC is a clock controller
resource and modeled from the clock controller drivers across chipsets.
>> + const: 1
>> +
>> + reg:
>> + maxItems: 1
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - power-domains
>> + - '#power-domain-cells'
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/power/qcom,rpmhpd.h>
>> + soc {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + clock-controller@3d68024 {
>> + compatible = "qcom,kaanapali-gxclkctl";
>> + reg = <0 0x3d68024 0x0 0x8>;
>
> Keep consistent hex, so first 0 -> 0x0.
Sure, will fix this.
> But the problem is that you defined a device for two registers,
> basically one domain. I have doubts now whether this is complete and
> real device.
>
As the Linux GPU driver requires only the GDSC, I have mapped the region
which is required by the clock controller driver. If required, the
entire region can be mapped as well.
>> + power-domains = <&rpmhpd RPMHPD_GFX>,
>> + <&rpmhpd RPMHPD_GMXC>,
>> + <&gpucc 0>;
>> + #power-domain-cells = <1>;
>
> And cells 1 makes no sense in such case.
>
We would like to leverage the existing common clock driver(GDSC) code to
register the power-domains and also maintain uniformity across chipsets
and consistency in consumer GDSC phandle usage.
--
Thanks,
Taniya Das
On 04/12/2025 07:49, Taniya Das wrote:
>>> + power-domains:
>>> + description:
>>> + Power domains required for the clock controller to operate
>>> + items:
>>> + - description: GFX power domain
>>> + - description: GMXC power domain
>>> + - description: GPUCC(CX) power domain
>>> +
>>> + '#power-domain-cells':
>>
>> Power domain controllers do not belong to clocks, so this is:
>> 1. Misplaced - wrong folder
>> 2. Probably wrongly named. gxclkctl sounds like clock controller, but
>> this is domain controller?
>>
>
> The GFXCLKCTL is actually a clock controller which has PLLs, clocks and
> Power domains (GDSC), but the requirement here is to use the GDSC from
> the clock controller to recover the GPU firmware in case of any
> failure/hangs. The rest of the resources of the clock controller are
> being used by the firmware of GPU. The GDSC is a clock controller
> resource and modeled from the clock controller drivers across chipsets.
This should be somewhere explained.
>
>>> + const: 1
>>> +
>>> + reg:
>>> + maxItems: 1
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - power-domains
>>> + - '#power-domain-cells'
>>> +
>>> +unevaluatedProperties: false
>>> +
>>> +examples:
>>> + - |
>>> + #include <dt-bindings/power/qcom,rpmhpd.h>
>>> + soc {
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> +
>>> + clock-controller@3d68024 {
>>> + compatible = "qcom,kaanapali-gxclkctl";
>>> + reg = <0 0x3d68024 0x0 0x8>;
>>
>> Keep consistent hex, so first 0 -> 0x0.
>
> Sure, will fix this.
>
>> But the problem is that you defined a device for two registers,
>> basically one domain. I have doubts now whether this is complete and
>> real device.
>>
>
> As the Linux GPU driver requires only the GDSC, I have mapped the region
> which is required by the clock controller driver. If required, the
> entire region can be mapped as well.
Required is to properly describe the hardware, please read writing
bindings doc.
>
>>> + power-domains = <&rpmhpd RPMHPD_GFX>,
>>> + <&rpmhpd RPMHPD_GMXC>,
>>> + <&gpucc 0>;
>>> + #power-domain-cells = <1>;
>>
>> And cells 1 makes no sense in such case.
>>
>
> We would like to leverage the existing common clock driver(GDSC) code to
Fix the driver code if it cannot handle other cells. Your drivers do not
matter for choices made in bindings.
> register the power-domains and also maintain uniformity across chipsets
> and consistency in consumer GDSC phandle usage.
There is no such consistency rule. Don't make up your own rules.
Best regards,
Krzysztof
On 12/16/2025 2:21 PM, Krzysztof Kozlowski wrote:
> On 04/12/2025 07:49, Taniya Das wrote:
>>>> + power-domains:
>>>> + description:
>>>> + Power domains required for the clock controller to operate
>>>> + items:
>>>> + - description: GFX power domain
>>>> + - description: GMXC power domain
>>>> + - description: GPUCC(CX) power domain
>>>> +
>>>> + '#power-domain-cells':
>>>
>>> Power domain controllers do not belong to clocks, so this is:
>>> 1. Misplaced - wrong folder
>>> 2. Probably wrongly named. gxclkctl sounds like clock controller, but
>>> this is domain controller?
>>>
>>
>> The GFXCLKCTL is actually a clock controller which has PLLs, clocks and
>> Power domains (GDSC), but the requirement here is to use the GDSC from
>> the clock controller to recover the GPU firmware in case of any
>> failure/hangs. The rest of the resources of the clock controller are
>> being used by the firmware of GPU. The GDSC is a clock controller
>> resource and modeled from the clock controller drivers across chipsets.
>
> This should be somewhere explained.
I will capture it in the binding description in the next patch set.
>
>>
>>>> + const: 1
>>>> +
>>>> + reg:
>>>> + maxItems: 1
>>>> +
>>>> +required:
>>>> + - compatible
>>>> + - reg
>>>> + - power-domains
>>>> + - '#power-domain-cells'
>>>> +
>>>> +unevaluatedProperties: false
>>>> +
>>>> +examples:
>>>> + - |
>>>> + #include <dt-bindings/power/qcom,rpmhpd.h>
>>>> + soc {
>>>> + #address-cells = <2>;
>>>> + #size-cells = <2>;
>>>> +
>>>> + clock-controller@3d68024 {
>>>> + compatible = "qcom,kaanapali-gxclkctl";
>>>> + reg = <0 0x3d68024 0x0 0x8>;
>>>
>>> Keep consistent hex, so first 0 -> 0x0.
>>
>> Sure, will fix this.
>>
>>> But the problem is that you defined a device for two registers,
>>> basically one domain. I have doubts now whether this is complete and
>>> real device.
>>>
>>
>> As the Linux GPU driver requires only the GDSC, I have mapped the region
>> which is required by the clock controller driver. If required, the
>> entire region can be mapped as well.
>
> Required is to properly describe the hardware, please read writing
> bindings doc.
>
Sure, will map the entire region to be describe the entire hardware.
>>
>>>> + power-domains = <&rpmhpd RPMHPD_GFX>,
>>>> + <&rpmhpd RPMHPD_GMXC>,
>>>> + <&gpucc 0>;
>>>> + #power-domain-cells = <1>;
>>>
>>> And cells 1 makes no sense in such case.
>>>
>>
>> We would like to leverage the existing common clock driver(GDSC) code to
>
> Fix the driver code if it cannot handle other cells. Your drivers do not
> matter for choices made in bindings.
>
As it is still a clock controller from hardware design and in SW I will
be map the entire hardware region and this way this clock controller
will also be aligned to the existing clock controllers and keep the
#power-domain-cells = <1> as other CCs.
>> register the power-domains and also maintain uniformity across chipsets
>> and consistency in consumer GDSC phandle usage.
>
> There is no such consistency rule. Don't make up your own rules.
>
--
Thanks,
Taniya Das
On 17/12/2025 10:32, Taniya Das wrote: >>> >>> We would like to leverage the existing common clock driver(GDSC) code to >> >> Fix the driver code if it cannot handle other cells. Your drivers do not >> matter for choices made in bindings. >> > > As it is still a clock controller from hardware design and in SW I will > be map the entire hardware region and this way this clock controller > will also be aligned to the existing clock controllers and keep the > #power-domain-cells = <1> as other CCs. I don't see how this resolves my comment. Best regards, Krzysztof
On 12/17/25 11:09 AM, Krzysztof Kozlowski wrote: > On 17/12/2025 10:32, Taniya Das wrote: >>>> >>>> We would like to leverage the existing common clock driver(GDSC) code to >>> >>> Fix the driver code if it cannot handle other cells. Your drivers do not >>> matter for choices made in bindings. >>> >> >> As it is still a clock controller from hardware design and in SW I will >> be map the entire hardware region and this way this clock controller >> will also be aligned to the existing clock controllers and keep the >> #power-domain-cells = <1> as other CCs. > > I don't see how this resolves my comment. Spanning the entire 0x6000-long block will remove your worry about this description only being 2-register-wide This block provides more than one GDSC - although again, not all of them need/should be accessed by Linux. I suppose just enumerating the "extra" ones in bindings will be a good enough compromise? Konrad
On 17/12/2025 14:21, Konrad Dybcio wrote: > On 12/17/25 11:09 AM, Krzysztof Kozlowski wrote: >> On 17/12/2025 10:32, Taniya Das wrote: >>>>> >>>>> We would like to leverage the existing common clock driver(GDSC) code to >>>> >>>> Fix the driver code if it cannot handle other cells. Your drivers do not >>>> matter for choices made in bindings. >>>> >>> >>> As it is still a clock controller from hardware design and in SW I will >>> be map the entire hardware region and this way this clock controller >>> will also be aligned to the existing clock controllers and keep the >>> #power-domain-cells = <1> as other CCs. >> >> I don't see how this resolves my comment. > > Spanning the entire 0x6000-long block will remove your worry about this > description only being 2-register-wide But that was not the comment here. Taniya replied under comment about cells. We are not discussing here some other things... Best regards, Krzysztof
On 12/17/25 2:54 PM, Krzysztof Kozlowski wrote: > On 17/12/2025 14:21, Konrad Dybcio wrote: >> On 12/17/25 11:09 AM, Krzysztof Kozlowski wrote: >>> On 17/12/2025 10:32, Taniya Das wrote: >>>>>> >>>>>> We would like to leverage the existing common clock driver(GDSC) code to >>>>> >>>>> Fix the driver code if it cannot handle other cells. Your drivers do not >>>>> matter for choices made in bindings. >>>>> >>>> >>>> As it is still a clock controller from hardware design and in SW I will >>>> be map the entire hardware region and this way this clock controller >>>> will also be aligned to the existing clock controllers and keep the >>>> #power-domain-cells = <1> as other CCs. >>> >>> I don't see how this resolves my comment. >> >> Spanning the entire 0x6000-long block will remove your worry about this >> description only being 2-register-wide > > But that was not the comment here. Taniya replied under comment about > cells. We are not discussing here some other things... Right, you omitted the part where I answered your comment from the context, so I'll re-add it: """ This block provides more than one GDSC - although again, not all of them need/should be accessed by Linux. I suppose just enumerating the "extra" ones in bindings will be a good enough compromise? """ TLDR: cells=1 makes sense as per usual Konrad
On 19/12/2025 14:02, Konrad Dybcio wrote: > On 12/17/25 2:54 PM, Krzysztof Kozlowski wrote: >> On 17/12/2025 14:21, Konrad Dybcio wrote: >>> On 12/17/25 11:09 AM, Krzysztof Kozlowski wrote: >>>> On 17/12/2025 10:32, Taniya Das wrote: >>>>>>> >>>>>>> We would like to leverage the existing common clock driver(GDSC) code to >>>>>> >>>>>> Fix the driver code if it cannot handle other cells. Your drivers do not >>>>>> matter for choices made in bindings. >>>>>> >>>>> >>>>> As it is still a clock controller from hardware design and in SW I will >>>>> be map the entire hardware region and this way this clock controller >>>>> will also be aligned to the existing clock controllers and keep the >>>>> #power-domain-cells = <1> as other CCs. >>>> >>>> I don't see how this resolves my comment. >>> >>> Spanning the entire 0x6000-long block will remove your worry about this >>> description only being 2-register-wide >> >> But that was not the comment here. Taniya replied under comment about >> cells. We are not discussing here some other things... > > Right, you omitted the part where I answered your comment from the > context, so I'll re-add it: > > """ > This block provides more than one GDSC - although again, not all of them > need/should be accessed by Linux. I suppose just enumerating the "extra" > ones in bindings will be a good enough compromise? > """ > > TLDR: cells=1 makes sense as per usual Either list them in headers or at least explain that in the binding. Best regards, Krzysztof
On 12/19/2025 8:15 PM, Krzysztof Kozlowski wrote: > On 19/12/2025 14:02, Konrad Dybcio wrote: >> On 12/17/25 2:54 PM, Krzysztof Kozlowski wrote: >>> On 17/12/2025 14:21, Konrad Dybcio wrote: >>>> On 12/17/25 11:09 AM, Krzysztof Kozlowski wrote: >>>>> On 17/12/2025 10:32, Taniya Das wrote: >>>>>>>> >>>>>>>> We would like to leverage the existing common clock driver(GDSC) code to >>>>>>> >>>>>>> Fix the driver code if it cannot handle other cells. Your drivers do not >>>>>>> matter for choices made in bindings. >>>>>>> >>>>>> >>>>>> As it is still a clock controller from hardware design and in SW I will >>>>>> be map the entire hardware region and this way this clock controller >>>>>> will also be aligned to the existing clock controllers and keep the >>>>>> #power-domain-cells = <1> as other CCs. >>>>> >>>>> I don't see how this resolves my comment. >>>> >>>> Spanning the entire 0x6000-long block will remove your worry about this >>>> description only being 2-register-wide >>> >>> But that was not the comment here. Taniya replied under comment about >>> cells. We are not discussing here some other things... >> >> Right, you omitted the part where I answered your comment from the >> context, so I'll re-add it: >> >> """ >> This block provides more than one GDSC - although again, not all of them >> need/should be accessed by Linux. I suppose just enumerating the "extra" >> ones in bindings will be a good enough compromise? >> """ >> >> TLDR: cells=1 makes sense as per usual > > Either list them in headers or at least explain that in the binding. I will take care to list them and explain them as well. -- Thanks, Taniya Das
On 12/17/2025 7:24 PM, Krzysztof Kozlowski wrote: > On 17/12/2025 14:21, Konrad Dybcio wrote: >> On 12/17/25 11:09 AM, Krzysztof Kozlowski wrote: >>> On 17/12/2025 10:32, Taniya Das wrote: >>>>>> >>>>>> We would like to leverage the existing common clock driver(GDSC) code to >>>>> >>>>> Fix the driver code if it cannot handle other cells. Your drivers do not >>>>> matter for choices made in bindings. >>>>> >>>> >>>> As it is still a clock controller from hardware design and in SW I will >>>> be map the entire hardware region and this way this clock controller >>>> will also be aligned to the existing clock controllers and keep the >>>> #power-domain-cells = <1> as other CCs. >>> >>> I don't see how this resolves my comment. >> >> Spanning the entire 0x6000-long block will remove your worry about this >> description only being 2-register-wide > > But that was not the comment here. Taniya replied under comment about > cells. We are not discussing here some other things... > I will review and add support for handling #power-domain-cells = <0> in our common code of clock & gdsc. However, the initial intent was to keep the GDSC phandle uniform across chipsets as this is a clock controller by hardware design, which is why #power-domain-cells was originally set to <1>. -- Thanks, Taniya Das
On 19/12/2025 11:39, Taniya Das wrote: > > > On 12/17/2025 7:24 PM, Krzysztof Kozlowski wrote: >> On 17/12/2025 14:21, Konrad Dybcio wrote: >>> On 12/17/25 11:09 AM, Krzysztof Kozlowski wrote: >>>> On 17/12/2025 10:32, Taniya Das wrote: >>>>>>> >>>>>>> We would like to leverage the existing common clock driver(GDSC) code to >>>>>> >>>>>> Fix the driver code if it cannot handle other cells. Your drivers do not >>>>>> matter for choices made in bindings. >>>>>> >>>>> >>>>> As it is still a clock controller from hardware design and in SW I will >>>>> be map the entire hardware region and this way this clock controller >>>>> will also be aligned to the existing clock controllers and keep the >>>>> #power-domain-cells = <1> as other CCs. >>>> >>>> I don't see how this resolves my comment. >>> >>> Spanning the entire 0x6000-long block will remove your worry about this >>> description only being 2-register-wide >> >> But that was not the comment here. Taniya replied under comment about >> cells. We are not discussing here some other things... >> > > I will review and add support for handling #power-domain-cells = <0> in > our common code of clock & gdsc. However, the initial intent was to keep > the GDSC phandle uniform across chipsets as this is a clock controller > by hardware design, which is why #power-domain-cells was originally set > to <1>. Having cells=0 or =2 or =3 does not change "as this is a clock controller by hardware design" at all. I do not see any of these arguments relevant to discussion. Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.