2020-10-21 06:28:44

by Manivannan Sadhasivam

[permalink] [raw]
Subject: [PATCH v3 1/2] dt-bindings: arm: cpus: Document 'qcom,freq-domain' property

Add devicetree documentation for 'qcom,freq-domain' property specific
to Qualcomm CPUs. This property is used to reference the CPUFREQ node
along with Domain ID (0/1).

Signed-off-by: Manivannan Sadhasivam <[email protected]>
---
Documentation/devicetree/bindings/arm/cpus.yaml | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
index 1222bf1831fa..f40564bf004f 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -290,6 +290,12 @@ properties:

* arm/msm/qcom,kpss-acc.txt

+ qcom,freq-domain:
+ $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ description: |
+ CPUs supporting freq-domain must set their "qcom,freq-domain" property
+ with phandle to a cpufreq_hw node followed by the Domain ID(0/1).
+
rockchip,pmu:
$ref: '/schemas/types.yaml#/definitions/phandle'
description: |
--
2.17.1


2020-10-21 06:29:48

by Manivannan Sadhasivam

[permalink] [raw]
Subject: [PATCH v3 2/2] dt-bindings: cpufreq: cpufreq-qcom-hw: Convert to YAML bindings

Convert Qualcomm cpufreq devicetree binding to YAML.

Signed-off-by: Manivannan Sadhasivam <[email protected]>
---

Changes in v3:

* Added "qcom,freq-domain" property to ARM CPU binding.

.../bindings/cpufreq/cpufreq-qcom-hw.txt | 172 ---------------
.../bindings/cpufreq/cpufreq-qcom-hw.yaml | 204 ++++++++++++++++++
2 files changed, 204 insertions(+), 172 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
deleted file mode 100644
index 9299028ee712..000000000000
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
+++ /dev/null
@@ -1,172 +0,0 @@
-Qualcomm Technologies, Inc. CPUFREQ Bindings
-
-CPUFREQ HW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI)
-SoCs to manage frequency in hardware. It is capable of controlling frequency
-for multiple clusters.
-
-Properties:
-- compatible
- Usage: required
- Value type: <string>
- Definition: must be "qcom,cpufreq-hw" or "qcom,cpufreq-epss".
-
-- clocks
- Usage: required
- Value type: <phandle> From common clock binding.
- Definition: clock handle for XO clock and GPLL0 clock.
-
-- clock-names
- Usage: required
- Value type: <string> From common clock binding.
- Definition: must be "xo", "alternate".
-
-- reg
- Usage: required
- Value type: <prop-encoded-array>
- Definition: Addresses and sizes for the memory of the HW bases in
- each frequency domain.
-- reg-names
- Usage: Optional
- Value type: <string>
- Definition: Frequency domain name i.e.
- "freq-domain0", "freq-domain1".
-
-- #freq-domain-cells:
- Usage: required.
- Definition: Number of cells in a freqency domain specifier.
-
-* Property qcom,freq-domain
-Devices supporting freq-domain must set their "qcom,freq-domain" property with
-phandle to a cpufreq_hw followed by the Domain ID(0/1) in the CPU DT node.
-
-
-Example:
-
-Example 1: Dual-cluster, Quad-core per cluster. CPUs within a cluster switch
-DCVS state together.
-
-/ {
- cpus {
- #address-cells = <2>;
- #size-cells = <0>;
-
- CPU0: cpu@0 {
- device_type = "cpu";
- compatible = "qcom,kryo385";
- reg = <0x0 0x0>;
- enable-method = "psci";
- next-level-cache = <&L2_0>;
- qcom,freq-domain = <&cpufreq_hw 0>;
- L2_0: l2-cache {
- compatible = "cache";
- next-level-cache = <&L3_0>;
- L3_0: l3-cache {
- compatible = "cache";
- };
- };
- };
-
- CPU1: cpu@100 {
- device_type = "cpu";
- compatible = "qcom,kryo385";
- reg = <0x0 0x100>;
- enable-method = "psci";
- next-level-cache = <&L2_100>;
- qcom,freq-domain = <&cpufreq_hw 0>;
- L2_100: l2-cache {
- compatible = "cache";
- next-level-cache = <&L3_0>;
- };
- };
-
- CPU2: cpu@200 {
- device_type = "cpu";
- compatible = "qcom,kryo385";
- reg = <0x0 0x200>;
- enable-method = "psci";
- next-level-cache = <&L2_200>;
- qcom,freq-domain = <&cpufreq_hw 0>;
- L2_200: l2-cache {
- compatible = "cache";
- next-level-cache = <&L3_0>;
- };
- };
-
- CPU3: cpu@300 {
- device_type = "cpu";
- compatible = "qcom,kryo385";
- reg = <0x0 0x300>;
- enable-method = "psci";
- next-level-cache = <&L2_300>;
- qcom,freq-domain = <&cpufreq_hw 0>;
- L2_300: l2-cache {
- compatible = "cache";
- next-level-cache = <&L3_0>;
- };
- };
-
- CPU4: cpu@400 {
- device_type = "cpu";
- compatible = "qcom,kryo385";
- reg = <0x0 0x400>;
- enable-method = "psci";
- next-level-cache = <&L2_400>;
- qcom,freq-domain = <&cpufreq_hw 1>;
- L2_400: l2-cache {
- compatible = "cache";
- next-level-cache = <&L3_0>;
- };
- };
-
- CPU5: cpu@500 {
- device_type = "cpu";
- compatible = "qcom,kryo385";
- reg = <0x0 0x500>;
- enable-method = "psci";
- next-level-cache = <&L2_500>;
- qcom,freq-domain = <&cpufreq_hw 1>;
- L2_500: l2-cache {
- compatible = "cache";
- next-level-cache = <&L3_0>;
- };
- };
-
- CPU6: cpu@600 {
- device_type = "cpu";
- compatible = "qcom,kryo385";
- reg = <0x0 0x600>;
- enable-method = "psci";
- next-level-cache = <&L2_600>;
- qcom,freq-domain = <&cpufreq_hw 1>;
- L2_600: l2-cache {
- compatible = "cache";
- next-level-cache = <&L3_0>;
- };
- };
-
- CPU7: cpu@700 {
- device_type = "cpu";
- compatible = "qcom,kryo385";
- reg = <0x0 0x700>;
- enable-method = "psci";
- next-level-cache = <&L2_700>;
- qcom,freq-domain = <&cpufreq_hw 1>;
- L2_700: l2-cache {
- compatible = "cache";
- next-level-cache = <&L3_0>;
- };
- };
- };
-
- soc {
- cpufreq_hw: cpufreq@17d43000 {
- compatible = "qcom,cpufreq-hw";
- reg = <0x17d43000 0x1400>, <0x17d45800 0x1400>;
- reg-names = "freq-domain0", "freq-domain1";
-
- clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
- clock-names = "xo", "alternate";
-
- #freq-domain-cells = <1>;
- };
-}
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
new file mode 100644
index 000000000000..bc81b6203e27
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
@@ -0,0 +1,204 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cpufreq/cpufreq-qcom-hw.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. CPUFREQ
+
+maintainers:
+ - Manivannan Sadhasivam <[email protected]>
+
+description: |
+
+ CPUFREQ HW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI)
+ SoCs to manage frequency in hardware. It is capable of controlling frequency
+ for multiple clusters.
+
+properties:
+ compatible:
+ oneOf:
+ - description: v1 of CPUFREQ HW
+ items:
+ - const: qcom,cpufreq-hw
+
+ - description: v2 of CPUFREQ HW (EPSS)
+ items:
+ - enum:
+ - qcom,sm8250-cpufreq-epss
+ - const: qcom,cpufreq-epss
+
+ reg:
+ minItems: 2
+ maxItems: 3
+ items:
+ - description: Frequency domain 0 register region
+ - description: Frequency domain 1 register region
+ - description: Frequency domain 2 register region
+
+ reg-names:
+ minItems: 2
+ maxItems: 3
+ items:
+ - const: freq-domain0
+ - const: freq-domain1
+ - const: freq-domain2
+
+ clocks:
+ items:
+ - description: XO Clock
+ - description: GPLL0 Clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: alternate
+
+ '#freq-domain-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - '#freq-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sdm845.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+
+ // Example 1: Dual-cluster, Quad-core per cluster. CPUs within a cluster
+ // switch DCVS state together.
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "qcom,kryo385";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <&L2_0>;
+ qcom,freq-domain = <&cpufreq_hw 0>;
+ L2_0: l2-cache {
+ compatible = "cache";
+ next-level-cache = <&L3_0>;
+ L3_0: l3-cache {
+ compatible = "cache";
+ };
+ };
+ };
+
+ CPU1: cpu@100 {
+ device_type = "cpu";
+ compatible = "qcom,kryo385";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ next-level-cache = <&L2_100>;
+ qcom,freq-domain = <&cpufreq_hw 0>;
+ L2_100: l2-cache {
+ compatible = "cache";
+ next-level-cache = <&L3_0>;
+ };
+ };
+
+ CPU2: cpu@200 {
+ device_type = "cpu";
+ compatible = "qcom,kryo385";
+ reg = <0x0 0x200>;
+ enable-method = "psci";
+ next-level-cache = <&L2_200>;
+ qcom,freq-domain = <&cpufreq_hw 0>;
+ L2_200: l2-cache {
+ compatible = "cache";
+ next-level-cache = <&L3_0>;
+ };
+ };
+
+ CPU3: cpu@300 {
+ device_type = "cpu";
+ compatible = "qcom,kryo385";
+ reg = <0x0 0x300>;
+ enable-method = "psci";
+ next-level-cache = <&L2_300>;
+ qcom,freq-domain = <&cpufreq_hw 0>;
+ L2_300: l2-cache {
+ compatible = "cache";
+ next-level-cache = <&L3_0>;
+ };
+ };
+
+ CPU4: cpu@400 {
+ device_type = "cpu";
+ compatible = "qcom,kryo385";
+ reg = <0x0 0x400>;
+ enable-method = "psci";
+ next-level-cache = <&L2_400>;
+ qcom,freq-domain = <&cpufreq_hw 1>;
+ L2_400: l2-cache {
+ compatible = "cache";
+ next-level-cache = <&L3_0>;
+ };
+ };
+
+ CPU5: cpu@500 {
+ device_type = "cpu";
+ compatible = "qcom,kryo385";
+ reg = <0x0 0x500>;
+ enable-method = "psci";
+ next-level-cache = <&L2_500>;
+ qcom,freq-domain = <&cpufreq_hw 1>;
+ L2_500: l2-cache {
+ compatible = "cache";
+ next-level-cache = <&L3_0>;
+ };
+ };
+
+ CPU6: cpu@600 {
+ device_type = "cpu";
+ compatible = "qcom,kryo385";
+ reg = <0x0 0x600>;
+ enable-method = "psci";
+ next-level-cache = <&L2_600>;
+ qcom,freq-domain = <&cpufreq_hw 1>;
+ L2_600: l2-cache {
+ compatible = "cache";
+ next-level-cache = <&L3_0>;
+ };
+ };
+
+ CPU7: cpu@700 {
+ device_type = "cpu";
+ compatible = "qcom,kryo385";
+ reg = <0x0 0x700>;
+ enable-method = "psci";
+ next-level-cache = <&L2_700>;
+ qcom,freq-domain = <&cpufreq_hw 1>;
+ L2_700: l2-cache {
+ compatible = "cache";
+ next-level-cache = <&L3_0>;
+ };
+ };
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpufreq@17d43000 {
+ compatible = "qcom,cpufreq-hw";
+ reg = <0x17d43000 0x1400>, <0x17d45800 0x1400>;
+ reg-names = "freq-domain0", "freq-domain1";
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+ clock-names = "xo", "alternate";
+
+ #freq-domain-cells = <1>;
+ };
+ };
+...
--
2.17.1

2020-10-21 12:09:37

by Hector Yuan

[permalink] [raw]
Subject: Re: [PATCH v3 1/2] dt-bindings: arm: cpus: Document 'qcom,freq-domain' property

Hi, Manivannan

On Tue, 2020-10-20 at 21:09 +0530, Manivannan Sadhasivam wrote:
> Add devicetree documentation for 'qcom,freq-domain' property specific
> to Qualcomm CPUs. This property is used to reference the CPUFREQ node
> along with Domain ID (0/1).
>
> Signed-off-by: Manivannan Sadhasivam <[email protected]>
> ---
> Documentation/devicetree/bindings/arm/cpus.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
> index 1222bf1831fa..f40564bf004f 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.yaml
> +++ b/Documentation/devicetree/bindings/arm/cpus.yaml
> @@ -290,6 +290,12 @@ properties:
>
> * arm/msm/qcom,kpss-acc.txt
>
> + qcom,freq-domain:
Do you mind to change "qcom, freq-domain" to common naming? or drop the
prefix. So that we can use this CPU node and map it to each freq-domain.
Thanks a lot.

> + $ref: '/schemas/types.yaml#/definitions/phandle-array'
> + description: |
> + CPUs supporting freq-domain must set their "qcom,freq-domain" property
> + with phandle to a cpufreq_hw node followed by the Domain ID(0/1).
> +
> rockchip,pmu:
> $ref: '/schemas/types.yaml#/definitions/phandle'
> description: |

2020-10-21 13:36:45

by Viresh Kumar

[permalink] [raw]
Subject: Re: [PATCH v3 1/2] dt-bindings: arm: cpus: Document 'qcom,freq-domain' property

On 21-10-20, 15:29, Manivannan Sadhasivam wrote:
> Hi,
>
> On Wed, Oct 21, 2020 at 10:36:43AM +0800, Hector Yuan wrote:
> > Hi, Manivannan
> >
> > On Tue, 2020-10-20 at 21:09 +0530, Manivannan Sadhasivam wrote:
> > > Add devicetree documentation for 'qcom,freq-domain' property specific
> > > to Qualcomm CPUs. This property is used to reference the CPUFREQ node
> > > along with Domain ID (0/1).
> > >
> > > Signed-off-by: Manivannan Sadhasivam <[email protected]>
> > > ---
> > > Documentation/devicetree/bindings/arm/cpus.yaml | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
> > > index 1222bf1831fa..f40564bf004f 100644
> > > --- a/Documentation/devicetree/bindings/arm/cpus.yaml
> > > +++ b/Documentation/devicetree/bindings/arm/cpus.yaml
> > > @@ -290,6 +290,12 @@ properties:
> > >
> > > * arm/msm/qcom,kpss-acc.txt
> > >
> > > + qcom,freq-domain:
> > Do you mind to change "qcom, freq-domain" to common naming? or drop the
> > prefix. So that we can use this CPU node and map it to each freq-domain.
> > Thanks a lot.
>
> I can do that but did the domain value match for other platforms as well?

I am not sure if you can. The code needs to be backward compatible so it can
support all devices shipped with older bootloaders and latest kernels. And so
changing the bindings isn't a good idea normally.

>
> >
> > > + $ref: '/schemas/types.yaml#/definitions/phandle-array'
> > > + description: |
> > > + CPUs supporting freq-domain must set their "qcom,freq-domain" property
> > > + with phandle to a cpufreq_hw node followed by the Domain ID(0/1).
> > > +
> > > rockchip,pmu:
> > > $ref: '/schemas/types.yaml#/definitions/phandle'
> > > description: |
> >

--
viresh

2020-10-21 21:51:58

by Manivannan Sadhasivam

[permalink] [raw]
Subject: Re: [PATCH v3 1/2] dt-bindings: arm: cpus: Document 'qcom,freq-domain' property

Hi,

On Wed, Oct 21, 2020 at 10:36:43AM +0800, Hector Yuan wrote:
> Hi, Manivannan
>
> On Tue, 2020-10-20 at 21:09 +0530, Manivannan Sadhasivam wrote:
> > Add devicetree documentation for 'qcom,freq-domain' property specific
> > to Qualcomm CPUs. This property is used to reference the CPUFREQ node
> > along with Domain ID (0/1).
> >
> > Signed-off-by: Manivannan Sadhasivam <[email protected]>
> > ---
> > Documentation/devicetree/bindings/arm/cpus.yaml | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
> > index 1222bf1831fa..f40564bf004f 100644
> > --- a/Documentation/devicetree/bindings/arm/cpus.yaml
> > +++ b/Documentation/devicetree/bindings/arm/cpus.yaml
> > @@ -290,6 +290,12 @@ properties:
> >
> > * arm/msm/qcom,kpss-acc.txt
> >
> > + qcom,freq-domain:
> Do you mind to change "qcom, freq-domain" to common naming? or drop the
> prefix. So that we can use this CPU node and map it to each freq-domain.
> Thanks a lot.

I can do that but did the domain value match for other platforms as well?

Thanks,
Mani

>
> > + $ref: '/schemas/types.yaml#/definitions/phandle-array'
> > + description: |
> > + CPUs supporting freq-domain must set their "qcom,freq-domain" property
> > + with phandle to a cpufreq_hw node followed by the Domain ID(0/1).
> > +
> > rockchip,pmu:
> > $ref: '/schemas/types.yaml#/definitions/phandle'
> > description: |
>

2020-10-26 17:54:05

by Rob Herring

[permalink] [raw]
Subject: Re: [PATCH v3 1/2] dt-bindings: arm: cpus: Document 'qcom,freq-domain' property

On Tue, Oct 20, 2020 at 09:09:43PM +0530, Manivannan Sadhasivam wrote:
> Add devicetree documentation for 'qcom,freq-domain' property specific
> to Qualcomm CPUs. This property is used to reference the CPUFREQ node
> along with Domain ID (0/1).
>
> Signed-off-by: Manivannan Sadhasivam <[email protected]>
> ---
> Documentation/devicetree/bindings/arm/cpus.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
> index 1222bf1831fa..f40564bf004f 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.yaml
> +++ b/Documentation/devicetree/bindings/arm/cpus.yaml
> @@ -290,6 +290,12 @@ properties:
>
> * arm/msm/qcom,kpss-acc.txt
>
> + qcom,freq-domain:
> + $ref: '/schemas/types.yaml#/definitions/phandle-array'
> + description: |
> + CPUs supporting freq-domain must set their "qcom,freq-domain" property
> + with phandle to a cpufreq_hw node followed by the Domain ID(0/1).

There's no 3 patches doing the same thing. Mediatek and SCMI are the
others. This will need to be common.

> +
> rockchip,pmu:
> $ref: '/schemas/types.yaml#/definitions/phandle'
> description: |
> --
> 2.17.1
>

2020-10-26 17:57:30

by Bjorn Andersson

[permalink] [raw]
Subject: Re: [PATCH v3 1/2] dt-bindings: arm: cpus: Document 'qcom,freq-domain' property

On Mon 26 Oct 09:32 CDT 2020, Rob Herring wrote:

> On Tue, Oct 20, 2020 at 09:09:43PM +0530, Manivannan Sadhasivam wrote:
> > Add devicetree documentation for 'qcom,freq-domain' property specific
> > to Qualcomm CPUs. This property is used to reference the CPUFREQ node
> > along with Domain ID (0/1).
> >
> > Signed-off-by: Manivannan Sadhasivam <[email protected]>
> > ---
> > Documentation/devicetree/bindings/arm/cpus.yaml | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
> > index 1222bf1831fa..f40564bf004f 100644
> > --- a/Documentation/devicetree/bindings/arm/cpus.yaml
> > +++ b/Documentation/devicetree/bindings/arm/cpus.yaml
> > @@ -290,6 +290,12 @@ properties:
> >
> > * arm/msm/qcom,kpss-acc.txt
> >
> > + qcom,freq-domain:
> > + $ref: '/schemas/types.yaml#/definitions/phandle-array'
> > + description: |
> > + CPUs supporting freq-domain must set their "qcom,freq-domain" property
> > + with phandle to a cpufreq_hw node followed by the Domain ID(0/1).
>
> There's no 3 patches doing the same thing. Mediatek and SCMI are the
> others. This will need to be common.
>

This property is used by existing dtbs for Qualcomm sdm845, sm8150,
sm8250 and sc7180 based devices, so I expect that the support for the
existing property will stay.

Regards,
Bjorn

> > +
> > rockchip,pmu:
> > $ref: '/schemas/types.yaml#/definitions/phandle'
> > description: |
> > --
> > 2.17.1
> >

2020-10-29 09:58:57

by Rob Herring

[permalink] [raw]
Subject: Re: [PATCH v3 1/2] dt-bindings: arm: cpus: Document 'qcom,freq-domain' property

On Wed, Oct 21, 2020 at 04:20:37PM +0530, Viresh Kumar wrote:
> On 21-10-20, 15:29, Manivannan Sadhasivam wrote:
> > Hi,
> >
> > On Wed, Oct 21, 2020 at 10:36:43AM +0800, Hector Yuan wrote:
> > > Hi, Manivannan
> > >
> > > On Tue, 2020-10-20 at 21:09 +0530, Manivannan Sadhasivam wrote:
> > > > Add devicetree documentation for 'qcom,freq-domain' property specific
> > > > to Qualcomm CPUs. This property is used to reference the CPUFREQ node
> > > > along with Domain ID (0/1).
> > > >
> > > > Signed-off-by: Manivannan Sadhasivam <[email protected]>
> > > > ---
> > > > Documentation/devicetree/bindings/arm/cpus.yaml | 6 ++++++
> > > > 1 file changed, 6 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
> > > > index 1222bf1831fa..f40564bf004f 100644
> > > > --- a/Documentation/devicetree/bindings/arm/cpus.yaml
> > > > +++ b/Documentation/devicetree/bindings/arm/cpus.yaml
> > > > @@ -290,6 +290,12 @@ properties:
> > > >
> > > > * arm/msm/qcom,kpss-acc.txt
> > > >
> > > > + qcom,freq-domain:
> > > Do you mind to change "qcom, freq-domain" to common naming? or drop the
> > > prefix. So that we can use this CPU node and map it to each freq-domain.
> > > Thanks a lot.
> >
> > I can do that but did the domain value match for other platforms as well?
>
> I am not sure if you can. The code needs to be backward compatible so it can
> support all devices shipped with older bootloaders and latest kernels. And so
> changing the bindings isn't a good idea normally.

It can be done. We'd need to do the following:

- schema defines the common property/binding.
- The kernel supports both names and that is backported to stable.
- Update all the Qcom dts files to the new binding

Whether we actually do that or not, I'd like to keep the option open.
Aligning the current proposals should be possible. My concern is more
about what's the next addition and non-cpu device support.

Rob

2020-10-29 10:00:02

by Rob Herring

[permalink] [raw]
Subject: Re: [PATCH v3 1/2] dt-bindings: arm: cpus: Document 'qcom,freq-domain' property

On Mon, Oct 26, 2020 at 09:51:08AM -0500, Bjorn Andersson wrote:
> On Mon 26 Oct 09:32 CDT 2020, Rob Herring wrote:
>
> > On Tue, Oct 20, 2020 at 09:09:43PM +0530, Manivannan Sadhasivam wrote:
> > > Add devicetree documentation for 'qcom,freq-domain' property specific
> > > to Qualcomm CPUs. This property is used to reference the CPUFREQ node
> > > along with Domain ID (0/1).
> > >
> > > Signed-off-by: Manivannan Sadhasivam <[email protected]>
> > > ---
> > > Documentation/devicetree/bindings/arm/cpus.yaml | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
> > > index 1222bf1831fa..f40564bf004f 100644
> > > --- a/Documentation/devicetree/bindings/arm/cpus.yaml
> > > +++ b/Documentation/devicetree/bindings/arm/cpus.yaml
> > > @@ -290,6 +290,12 @@ properties:
> > >
> > > * arm/msm/qcom,kpss-acc.txt
> > >
> > > + qcom,freq-domain:
> > > + $ref: '/schemas/types.yaml#/definitions/phandle-array'
> > > + description: |
> > > + CPUs supporting freq-domain must set their "qcom,freq-domain" property
> > > + with phandle to a cpufreq_hw node followed by the Domain ID(0/1).
> >
> > There's no 3 patches doing the same thing. Mediatek and SCMI are the
> > others. This will need to be common.
> >
>
> This property is used by existing dtbs for Qualcomm sdm845, sm8150,
> sm8250 and sc7180 based devices, so I expect that the support for the
> existing property will stay.

Indeed. Any of these can tolerate a change here?

We should still take QCom into account for whatever is come up with for
a common binding.

Rob

2020-12-08 15:48:46

by Manivannan Sadhasivam

[permalink] [raw]
Subject: Re: [PATCH v3 1/2] dt-bindings: arm: cpus: Document 'qcom,freq-domain' property

On Wed, Oct 28, 2020 at 10:46:37AM -0500, Rob Herring wrote:
> On Wed, Oct 21, 2020 at 04:20:37PM +0530, Viresh Kumar wrote:
> > On 21-10-20, 15:29, Manivannan Sadhasivam wrote:
> > > Hi,
> > >
> > > On Wed, Oct 21, 2020 at 10:36:43AM +0800, Hector Yuan wrote:
> > > > Hi, Manivannan
> > > >
> > > > On Tue, 2020-10-20 at 21:09 +0530, Manivannan Sadhasivam wrote:
> > > > > Add devicetree documentation for 'qcom,freq-domain' property specific
> > > > > to Qualcomm CPUs. This property is used to reference the CPUFREQ node
> > > > > along with Domain ID (0/1).
> > > > >
> > > > > Signed-off-by: Manivannan Sadhasivam <[email protected]>
> > > > > ---
> > > > > Documentation/devicetree/bindings/arm/cpus.yaml | 6 ++++++
> > > > > 1 file changed, 6 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
> > > > > index 1222bf1831fa..f40564bf004f 100644
> > > > > --- a/Documentation/devicetree/bindings/arm/cpus.yaml
> > > > > +++ b/Documentation/devicetree/bindings/arm/cpus.yaml
> > > > > @@ -290,6 +290,12 @@ properties:
> > > > >
> > > > > * arm/msm/qcom,kpss-acc.txt
> > > > >
> > > > > + qcom,freq-domain:
> > > > Do you mind to change "qcom, freq-domain" to common naming? or drop the
> > > > prefix. So that we can use this CPU node and map it to each freq-domain.
> > > > Thanks a lot.
> > >
> > > I can do that but did the domain value match for other platforms as well?
> >
> > I am not sure if you can. The code needs to be backward compatible so it can
> > support all devices shipped with older bootloaders and latest kernels. And so
> > changing the bindings isn't a good idea normally.
>
> It can be done. We'd need to do the following:
>
> - schema defines the common property/binding.
> - The kernel supports both names and that is backported to stable.
> - Update all the Qcom dts files to the new binding
>
> Whether we actually do that or not, I'd like to keep the option open.
> Aligning the current proposals should be possible. My concern is more
> about what's the next addition and non-cpu device support.
>

In the meantime can we get this series merged?

Thanks,
Mani

> Rob