Krait Documentation conversion

Convert kpss-acc driver Documentation to yaml.
The original Documentation was wrong all along. Fix it while we are converting it.
The example was wrong as kpss-acc-v2 should only expose the regs but we don't have any driver that expose additional clocks. The kpss-acc driver is only specific to v1. For this exact reason, limit all the additional bindings (clocks, clock-names, clock-output-names and #clock-cells) to v1 and also flag that these bindings should NOT be used for v2.

Signed-off-by Christian Marangi <[email protected]>

---
 .../bindings/arm/msm/qcom,kpss-acc.txt        | 49 ----------
 .../bindings/arm/msm/qcom,kpss-acc.yaml       | 93 +++++++++++++++++++
 2 files changed, 93 insertions(+), 49 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
 create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.yaml

Quoted 9 lines · Christian Marangi

Convert kpss-acc driver Documentation to yaml.
The original Documentation was wrong all along. Fix it while we are converting it.
The example was wrong as kpss-acc-v2 should only expose the regs but we don't have any driver that expose additional clocks. The kpss-acc driver is only specific to v1. For this exact reason, limit all the additional bindings (clocks, clock-names, clock-output-names and #clock-cells) to v1 and also flag that these bindings should NOT be used for v2.

Quoted 8 lines

Signed-off-by Christian Marangi <[email protected]>

---
 .../bindings/arm/msm/qcom,kpss-acc.txt        | 49 ----------
 .../bindings/arm/msm/qcom,kpss-acc.yaml       | 93 +++++++++++++++++++
 2 files changed, 93 insertions(+), 49 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
 create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.yaml

Running 'make dtbs_check' with the schema in this patch gives the following warnings. Consider if they are expected or the schema is incorrect. These may not be new warnings.

Note that it is not yet a requirement to have 0 warnings for dtbs_check. This will change in the future.

Full log is available here: https://patchwork.ozlabs.org/patch/

clock-controller@2088000: '#clock-cells' is a required property

	arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dtb
	arch/arm/boot/dts/qcom-apq8064-cm-qs600.dtb
	arch/arm/boot/dts/qcom-apq8064-ifc6410.dtb
	arch/arm/boot/dts/qcom-apq8064-sony-xperia-lagan-yuga.dtb
	arch/arm/boot/dts/qcom-ipq8064-ap148.dtb
	arch/arm/boot/dts/qcom-ipq8064-rb3011.dtb
	arch/arm/boot/dts/qcom-msm8960-cdp.dtb

clock-controller@2088000: 'clock-names' is a required property

	arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dtb
	arch/arm/boot/dts/qcom-apq8064-cm-qs600.dtb
	arch/arm/boot/dts/qcom-apq8064-ifc6410.dtb
	arch/arm/boot/dts/qcom-apq8064-sony-xperia-lagan-yuga.dtb
	arch/arm/boot/dts/qcom-ipq8064-ap148.dtb
	arch/arm/boot/dts/qcom-ipq8064-rb3011.dtb
	arch/arm/boot/dts/qcom-msm8960-cdp.dtb

clock-controller@2088000: 'clock-output-names' is a required property

	arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dtb
	arch/arm/boot/dts/qcom-apq8064-cm-qs600.dtb
	arch/arm/boot/dts/qcom-apq8064-ifc6410.dtb
	arch/arm/boot/dts/qcom-apq8064-sony-xperia-lagan-yuga.dtb
	arch/arm/boot/dts/qcom-ipq8064-ap148.dtb
	arch/arm/boot/dts/qcom-ipq8064-rb3011.dtb
	arch/arm/boot/dts/qcom-msm8960-cdp.dtb

clock-controller@2088000: 'clocks' is a required property

	arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dtb
	arch/arm/boot/dts/qcom-apq8064-cm-qs600.dtb
	arch/arm/boot/dts/qcom-apq8064-ifc6410.dtb
	arch/arm/boot/dts/qcom-apq8064-sony-xperia-lagan-yuga.dtb
	arch/arm/boot/dts/qcom-ipq8064-ap148.dtb
	arch/arm/boot/dts/qcom-ipq8064-rb3011.dtb
	arch/arm/boot/dts/qcom-msm8960-cdp.dtb

clock-controller@2098000: '#clock-cells' is a required property

	arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dtb
	arch/arm/boot/dts/qcom-apq8064-cm-qs600.dtb
	arch/arm/boot/dts/qcom-apq8064-ifc6410.dtb
	arch/arm/boot/dts/qcom-apq8064-sony-xperia-lagan-yuga.dtb
	arch/arm/boot/dts/qcom-ipq8064-ap148.dtb
	arch/arm/boot/dts/qcom-ipq8064-rb3011.dtb
	arch/arm/boot/dts/qcom-msm8960-cdp.dtb

clock-controller@2098000: 'clock-names' is a required property

	arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dtb
	arch/arm/boot/dts/qcom-apq8064-cm-qs600.dtb
	arch/arm/boot/dts/qcom-apq8064-ifc6410.dtb
	arch/arm/boot/dts/qcom-apq8064-sony-xperia-lagan-yuga.dtb
	arch/arm/boot/dts/qcom-ipq8064-ap148.dtb
	arch/arm/boot/dts/qcom-ipq8064-rb3011.dtb
	arch/arm/boot/dts/qcom-msm8960-cdp.dtb

clock-controller@2098000: 'clock-output-names' is a required property

	arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dtb
	arch/arm/boot/dts/qcom-apq8064-cm-qs600.dtb
	arch/arm/boot/dts/qcom-apq8064-ifc6410.dtb
	arch/arm/boot/dts/qcom-apq8064-sony-xperia-lagan-yuga.dtb
	arch/arm/boot/dts/qcom-ipq8064-ap148.dtb
	arch/arm/boot/dts/qcom-ipq8064-rb3011.dtb
	arch/arm/boot/dts/qcom-msm8960-cdp.dtb

clock-controller@2098000: 'clocks' is a required property

	arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dtb
	arch/arm/boot/dts/qcom-apq8064-cm-qs600.dtb
	arch/arm/boot/dts/qcom-apq8064-ifc6410.dtb
	arch/arm/boot/dts/qcom-apq8064-sony-xperia-lagan-yuga.dtb
	arch/arm/boot/dts/qcom-ipq8064-ap148.dtb
	arch/arm/boot/dts/qcom-ipq8064-rb3011.dtb
	arch/arm/boot/dts/qcom-msm8960-cdp.dtb

clock-controller@20a8000: '#clock-cells' is a required property

	arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dtb
	arch/arm/boot/dts/qcom-apq8064-cm-qs600.dtb
	arch/arm/boot/dts/qcom-apq8064-ifc6410.dtb
	arch/arm/boot/dts/qcom-apq8064-sony-xperia-lagan-yuga.dtb

clock-controller@20a8000: 'clock-names' is a required property

	arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dtb
	arch/arm/boot/dts/qcom-apq8064-cm-qs600.dtb
	arch/arm/boot/dts/qcom-apq8064-ifc6410.dtb
	arch/arm/boot/dts/qcom-apq8064-sony-xperia-lagan-yuga.dtb

clock-controller@20a8000: 'clock-output-names' is a required property

	arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dtb
	arch/arm/boot/dts/qcom-apq8064-cm-qs600.dtb
	arch/arm/boot/dts/qcom-apq8064-ifc6410.dtb
	arch/arm/boot/dts/qcom-apq8064-sony-xperia-lagan-yuga.dtb

clock-controller@20a8000: 'clocks' is a required property

	arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dtb
	arch/arm/boot/dts/qcom-apq8064-cm-qs600.dtb
	arch/arm/boot/dts/qcom-apq8064-ifc6410.dtb
	arch/arm/boot/dts/qcom-apq8064-sony-xperia-lagan-yuga.dtb

clock-controller@20b8000: '#clock-cells' is a required property

	arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dtb
	arch/arm/boot/dts/qcom-apq8064-cm-qs600.dtb
	arch/arm/boot/dts/qcom-apq8064-ifc6410.dtb
	arch/arm/boot/dts/qcom-apq8064-sony-xperia-lagan-yuga.dtb

clock-controller@20b8000: 'clock-names' is a required property

	arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dtb
	arch/arm/boot/dts/qcom-apq8064-cm-qs600.dtb
	arch/arm/boot/dts/qcom-apq8064-ifc6410.dtb
	arch/arm/boot/dts/qcom-apq8064-sony-xperia-lagan-yuga.dtb

clock-controller@20b8000: 'clock-output-names' is a required property

	arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dtb
	arch/arm/boot/dts/qcom-apq8064-cm-qs600.dtb
	arch/arm/boot/dts/qcom-apq8064-ifc6410.dtb
	arch/arm/boot/dts/qcom-apq8064-sony-xperia-lagan-yuga.dtb

clock-controller@20b8000: 'clocks' is a required property

	arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dtb
	arch/arm/boot/dts/qcom-apq8064-cm-qs600.dtb
	arch/arm/boot/dts/qcom-apq8064-ifc6410.dtb
	arch/arm/boot/dts/qcom-apq8064-sony-xperia-lagan-yuga.dtb

Convert kpss-acc driver Documentation to yaml.
The original Documentation was wrong all along. Fix it while we are converting it.
The example was wrong as kpss-acc-v2 should only expose the regs but we don't have any driver that expose additional clocks. The kpss-acc driver is only specific to v1. For this exact reason, limit all the additional bindings (clocks, clock-names, clock-output-names and #clock-cells) to v1 and also flag that these bindings should NOT be used for v2.

Signed-off-by Christian Marangi <[email protected]>

---
 .../bindings/arm/msm/qcom,kpss-acc.txt        | 49 ----------
 .../bindings/arm/msm/qcom,kpss-acc.yaml       | 93 +++++++++++++++++++

 2 files changed, 93 insertions(+), 49 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
 create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.yaml

Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.yaml new file +2 -0

new file mode 100644
index 000000000000..5e16121d9f0d
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2

Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.yaml new file +9 -0

+  The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
+  There is one ACC register region per CPU within the KPSS remapped region as
+  well as an alias register region that remaps accesses to the ACC associated
+  with the CPU accessing the region.
+
+properties:
+  compatible:
+    enum:
+      - qcom,kpss-acc-v1

Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.yaml new file +62 -0

+      - description: phandle to pxo_board
+
+  clock-names:
+    items:
+      - const: pll8_vote
+      - const: pxo
+
+  clock-output-names:
+    description: Name of the aux clock. Krait can have at most 4 cpu.
+    enum:
+      - acpu0_aux
+      - acpu1_aux
+      - acpu2_aux
+      - acpu3_aux
+
+  '#clock-cells':
+    const: 0
+
+required:
+  - compatible
+  - reg
+
+if:
+  properties:
+    compatible:
+      contains:
+        const: qcom,kpss-acc-v1
+then:
+  required:
+    - clocks
+    - clock-names
+    - clock-output-names
+    - '#clock-cells'
+else:
+  properties:
+    clocks: false
+    clock-names: false
+    clock-output-names: false
+    '#clock-cells': false
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/qcom,gcc-ipq806x.h>
+
+    clock-controller@2088000 {
+      compatible = "qcom,kpss-acc-v1";
+      reg = <0x02088000 0x1000>, <0x02008000 0x1000>;
+      clocks = <&gcc PLL8_VOTE>, <&pxo_board>;
+      clock-names = "pll8_vote", "pxo";
+      clock-output-names = "acpu0_aux";
+      #clock-cells = <0>;
+    };
+
+  - |
+    clock-controller@f9088000 {
+      compatible = "qcom,kpss-acc-v2";
+      reg = <0xf9088000 0x1000>,
+            <0xf9008000 0x1000>;
+    };
+...

Signature · 1 line

2.37.2

Quoted 8 lines · Christian Marangi

Convert kpss-acc driver Documentation to yaml.
The original Documentation was wrong all along. Fix it while we are converting it.
The example was wrong as kpss-acc-v2 should only expose the regs but we don't have any driver that expose additional clocks. The kpss-acc driver is only specific to v1. For this exact reason, limit all the additional bindings (clocks, clock-names, clock-output-names and #clock-cells) to v1 and also flag that these bindings should NOT be used for v2.

Odd that a clock controller has no clocks, but okay.

Quoted 5 lines

Signed-off-by Christian Marangi <[email protected]>

---
 .../bindings/arm/msm/qcom,kpss-acc.txt        | 49 ----------
 .../bindings/arm/msm/qcom,kpss-acc.yaml       | 93 +++++++++++++++++++

As this is a clock controller, please move to bindings/clock/

Quoted 12 lines

 2 files changed, 93 insertions(+), 49 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
 create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.yaml

Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.yaml new file +2 -0

new file mode 100644
index 000000000000..5e16121d9f0d
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2

Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.yaml line 12

Quoted 10 lines

Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.yaml new file +10 -0

+---
+$id: http://devicetree.org/schemas/arm/msm/qcom,kpss-acc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Krait Processor Sub-system (KPSS) Application Clock Controller (ACC)
+
+maintainers:
+  - Christian Marangi <[email protected]>
+
+description: |

Don't need '|' if no formatting to preserve.

Quoted 9 lines

Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.yaml new file +9 -0

+  The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
+  There is one ACC register region per CPU within the KPSS remapped region as
+  well as an alias register region that remaps accesses to the ACC associated
+  with the CPU accessing the region.
+
+properties:
+  compatible:
+    enum:
+      - qcom,kpss-acc-v1

Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.yaml line 31

Quoted 10 lines

Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.yaml new file +10 -0

+      - qcom,kpss-acc-v2
+
+  reg:
+    items:
+      - description: Base address and size of the register region
+      - description: Optional base address and size of the alias register region
+
+  clocks:
+    items:
+      - description: phandle to pll8_vote

Always a phandle (and arg), so that's redundant. Really, if there's not more to add that what clock-names says, then just 'maxItems: 2' is fine.

Quoted 66 lines

Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.yaml new file +62 -0

+      - description: phandle to pxo_board
+
+  clock-names:
+    items:
+      - const: pll8_vote
+      - const: pxo
+
+  clock-output-names:
+    description: Name of the aux clock. Krait can have at most 4 cpu.
+    enum:
+      - acpu0_aux
+      - acpu1_aux
+      - acpu2_aux
+      - acpu3_aux
+
+  '#clock-cells':
+    const: 0
+
+required:
+  - compatible
+  - reg
+
+if:
+  properties:
+    compatible:
+      contains:
+        const: qcom,kpss-acc-v1
+then:
+  required:
+    - clocks
+    - clock-names
+    - clock-output-names
+    - '#clock-cells'
+else:
+  properties:
+    clocks: false
+    clock-names: false
+    clock-output-names: false
+    '#clock-cells': false
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/qcom,gcc-ipq806x.h>
+
+    clock-controller@2088000 {
+      compatible = "qcom,kpss-acc-v1";
+      reg = <0x02088000 0x1000>, <0x02008000 0x1000>;
+      clocks = <&gcc PLL8_VOTE>, <&pxo_board>;
+      clock-names = "pll8_vote", "pxo";
+      clock-output-names = "acpu0_aux";
+      #clock-cells = <0>;
+    };
+
+  - |
+    clock-controller@f9088000 {
+      compatible = "qcom,kpss-acc-v2";
+      reg = <0xf9088000 0x1000>,
+            <0xf9008000 0x1000>;
+    };
+...

Signature · 1 line

2.37.2

Quoted 10 lines · Rob Herring

Quoted 8 lines · Christian Marangi

Convert kpss-acc driver Documentation to yaml.
The original Documentation was wrong all along. Fix it while we are converting it.
The example was wrong as kpss-acc-v2 should only expose the regs but we don't have any driver that expose additional clocks. The kpss-acc driver is only specific to v1. For this exact reason, limit all the additional bindings (clocks, clock-names, clock-output-names and #clock-cells) to v1 and also flag that these bindings should NOT be used for v2.

Quoted 2 lines

Odd that a clock controller has no clocks, but okay.

As said in the commit v2 is only used for regs. v2 it's only used in arch/arm/mach-qcom/platsmp.c to setup stuff cpu hotplug and bringup.

Should we split the 2 driver? To me the acc naming seems to be just recycled for v2 and it's not really a clk controller.

So keeping v2 in arm/msm/qcom,kpss-acc-v2.yaml and v1 moved to clock?

Quoted 18 lines · Christian Marangi

Quoted 10 lines · Rob Herring

Quoted 8 lines · Christian Marangi

Convert kpss-acc driver Documentation to yaml.
The original Documentation was wrong all along. Fix it while we are converting it.
The example was wrong as kpss-acc-v2 should only expose the regs but we don't have any driver that expose additional clocks. The kpss-acc driver is only specific to v1. For this exact reason, limit all the additional bindings (clocks, clock-names, clock-output-names and #clock-cells) to v1 and also flag that these bindings should NOT be used for v2.

Quoted 2 lines

Odd that a clock controller has no clocks, but okay.

As said in the commit v2 is only used for regs. v2 it's only used in arch/arm/mach-qcom/platsmp.c to setup stuff cpu hotplug and bringup.

Quoted 4 lines

Should we split the 2 driver? To me the acc naming seems to be just recycled for v2 and it's not really a clk controller.

So keeping v2 in arm/msm/qcom,kpss-acc-v2.yaml and v1 moved to clock?

I suspect that qcom,kpss-acc-v2 is misnamed as the "clock-controller". According to msm-3.10, these regions are used by the Krait core regulators.

Quoted 19 lines · Dmitry Baryshkov

Quoted 18 lines · Christian Marangi

Quoted 10 lines · Rob Herring

Quoted 8 lines · Christian Marangi

Convert kpss-acc driver Documentation to yaml.
The original Documentation was wrong all along. Fix it while we are converting it.
The example was wrong as kpss-acc-v2 should only expose the regs but we don't have any driver that expose additional clocks. The kpss-acc driver is only specific to v1. For this exact reason, limit all the additional bindings (clocks, clock-names, clock-output-names and #clock-cells) to v1 and also flag that these bindings should NOT be used for v2.

Quoted 2 lines

Odd that a clock controller has no clocks, but okay.

As said in the commit v2 is only used for regs. v2 it's only used in arch/arm/mach-qcom/platsmp.c to setup stuff cpu hotplug and bringup.

Quoted 9 lines

Quoted 4 lines

Should we split the 2 driver? To me the acc naming seems to be just recycled for v2 and it's not really a clk controller.

So keeping v2 in arm/msm/qcom,kpss-acc-v2.yaml and v1 moved to clock?

I suspect that qcom,kpss-acc-v2 is misnamed as the "clock-controller". According to msm-3.10, these regions are used by the Krait core regulators.

Well we need to understand how to handle this... change the compatible it's a nono for sure. In platsmp.c they are used for cpu power control so could be that they are actually used to regulators. I would honestly move v1 to clock and leave v2 to arm/msm but I'm not cetain on what name to assign to the 2 yaml.

What do you think?

Quoted 37 lines · Christian Marangi

Quoted 19 lines · Dmitry Baryshkov

Quoted 18 lines · Christian Marangi

Quoted 10 lines · Rob Herring

Quoted 8 lines · Christian Marangi

Convert kpss-acc driver Documentation to yaml.
The original Documentation was wrong all along. Fix it while we are converting it.
The example was wrong as kpss-acc-v2 should only expose the regs but we don't have any driver that expose additional clocks. The kpss-acc driver is only specific to v1. For this exact reason, limit all the additional bindings (clocks, clock-names, clock-output-names and #clock-cells) to v1 and also flag that these bindings should NOT be used for v2.

Quoted 2 lines

Odd that a clock controller has no clocks, but okay.

As said in the commit v2 is only used for regs. v2 it's only used in arch/arm/mach-qcom/platsmp.c to setup stuff cpu hotplug and bringup.

Quoted 9 lines

Quoted 4 lines

Should we split the 2 driver? To me the acc naming seems to be just recycled for v2 and it's not really a clk controller.

So keeping v2 in arm/msm/qcom,kpss-acc-v2.yaml and v1 moved to clock?

I suspect that qcom,kpss-acc-v2 is misnamed as the "clock-controller". According to msm-3.10, these regions are used by the Krait core regulators.

Well we need to understand how to handle this... change the compatible it's a nono for sure. In platsmp.c they are used for cpu power control so could be that they are actually used to regulators. I would honestly move v1 to clock and leave v2 to arm/msm but I'm not cetain on what name to assign to the 2 yaml.

Quoted 1 line

What do you think?

This is fine for me. If somebody gets better understanding of underlying hardware and works on actually using these blocks, he will update the bindings.

My only suggestion would be to rename kpss-acc-v2 nodes to 'power-controller@address' and document them so.

Quoted 38 lines · Dmitry Baryshkov

Quoted 37 lines · Christian Marangi

Quoted 19 lines · Dmitry Baryshkov

Quoted 18 lines · Christian Marangi

Quoted 10 lines · Rob Herring

Quoted 8 lines · Christian Marangi

Convert kpss-acc driver Documentation to yaml.
The original Documentation was wrong all along. Fix it while we are converting it.
The example was wrong as kpss-acc-v2 should only expose the regs but we don't have any driver that expose additional clocks. The kpss-acc driver is only specific to v1. For this exact reason, limit all the additional bindings (clocks, clock-names, clock-output-names and #clock-cells) to v1 and also flag that these bindings should NOT be used for v2.

Quoted 2 lines

Odd that a clock controller has no clocks, but okay.

As said in the commit v2 is only used for regs. v2 it's only used in arch/arm/mach-qcom/platsmp.c to setup stuff cpu hotplug and bringup.

Quoted 9 lines

Quoted 4 lines

Should we split the 2 driver? To me the acc naming seems to be just recycled for v2 and it's not really a clk controller.

So keeping v2 in arm/msm/qcom,kpss-acc-v2.yaml and v1 moved to clock?

I suspect that qcom,kpss-acc-v2 is misnamed as the "clock-controller". According to msm-3.10, these regions are used by the Krait core regulators.

Well we need to understand how to handle this... change the compatible it's a nono for sure. In platsmp.c they are used for cpu power control so could be that they are actually used to regulators. I would honestly move v1 to clock and leave v2 to arm/msm but I'm not cetain on what name to assign to the 2 yaml.

Quoted 9 lines

Quoted 1 line

What do you think?

This is fine for me. If somebody gets better understanding of underlying hardware and works on actually using these blocks, he will update the bindings.

My only suggestion would be to rename kpss-acc-v2 nodes to 'power-controller@address' and document them so.

Ok so something like this?

    power-controller@f9088000 {
      compatible = "qcom,kpss-acc-v2";
      reg = <0xf9088000 0x1000>,
            <0xf9008000 0x1000>;
    };

(and I will have to fix dtbs warning as they will be unmatched I think.) Yaml naming:
qcom,kpss-acc-v1.yaml
qcom,kpss-acc-v2.yaml
Right?

--
Ansuel

Quoted 58 lines · Christian Marangi

Quoted 38 lines · Dmitry Baryshkov

Quoted 37 lines · Christian Marangi

Quoted 19 lines · Dmitry Baryshkov

Quoted 18 lines · Christian Marangi

Quoted 10 lines · Rob Herring

Quoted 8 lines · Christian Marangi

Convert kpss-acc driver Documentation to yaml.
The original Documentation was wrong all along. Fix it while we are converting it.
The example was wrong as kpss-acc-v2 should only expose the regs but we don't have any driver that expose additional clocks. The kpss-acc driver is only specific to v1. For this exact reason, limit all the additional bindings (clocks, clock-names, clock-output-names and #clock-cells) to v1 and also flag that these bindings should NOT be used for v2.

Quoted 2 lines

Odd that a clock controller has no clocks, but okay.

As said in the commit v2 is only used for regs. v2 it's only used in arch/arm/mach-qcom/platsmp.c to setup stuff cpu hotplug and bringup.

Quoted 9 lines

Quoted 4 lines

Should we split the 2 driver? To me the acc naming seems to be just recycled for v2 and it's not really a clk controller.

So keeping v2 in arm/msm/qcom,kpss-acc-v2.yaml and v1 moved to clock?

I suspect that qcom,kpss-acc-v2 is misnamed as the "clock-controller". According to msm-3.10, these regions are used by the Krait core regulators.

Well we need to understand how to handle this... change the compatible it's a nono for sure. In platsmp.c they are used for cpu power control so could be that they are actually used to regulators. I would honestly move v1 to clock and leave v2 to arm/msm but I'm not cetain on what name to assign to the 2 yaml.

Quoted 9 lines

Quoted 1 line

What do you think?

This is fine for me. If somebody gets better understanding of underlying hardware and works on actually using these blocks, he will update the bindings.

My only suggestion would be to rename kpss-acc-v2 nodes to 'power-controller@address' and document them so.

Ok so something like this?

    power-controller@f9088000 {
      compatible = "qcom,kpss-acc-v2";
      reg = <0xf9088000 0x1000>,
            <0xf9008000 0x1000>;
    };

Quoted 5 lines

(and I will have to fix dtbs warning as they will be unmatched I think.) Yaml naming:
qcom,kpss-acc-v1.yaml
qcom,kpss-acc-v2.yaml
Right?

Sounds good to me.

I'd even say clock/qcom,kpss-acc-v1.yaml and arm/msm/qcom,kpss-acc-v2.yaml or maybe power/qcom,kpss-acc-v2.yaml

Quoted 67 lines · Dmitry Baryshkov

Quoted 58 lines · Christian Marangi

Quoted 38 lines · Dmitry Baryshkov

Quoted 37 lines · Christian Marangi

Quoted 19 lines · Dmitry Baryshkov

Quoted 18 lines · Christian Marangi

Quoted 10 lines · Rob Herring

Quoted 8 lines · Christian Marangi

Convert kpss-acc driver Documentation to yaml.
The original Documentation was wrong all along. Fix it while we are converting it.
The example was wrong as kpss-acc-v2 should only expose the regs but we don't have any driver that expose additional clocks. The kpss-acc driver is only specific to v1. For this exact reason, limit all the additional bindings (clocks, clock-names, clock-output-names and #clock-cells) to v1 and also flag that these bindings should NOT be used for v2.

Quoted 2 lines

Odd that a clock controller has no clocks, but okay.

As said in the commit v2 is only used for regs. v2 it's only used in arch/arm/mach-qcom/platsmp.c to setup stuff cpu hotplug and bringup.

Quoted 9 lines

Quoted 4 lines

Should we split the 2 driver? To me the acc naming seems to be just recycled for v2 and it's not really a clk controller.

So keeping v2 in arm/msm/qcom,kpss-acc-v2.yaml and v1 moved to clock?

I suspect that qcom,kpss-acc-v2 is misnamed as the "clock-controller". According to msm-3.10, these regions are used by the Krait core regulators.

Well we need to understand how to handle this... change the compatible it's a nono for sure. In platsmp.c they are used for cpu power control so could be that they are actually used to regulators. I would honestly move v1 to clock and leave v2 to arm/msm but I'm not cetain on what name to assign to the 2 yaml.

Quoted 9 lines

Quoted 1 line

What do you think?

This is fine for me. If somebody gets better understanding of underlying hardware and works on actually using these blocks, he will update the bindings.

My only suggestion would be to rename kpss-acc-v2 nodes to 'power-controller@address' and document them so.

Ok so something like this?

    power-controller@f9088000 {
      compatible = "qcom,kpss-acc-v2";
      reg = <0xf9088000 0x1000>,
            <0xf9008000 0x1000>;
    };

Quoted 5 lines

(and I will have to fix dtbs warning as they will be unmatched I think.) Yaml naming:
qcom,kpss-acc-v1.yaml
qcom,kpss-acc-v2.yaml
Right?

Sounds good to me.

Quoted 3 lines

I'd even say clock/qcom,kpss-acc-v1.yaml and arm/msm/qcom,kpss-acc-v2.yaml or maybe power/qcom,kpss-acc-v2.yaml

Wonder if the gcc driver should have the same tretement? It's also a clock-controller driver that doesn't use clock at all... Do you have some info about it?

Quoted 73 lines · Christian Marangi

Quoted 70 lines · Dmitry Baryshkov

Quoted 58 lines · Christian Marangi

Quoted 38 lines · Dmitry Baryshkov

Quoted 37 lines · Christian Marangi

Quoted 19 lines · Dmitry Baryshkov

Quoted 18 lines · Christian Marangi

Quoted 10 lines · Rob Herring

Quoted 8 lines · Christian Marangi

Convert kpss-acc driver Documentation to yaml.
The original Documentation was wrong all along. Fix it while we are converting it.
The example was wrong as kpss-acc-v2 should only expose the regs but we don't have any driver that expose additional clocks. The kpss-acc driver is only specific to v1. For this exact reason, limit all the additional bindings (clocks, clock-names, clock-output-names and #clock-cells) to v1 and also flag that these bindings should NOT be used for v2.

Quoted 2 lines

Odd that a clock controller has no clocks, but okay.

As said in the commit v2 is only used for regs. v2 it's only used in arch/arm/mach-qcom/platsmp.c to setup stuff cpu hotplug and bringup.

Quoted 9 lines

Quoted 4 lines

Should we split the 2 driver? To me the acc naming seems to be just recycled for v2 and it's not really a clk controller.

So keeping v2 in arm/msm/qcom,kpss-acc-v2.yaml and v1 moved to clock?

I suspect that qcom,kpss-acc-v2 is misnamed as the "clock-controller". According to msm-3.10, these regions are used by the Krait core regulators.

Well we need to understand how to handle this... change the compatible it's a nono for sure. In platsmp.c they are used for cpu power control so could be that they are actually used to regulators. I would honestly move v1 to clock and leave v2 to arm/msm but I'm not cetain on what name to assign to the 2 yaml.

Quoted 9 lines

Quoted 1 line

What do you think?

This is fine for me. If somebody gets better understanding of underlying hardware and works on actually using these blocks, he will update the bindings.

My only suggestion would be to rename kpss-acc-v2 nodes to 'power-controller@address' and document them so.

Ok so something like this?

    power-controller@f9088000 {
      compatible = "qcom,kpss-acc-v2";
      reg = <0xf9088000 0x1000>,
            <0xf9008000 0x1000>;
    };

Quoted 5 lines

(and I will have to fix dtbs warning as they will be unmatched I think.) Yaml naming:
qcom,kpss-acc-v1.yaml
qcom,kpss-acc-v2.yaml
Right?

Sounds good to me.

I'd even say clock/qcom,kpss-acc-v1.yaml and arm/msm/qcom,kpss-acc-v2.yaml or maybe power/qcom,kpss-acc-v2.yaml

Quoted 3 lines

Wonder if the gcc driver should have the same tretement? It's also a clock-controller driver that doesn't use clock at all... Do you have some info about it?

As far as I understand, the kpss-gcc is a normal clock controller, isn't it? It provides clocks to other devices.

Quoted 74 lines · Dmitry Baryshkov

Quoted 73 lines · Christian Marangi

Quoted 70 lines · Dmitry Baryshkov

Quoted 58 lines · Christian Marangi

Quoted 38 lines · Dmitry Baryshkov

Quoted 37 lines · Christian Marangi

Quoted 19 lines · Dmitry Baryshkov

Quoted 18 lines · Christian Marangi

Quoted 10 lines · Rob Herring

Quoted 8 lines · Christian Marangi

Convert kpss-acc driver Documentation to yaml.
The original Documentation was wrong all along. Fix it while we are converting it.
The example was wrong as kpss-acc-v2 should only expose the regs but we don't have any driver that expose additional clocks. The kpss-acc driver is only specific to v1. For this exact reason, limit all the additional bindings (clocks, clock-names, clock-output-names and #clock-cells) to v1 and also flag that these bindings should NOT be used for v2.

Quoted 2 lines

Odd that a clock controller has no clocks, but okay.

As said in the commit v2 is only used for regs. v2 it's only used in arch/arm/mach-qcom/platsmp.c to setup stuff cpu hotplug and bringup.

Quoted 9 lines

Quoted 4 lines

Should we split the 2 driver? To me the acc naming seems to be just recycled for v2 and it's not really a clk controller.

So keeping v2 in arm/msm/qcom,kpss-acc-v2.yaml and v1 moved to clock?

I suspect that qcom,kpss-acc-v2 is misnamed as the "clock-controller". According to msm-3.10, these regions are used by the Krait core regulators.

Well we need to understand how to handle this... change the compatible it's a nono for sure. In platsmp.c they are used for cpu power control so could be that they are actually used to regulators. I would honestly move v1 to clock and leave v2 to arm/msm but I'm not cetain on what name to assign to the 2 yaml.

Quoted 9 lines

Quoted 1 line

What do you think?

This is fine for me. If somebody gets better understanding of underlying hardware and works on actually using these blocks, he will update the bindings.

My only suggestion would be to rename kpss-acc-v2 nodes to 'power-controller@address' and document them so.

Ok so something like this?

    power-controller@f9088000 {
      compatible = "qcom,kpss-acc-v2";
      reg = <0xf9088000 0x1000>,
            <0xf9008000 0x1000>;
    };

Quoted 5 lines

(and I will have to fix dtbs warning as they will be unmatched I think.) Yaml naming:
qcom,kpss-acc-v1.yaml
qcom,kpss-acc-v2.yaml
Right?

Sounds good to me.

I'd even say clock/qcom,kpss-acc-v1.yaml and arm/msm/qcom,kpss-acc-v2.yaml or maybe power/qcom,kpss-acc-v2.yaml

Quoted 7 lines

Quoted 3 lines

Wonder if the gcc driver should have the same tretement? It's also a clock-controller driver that doesn't use clock at all... Do you have some info about it?

As far as I understand, the kpss-gcc is a normal clock controller, isn't it? It provides clocks to other devices.

Hi again... Having acc-v2 as power-controller would require to set #power-domain-cells = <0>;

Would that be acceptable? Considering it wouldn't expose any PM domain?

About kpss-gcc we have some device that for some reason doesn't have the required clocks defined in the dts. I checked the related gcc and no PXO defined and no pll8_vote clock defined. (the affected dts are all listed in the related Documentation)

No idea how they currently work with the kpss-gcc driver as these parents are missing. Guess the driver just fails to probe? So this was the question if you had more info about it... since to me it seems just another gcc v2 that doesn't expose clocks but it's just a power-controller just like acc-v2.

Signature · 1 line

	Ansuel

Quoted 79 lines · Christian Marangi

Quoted 78 lines · Dmitry Baryshkov

Quoted 76 lines · Christian Marangi

Quoted 65 lines · Dmitry Baryshkov

Quoted 58 lines · Christian Marangi

Quoted 38 lines · Dmitry Baryshkov

Quoted 37 lines · Christian Marangi

Quoted 19 lines · Dmitry Baryshkov

Quoted 18 lines · Christian Marangi

Quoted 10 lines · Rob Herring

Quoted 8 lines · Christian Marangi

Convert kpss-acc driver Documentation to yaml.
The original Documentation was wrong all along. Fix it while we are converting it.
The example was wrong as kpss-acc-v2 should only expose the regs but we don't have any driver that expose additional clocks. The kpss-acc driver is only specific to v1. For this exact reason, limit all the additional bindings (clocks, clock-names, clock-output-names and #clock-cells) to v1 and also flag that these bindings should NOT be used for v2.

Quoted 2 lines

Odd that a clock controller has no clocks, but okay.

As said in the commit v2 is only used for regs. v2 it's only used in arch/arm/mach-qcom/platsmp.c to setup stuff cpu hotplug and bringup.

Quoted 9 lines

Quoted 4 lines

Should we split the 2 driver? To me the acc naming seems to be just recycled for v2 and it's not really a clk controller.

So keeping v2 in arm/msm/qcom,kpss-acc-v2.yaml and v1 moved to clock?

I suspect that qcom,kpss-acc-v2 is misnamed as the "clock-controller". According to msm-3.10, these regions are used by the Krait core regulators.

Well we need to understand how to handle this... change the compatible it's a nono for sure. In platsmp.c they are used for cpu power control so could be that they are actually used to regulators. I would honestly move v1 to clock and leave v2 to arm/msm but I'm not cetain on what name to assign to the 2 yaml.

Quoted 9 lines

Quoted 1 line

What do you think?

This is fine for me. If somebody gets better understanding of underlying hardware and works on actually using these blocks, he will update the bindings.

My only suggestion would be to rename kpss-acc-v2 nodes to 'power-controller@address' and document them so.

Ok so something like this?

    power-controller@f9088000 {
      compatible = "qcom,kpss-acc-v2";
      reg = <0xf9088000 0x1000>,
            <0xf9008000 0x1000>;
    };

Quoted 5 lines

(and I will have to fix dtbs warning as they will be unmatched I think.) Yaml naming:
qcom,kpss-acc-v1.yaml
qcom,kpss-acc-v2.yaml
Right?

Quoted 5 lines

Sounds good to me.

I'd even say clock/qcom,kpss-acc-v1.yaml and arm/msm/qcom,kpss-acc-v2.yaml or maybe power/qcom,kpss-acc-v2.yaml

Wonder if the gcc driver should have the same tretement? It's also a clock-controller driver that doesn't use clock at all... Do you have some info about it?

Quoted 6 lines

Quoted 3 lines

As far as I understand, the kpss-gcc is a normal clock controller, isn't it? It provides clocks to other devices.

Hi again... Having acc-v2 as power-controller would require to set #power-domain-cells = <0>;

Quoted 14 lines

Would that be acceptable? Considering it wouldn't expose any PM domain?

About kpss-gcc we have some device that for some reason doesn't have the required clocks defined in the dts. I checked the related gcc and no PXO defined and no pll8_vote clock defined. (the affected dts are all listed in the related Documentation)

No idea how they currently work with the kpss-gcc driver as these parents are missing. Guess the driver just fails to probe? So this was the question if you had more info about it... since to me it seems just another gcc v2 that doesn't expose clocks but it's just a power-controller just like acc-v2.

Quoted 2 lines

Signature · 1 line

	Ansuel

(Also sorry for the double email)
I'm checking the regs for apq8084 for example (from the dtsi) Are we really sure they are power-controller?

Checking the regs it seems they just changed the location and they placed clock-controller and right after the power-controller. So one can get confused and say that 0xf9... can be all related to power controller. I posted the regs for reference.

acc0 0xf9088000 0x1000
saw0 0xf9089000 0x1000

acc1 0xf9098000 0x1000
saw1 0xf9099000 0x1000

acc2 0xf90a8000 0x1000
saw2 0xf90b9000 0x1000

Anyway while at it there seems to be a bit of confusion about the naming here... We have on ipq8064 and ipq4019 the saw node set as regulator and with the regulator binding but on msm8974 and apq8084 the saw node set as power-controller (with the l2 node with the regulator binding).

Think we should chose a name and fix every dts.
So the main question here is...
Should we keep acc as clock-controller or change it to power-controller (for v2)?

Should we change saw node to regulator or power-controller?

From what I know acc are used to enable the cpu so it seems sane to keep them as clock-controller (even if v2 doesn't export clock) Saw node handle power (and in theory even low power state) so it seems sane to change them to power-controller.

Currently we have no warning for saw node as they are not converted to yaml but as soon as someone convert the txt to yaml then we will have all sort of inconsistency so better take a decision now instead of convert saw to yaml and then change acc node again to fix them for good.

Quoted 80 lines · Christian Marangi

Quoted 79 lines · Christian Marangi

Quoted 78 lines · Dmitry Baryshkov

Quoted 76 lines · Christian Marangi

Quoted 65 lines · Dmitry Baryshkov

Quoted 58 lines · Christian Marangi

Quoted 38 lines · Dmitry Baryshkov

Quoted 37 lines · Christian Marangi

Quoted 19 lines · Dmitry Baryshkov

Quoted 18 lines · Christian Marangi

Quoted 10 lines · Rob Herring

Quoted 8 lines · Christian Marangi

Convert kpss-acc driver Documentation to yaml.
The original Documentation was wrong all along. Fix it while we are
converting it.
The example was wrong as kpss-acc-v2 should only expose the regs but we
don't have any driver that expose additional clocks. The kpss-acc driver
is only specific to v1. For this exact reason, limit all the additional
bindings (clocks, clock-names, clock-output-names and #clock-cells) to
v1 and also flag that these bindings should NOT be used for v2.

Quoted 2 lines

Odd that a clock controller has no clocks, but okay.

As said in the commit v2 is only used for regs. v2 it's only used in arch/arm/mach-qcom/platsmp.c to setup stuff cpu hotplug and bringup.

Quoted 9 lines

Quoted 4 lines

Should we split the 2 driver? To me the acc naming seems to be just recycled for v2 and it's not really a clk controller.

So keeping v2 in arm/msm/qcom,kpss-acc-v2.yaml and v1 moved to clock?

I suspect that qcom,kpss-acc-v2 is misnamed as the "clock-controller". According to msm-3.10, these regions are used by the Krait core regulators.

Well we need to understand how to handle this... change the compatible it's a nono for sure. In platsmp.c they are used for cpu power control so could be that they are actually used to regulators. I would honestly move v1 to clock and leave v2 to arm/msm but I'm not cetain on what name to assign to the 2 yaml.

Quoted 9 lines

Quoted 1 line

What do you think?

This is fine for me. If somebody gets better understanding of underlying hardware and works on actually using these blocks, he will update the bindings.

My only suggestion would be to rename kpss-acc-v2 nodes to 'power-controller@address' and document them so.

Ok so something like this?

    power-controller@f9088000 {
      compatible = "qcom,kpss-acc-v2";
      reg = <0xf9088000 0x1000>,
            <0xf9008000 0x1000>;
    };

Quoted 5 lines

(and I will have to fix dtbs warning as they will be unmatched I think.) Yaml naming:
qcom,kpss-acc-v1.yaml
qcom,kpss-acc-v2.yaml
Right?

Quoted 5 lines

Sounds good to me.

I'd even say clock/qcom,kpss-acc-v1.yaml and arm/msm/qcom,kpss-acc-v2.yaml or maybe power/qcom,kpss-acc-v2.yaml

Wonder if the gcc driver should have the same tretement? It's also a clock-controller driver that doesn't use clock at all... Do you have some info about it?

Quoted 6 lines

Quoted 6 lines

Quoted 3 lines

As far as I understand, the kpss-gcc is a normal clock controller, isn't it? It provides clocks to other devices.

Hi again... Having acc-v2 as power-controller would require to set #power-domain-cells = <0>;

Why? I don't think so. Rob/Krzysztof, please correct me if I'm wrong.

Quoted 14 lines

Quoted 14 lines

Would that be acceptable? Considering it wouldn't expose any PM domain?

About kpss-gcc we have some device that for some reason doesn't have the required clocks defined in the dts. I checked the related gcc and no PXO defined and no pll8_vote clock defined. (the affected dts are all listed in the related Documentation)

No idea how they currently work with the kpss-gcc driver as these parents are missing. Guess the driver just fails to probe? So this was the question if you had more info about it... since to me it seems just another gcc v2 that doesn't expose clocks but it's just a power-controller just like acc-v2.

Quoted 6 lines

Quoted 2 lines

Signature · 1 line

	Ansuel

(Also sorry for the double email)
I'm checking the regs for apq8084 for example (from the dtsi) Are we really sure they are power-controller?

It looks like it's a regularor on steroids. See krait-regulator.c and corresponding bindings in msm-3.10/3.14. So I'd use either the regulator or the power-controller (with significant bias towards controller)

Quoted 31 lines

Checking the regs it seems they just changed the location and they placed clock-controller and right after the power-controller. So one can get confused and say that 0xf9... can be all related to power controller. I posted the regs for reference.

acc0 0xf9088000 0x1000
saw0 0xf9089000 0x1000

acc1 0xf9098000 0x1000
saw1 0xf9099000 0x1000

acc2 0xf90a8000 0x1000
saw2 0xf90b9000 0x1000

Anyway while at it there seems to be a bit of confusion about the naming here... We have on ipq8064 and ipq4019 the saw node set as regulator and with the regulator binding but on msm8974 and apq8084 the saw node set as power-controller (with the l2 node with the regulator binding).

Think we should chose a name and fix every dts.
So the main question here is...
Should we keep acc as clock-controller or change it to power-controller (for v2)?

Should we change saw node to regulator or power-controller?

From what I know acc are used to enable the cpu so it seems sane to keep them as clock-controller (even if v2 doesn't export clock) Saw node handle power (and in theory even low power state) so it seems sane to change them to power-controller.

Quoted 4 lines

Currently we have no warning for saw node as they are not converted to yaml but as soon as someone convert the txt to yaml then we will have all sort of inconsistency so better take a decision now instead of convert saw to yaml and then change acc node again to fix them for good.

The saw is definitely a bigger thing than just a regularor (or a set of them). It is used to control pmics, it handles low-power states, so `power-controller'.

Signature · 2 lines

With best wishes
Dmitry

Rework kpss-gcc driver Documentation to yaml Documentation. The current kpss-gcc Documentation have major problems and can't be converted directly. Introduce various changes to the original Documentation.

Add #clock-cells additional binding as this clock outputs a static clk named acpu_l2_aux with supported compatible.
Only some compatible require and outputs a clock, for the others, set only the reg as a required binding to correctly export the kpss-gcc registers. As the reg is shared also add the required syscon compatible.

Signed-off-by Christian Marangi <[email protected]>

---
 .../bindings/arm/msm/qcom,kpss-gcc.txt        | 44 ---------
 .../bindings/arm/msm/qcom,kpss-gcc.yaml       | 90 +++++++++++++++++++
 2 files changed, 90 insertions(+), 44 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
 create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.yaml

Rework kpss-gcc driver Documentation to yaml Documentation. The current kpss-gcc Documentation have major problems and can't be converted directly. Introduce various changes to the original Documentation.

Add #clock-cells additional binding as this clock outputs a static clk named acpu_l2_aux with supported compatible.
Only some compatible require and outputs a clock, for the others, set only the reg as a required binding to correctly export the kpss-gcc registers. As the reg is shared also add the required syscon compatible.

Signed-off-by Christian Marangi <[email protected]>

---
 .../bindings/arm/msm/qcom,kpss-gcc.txt        | 44 ---------
 .../bindings/arm/msm/qcom,kpss-gcc.yaml       | 90 +++++++++++++++++++
 2 files changed, 90 insertions(+), 44 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
 create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.yaml

Rework kpss-gcc driver Documentation to yaml Documentation. The current kpss-gcc Documentation have major problems and can't be converted directly. Introduce various changes to the original Documentation.

Add #clock-cells additional binding as this clock outputs a static clk named acpu_l2_aux with supported compatible.
Only some compatible require and outputs a clock, for the others, set only the reg as a required binding to correctly export the kpss-gcc registers. As the reg is shared also add the required syscon compatible.

Signed-off-by Christian Marangi <[email protected]>

---
 .../bindings/arm/msm/qcom,kpss-gcc.txt        | 44 ---------
 .../bindings/arm/msm/qcom,kpss-gcc.yaml       | 90 +++++++++++++++++++

 2 files changed, 90 insertions(+), 44 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
 create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.yaml

Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.yaml new file +90 -0

new file mode 100644
index 000000000000..27f7df7e3ec4
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/msm/qcom,kpss-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Krait Processor Sub-system (KPSS) Global Clock Controller (GCC)
+
+maintainers:
+  - Christian Marangi <[email protected]>
+
+description: |
+  Krait Processor Sub-system (KPSS) Global Clock Controller (GCC). Used
+  to control L2 mux (in the current implementation) and provide access
+  to the kpss-gcc registers.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - qcom,kpss-gcc-ipq8064
+          - qcom,kpss-gcc-apq8064
+          - qcom,kpss-gcc-msm8974
+          - qcom,kpss-gcc-msm8960
+          - qcom,kpss-gcc-msm8660
+          - qcom,kpss-gcc-mdm9615
+      - const: qcom,kpss-gcc
+      - const: syscon
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: phandle to pll8_vote
+      - description: phandle to pxo_board
+
+  clock-names:
+    items:
+      - const: pll8_vote
+      - const: pxo
+
+  '#clock-cells':
+    const: 0
+
+required:
+  - compatible
+  - reg
+
+if:
+  properties:
+    compatible:
+      contains:
+        enum:
+          - qcom,kpss-gcc-ipq8064
+          - qcom,kpss-gcc-apq8064
+          - qcom,kpss-gcc-msm8974
+          - qcom,kpss-gcc-msm8960
+then:
+  required:
+    - clocks
+    - clock-names
+    - '#clock-cells'
+else:
+  properties:
+    clock: false
+    clock-names: false
+    '#clock-cells': false
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/qcom,gcc-ipq806x.h>
+
+    clock-controller@2011000 {
+      compatible = "qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc", "syscon";
+      reg = <0x2011000 0x1000>;
+      clocks = <&gcc PLL8_VOTE>, <&pxo_board>;
+      clock-names = "pll8_vote", "pxo";
+      #clock-cells = <0>;
+    };
+
+  - |
+    clock-controller@2011000 {
+      compatible = "qcom,kpss-gcc-mdm9615", "qcom,kpss-gcc", "syscon";
+      reg = <0x02011000 0x1000>;
+    };
+...
+

Signature · 1 line

2.37.2

Fix dtbs_check warning now that we have a correct kpss-gcc yaml schema. Add additional qcom,kpss-gcc compatible to differentiate devices where kpss-gcc should provide a clk and where kpss-gcc should just provide the registers and the syscon phandle.
Add missing #clock-cells and remove useless clock-output-names for ipq806x.
Add missing bindings for msm8960 and apq8064 kpss-gcc node.

Signed-off-by Christian Marangi <[email protected]>

---
 arch/arm/boot/dts/qcom-apq8064.dtsi | 5 ++++-
 arch/arm/boot/dts/qcom-ipq8064.dtsi | 4 ++--
 arch/arm/boot/dts/qcom-mdm9615.dtsi | 2 +-
 arch/arm/boot/dts/qcom-msm8660.dtsi | 2 +-
 arch/arm/boot/dts/qcom-msm8960.dtsi | 7 +++++--
 5 files changed, 13 insertions(+), 7 deletions(-)

Quoted 8 lines · Christian Marangi

Fix dtbs_check warning now that we have a correct kpss-gcc yaml schema. Add additional qcom,kpss-gcc compatible to differentiate devices where kpss-gcc should provide a clk and where kpss-gcc should just provide the registers and the syscon phandle.
Add missing #clock-cells and remove useless clock-output-names for ipq806x.
Add missing bindings for msm8960 and apq8064 kpss-gcc node.

Quoted 8 lines

Signed-off-by Christian Marangi <[email protected]>

---
 arch/arm/boot/dts/qcom-apq8064.dtsi | 5 ++++-
 arch/arm/boot/dts/qcom-ipq8064.dtsi | 4 ++--
 arch/arm/boot/dts/qcom-mdm9615.dtsi | 2 +-
 arch/arm/boot/dts/qcom-msm8660.dtsi | 2 +-
 arch/arm/boot/dts/qcom-msm8960.dtsi | 7 +++++--
 5 files changed, 13 insertions(+), 7 deletions(-)

warning: 1 line adds whitespace errors.