R: R: [RFC PATCH v2 2/2] dt-bindings: cpufreq: Document Krait CPU Cache scaling
> -Messaggio originale-
> Da: Sudeep Holla
> Inviato: lunedì 10 agosto 2020 14:45
> A: ansuels...@gmail.com
> Cc: 'Viresh Kumar' ; 'Rafael J. Wysocki'
> ; 'Rob Herring' ; linux-
> p...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Oggetto: Re: R: [RFC PATCH v2 2/2] dt-bindings: cpufreq: Document Krait
> CPU Cache scaling
>
> On Mon, Aug 10, 2020 at 01:15:24PM +0200, ansuels...@gmail.com
> wrote:
> >
> >
> > > -Messaggio originale-
> > > Da: Sudeep Holla
> > > Inviato: lunedì 10 agosto 2020 10:02
> > > A: Ansuel Smith
> > > Cc: Viresh Kumar ; Rafael J. Wysocki
> > > ; Rob Herring ; linux-
> > > p...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> > > ker...@vger.kernel.org
> > > Oggetto: Re: [RFC PATCH v2 2/2] dt-bindings: cpufreq: Document Krait
> CPU
> > > Cache scaling
> > >
> > > On Sat, Aug 08, 2020 at 01:49:12AM +0200, Ansuel Smith wrote:
> > > > Document dedicated Krait CPU Cache Scaling driver.
> > > >
> > > > Signed-off-by: Ansuel Smith
> > > > ---
> > > > .../bindings/cpufreq/krait-cache-scale.yaml | 92
> > > +++
> > > > 1 file changed, 92 insertions(+)
> > > > create mode 100644
> Documentation/devicetree/bindings/cpufreq/krait-
> > > cache-scale.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/cpufreq/krait-cache-
> > > scale.yaml b/Documentation/devicetree/bindings/cpufreq/krait-cache-
> > > scale.yaml
> > > > new file mode 100644
> > > > index ..f10b1f386a99
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/cpufreq/krait-cache-
> > > scale.yaml
> > > > @@ -0,0 +1,92 @@
> > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/cpufreq/krait-cache-scale.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Krait Cpu Cache Frequency Scaling dedicated driver
> > > > +
> > > > +maintainers:
> > > > + - Ansuel Smith
> > > > +
> > > > +description: |
> > > > + This Scale the Krait CPU Cache Frequency and optionally voltage
> > > > + when the Cpu Frequency is changed (using the cpufreq notifier).
> > > > +
> > > > + Cache is scaled with the max frequency across all core and the
cache
> > > > + frequency will scale based on the configured threshold in the
dts.
> > > > +
> > > > + The cache is hardcoded to 3 frequency bin, idle, nominal and
high.
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > +const: qcom,krait-cache
> > > > +
> > >
> > > How does this fit in the standard cache hierarchy nodes ? Extend the
> > > example to cover that.
> > >
> >
> > I think i didn't understand this question. You mean that I should put
> > in the example how the standard l2 cache nodes are defined?
> >
>
> I was referring to something like below which I found now in
> arch/arm/boot/dts/qcom-msm8974.dtsi:
> L2: l2-cache {
> compatible = "cache";
> cache-level = <2>;
> qcom,saw = <_l2>;
> };
>
> > > > + clocks:
> > > > +description: Phandle to the L2 CPU clock
> > > > +
> > > > + clock-names:
> > > > +const: "l2"
> > > > +
> > > > + voltage-tolerance:
> > > > +description: Same voltage tollerance of the Krait CPU
> > > > +
> > > > + l2-rates:
> > > > +description: |
> > > > + Frequency the L2 cache will be scaled at.
> > > > + Value is in Hz.
> > > > +$ref: /schemas/types.yaml#/definitions/uint32-array
> > > > +items:
> > > > + - description: idle
> > > > + - description: nominal
> > > > + - description: high
> > > > +
> > >
> > > Why can't you re-use the standard OPP v2 bindings ?
> > >
> >
> > Isn't overkill to use the OPP v2 bindings to represent the the microvolt
> > related to the le freq? Is the OPP v1 sufficient?
>
> Should be fine if it is allowed. v2 came out in the flow of my thought
> and was not intentional.
>
> > Also I can't find a way to reflect this specific case where the l2 rates
> > are changed based on the cpu freq value? Any idea about that?
> >
>
> OK, I am always opposed to giving such independent controls in the kernel
> as one can play around say max cpu freq and lowest cache or vice-versa
> and create instabilities. IMO this should be completely hidden from OS.
> But I know these are old platforms, so I will shut my mouth ;)
>
If we really want to deny this practice, I can add a check in the probe
function to fail if the l2 freq threshold is less than the cpu freq.
> --
> Regards,
> Sudeep
Re: R: [RFC PATCH v2 2/2] dt-bindings: cpufreq: Document Krait CPU Cache scaling
On Mon, Aug 10, 2020 at 01:15:24PM +0200, ansuels...@gmail.com wrote:
>
>
> > -Messaggio originale-
> > Da: Sudeep Holla
> > Inviato: lunedì 10 agosto 2020 10:02
> > A: Ansuel Smith
> > Cc: Viresh Kumar ; Rafael J. Wysocki
> > ; Rob Herring ; linux-
> > p...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> > ker...@vger.kernel.org
> > Oggetto: Re: [RFC PATCH v2 2/2] dt-bindings: cpufreq: Document Krait CPU
> > Cache scaling
> >
> > On Sat, Aug 08, 2020 at 01:49:12AM +0200, Ansuel Smith wrote:
> > > Document dedicated Krait CPU Cache Scaling driver.
> > >
> > > Signed-off-by: Ansuel Smith
> > > ---
> > > .../bindings/cpufreq/krait-cache-scale.yaml | 92
> > +++
> > > 1 file changed, 92 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/cpufreq/krait-
> > cache-scale.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/cpufreq/krait-cache-
> > scale.yaml b/Documentation/devicetree/bindings/cpufreq/krait-cache-
> > scale.yaml
> > > new file mode 100644
> > > index ..f10b1f386a99
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/cpufreq/krait-cache-
> > scale.yaml
> > > @@ -0,0 +1,92 @@
> > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/cpufreq/krait-cache-scale.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Krait Cpu Cache Frequency Scaling dedicated driver
> > > +
> > > +maintainers:
> > > + - Ansuel Smith
> > > +
> > > +description: |
> > > + This Scale the Krait CPU Cache Frequency and optionally voltage
> > > + when the Cpu Frequency is changed (using the cpufreq notifier).
> > > +
> > > + Cache is scaled with the max frequency across all core and the cache
> > > + frequency will scale based on the configured threshold in the dts.
> > > +
> > > + The cache is hardcoded to 3 frequency bin, idle, nominal and high.
> > > +
> > > +properties:
> > > + compatible:
> > > +const: qcom,krait-cache
> > > +
> >
> > How does this fit in the standard cache hierarchy nodes ? Extend the
> > example to cover that.
> >
>
> I think i didn't understand this question. You mean that I should put
> in the example how the standard l2 cache nodes are defined?
>
I was referring to something like below which I found now in
arch/arm/boot/dts/qcom-msm8974.dtsi:
L2: l2-cache {
compatible = "cache";
cache-level = <2>;
qcom,saw = <_l2>;
};
> > > + clocks:
> > > +description: Phandle to the L2 CPU clock
> > > +
> > > + clock-names:
> > > +const: "l2"
> > > +
> > > + voltage-tolerance:
> > > +description: Same voltage tollerance of the Krait CPU
> > > +
> > > + l2-rates:
> > > +description: |
> > > + Frequency the L2 cache will be scaled at.
> > > + Value is in Hz.
> > > +$ref: /schemas/types.yaml#/definitions/uint32-array
> > > +items:
> > > + - description: idle
> > > + - description: nominal
> > > + - description: high
> > > +
> >
> > Why can't you re-use the standard OPP v2 bindings ?
> >
>
> Isn't overkill to use the OPP v2 bindings to represent the the microvolt
> related to the le freq? Is the OPP v1 sufficient?
Should be fine if it is allowed. v2 came out in the flow of my thought
and was not intentional.
> Also I can't find a way to reflect this specific case where the l2 rates
> are changed based on the cpu freq value? Any idea about that?
>
OK, I am always opposed to giving such independent controls in the kernel
as one can play around say max cpu freq and lowest cache or vice-versa
and create instabilities. IMO this should be completely hidden from OS.
But I know these are old platforms, so I will shut my mouth ;)
--
Regards,
Sudeep
R: [RFC PATCH v2 2/2] dt-bindings: cpufreq: Document Krait CPU Cache scaling
> -Messaggio originale- > Da: Sudeep Holla > Inviato: lunedì 10 agosto 2020 10:02 > A: Ansuel Smith > Cc: Viresh Kumar ; Rafael J. Wysocki > ; Rob Herring ; linux- > p...@vger.kernel.org; devicet...@vger.kernel.org; linux- > ker...@vger.kernel.org > Oggetto: Re: [RFC PATCH v2 2/2] dt-bindings: cpufreq: Document Krait CPU > Cache scaling > > On Sat, Aug 08, 2020 at 01:49:12AM +0200, Ansuel Smith wrote: > > Document dedicated Krait CPU Cache Scaling driver. > > > > Signed-off-by: Ansuel Smith > > --- > > .../bindings/cpufreq/krait-cache-scale.yaml | 92 > +++ > > 1 file changed, 92 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/cpufreq/krait- > cache-scale.yaml > > > > diff --git a/Documentation/devicetree/bindings/cpufreq/krait-cache- > scale.yaml b/Documentation/devicetree/bindings/cpufreq/krait-cache- > scale.yaml > > new file mode 100644 > > index ..f10b1f386a99 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/cpufreq/krait-cache- > scale.yaml > > @@ -0,0 +1,92 @@ > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/cpufreq/krait-cache-scale.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Krait Cpu Cache Frequency Scaling dedicated driver > > + > > +maintainers: > > + - Ansuel Smith > > + > > +description: | > > + This Scale the Krait CPU Cache Frequency and optionally voltage > > + when the Cpu Frequency is changed (using the cpufreq notifier). > > + > > + Cache is scaled with the max frequency across all core and the cache > > + frequency will scale based on the configured threshold in the dts. > > + > > + The cache is hardcoded to 3 frequency bin, idle, nominal and high. > > + > > +properties: > > + compatible: > > +const: qcom,krait-cache > > + > > How does this fit in the standard cache hierarchy nodes ? Extend the > example to cover that. > I think i didn't understand this question. You mean that I should put in the example how the standard l2 cache nodes are defined? > > + clocks: > > +description: Phandle to the L2 CPU clock > > + > > + clock-names: > > +const: "l2" > > + > > + voltage-tolerance: > > +description: Same voltage tollerance of the Krait CPU > > + > > + l2-rates: > > +description: | > > + Frequency the L2 cache will be scaled at. > > + Value is in Hz. > > +$ref: /schemas/types.yaml#/definitions/uint32-array > > +items: > > + - description: idle > > + - description: nominal > > + - description: high > > + > > Why can't you re-use the standard OPP v2 bindings ? > Isn't overkill to use the OPP v2 bindings to represent the the microvolt related to the le freq? Is the OPP v1 sufficient? Also I can't find a way to reflect this specific case where the l2 rates are changed based on the cpu freq value? Any idea about that? > -- > Regards, > Sudeep
Re: [RFC PATCH v2 2/2] dt-bindings: cpufreq: Document Krait CPU Cache scaling
On Sat, Aug 08, 2020 at 01:49:12AM +0200, Ansuel Smith wrote: > Document dedicated Krait CPU Cache Scaling driver. > > Signed-off-by: Ansuel Smith > --- > .../bindings/cpufreq/krait-cache-scale.yaml | 92 +++ > 1 file changed, 92 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml > > diff --git a/Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml > b/Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml > new file mode 100644 > index ..f10b1f386a99 > --- /dev/null > +++ b/Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml > @@ -0,0 +1,92 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/cpufreq/krait-cache-scale.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Krait Cpu Cache Frequency Scaling dedicated driver > + > +maintainers: > + - Ansuel Smith > + > +description: | > + This Scale the Krait CPU Cache Frequency and optionally voltage > + when the Cpu Frequency is changed (using the cpufreq notifier). > + > + Cache is scaled with the max frequency across all core and the cache > + frequency will scale based on the configured threshold in the dts. > + > + The cache is hardcoded to 3 frequency bin, idle, nominal and high. > + > +properties: > + compatible: > +const: qcom,krait-cache > + How does this fit in the standard cache hierarchy nodes ? Extend the example to cover that. > + clocks: > +description: Phandle to the L2 CPU clock > + > + clock-names: > +const: "l2" > + > + voltage-tolerance: > +description: Same voltage tollerance of the Krait CPU > + > + l2-rates: > +description: | > + Frequency the L2 cache will be scaled at. > + Value is in Hz. > +$ref: /schemas/types.yaml#/definitions/uint32-array > +items: > + - description: idle > + - description: nominal > + - description: high > + Why can't you re-use the standard OPP v2 bindings ? -- Regards, Sudeep
[RFC PATCH v2 2/2] dt-bindings: cpufreq: Document Krait CPU Cache scaling
Document dedicated Krait CPU Cache Scaling driver.
Signed-off-by: Ansuel Smith
---
.../bindings/cpufreq/krait-cache-scale.yaml | 92 +++
1 file changed, 92 insertions(+)
create mode 100644
Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml
diff --git a/Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml
b/Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml
new file mode 100644
index ..f10b1f386a99
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/krait-cache-scale.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cpufreq/krait-cache-scale.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Krait Cpu Cache Frequency Scaling dedicated driver
+
+maintainers:
+ - Ansuel Smith
+
+description: |
+ This Scale the Krait CPU Cache Frequency and optionally voltage
+ when the Cpu Frequency is changed (using the cpufreq notifier).
+
+ Cache is scaled with the max frequency across all core and the cache
+ frequency will scale based on the configured threshold in the dts.
+
+ The cache is hardcoded to 3 frequency bin, idle, nominal and high.
+
+properties:
+ compatible:
+const: qcom,krait-cache
+
+ clocks:
+description: Phandle to the L2 CPU clock
+
+ clock-names:
+const: "l2"
+
+ voltage-tolerance:
+description: Same voltage tollerance of the Krait CPU
+
+ l2-rates:
+description: |
+ Frequency the L2 cache will be scaled at.
+ Value is in Hz.
+$ref: /schemas/types.yaml#/definitions/uint32-array
+items:
+ - description: idle
+ - description: nominal
+ - description: high
+
+ l2-cpufreq:
+description: |
+ Threshold used by the driver to scale the L2 cache.
+ If the max CPU Frequency is more than the set frequency,
+ the driver will transition to the next frequency bin.
+ Value is in kHz
+$ref: /schemas/types.yaml#/definitions/uint32-array
+items:
+ - description: idle
+ - description: nominal
+ - description: high
+
+ l2-volt:
+description: |
+ Threshold used by the driver to scale the L2 cache.
+ If the max CPU Frequency is more than the set frequency,
+ the driver will transition to the next frequency bin.
+ Value is in microvolt.
+$ref: /schemas/types.yaml#/definitions/uint32-array
+items:
+ - description: idle
+ - description: nominal
+ - description: high
+
+ l2-supply:
+description: Phandle to the L2 regulator supply.
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - voltage-tolerance
+ - l2-rates
+ - l2-cpufreq
+ - l2-supply
+ - l2-volt
+
+examples:
+ - |
+qcom-krait-cache {
+ compatible = "qcom,krait-cache";
+ clocks = < 4>;
+ clock-names = "l2";
+ voltage-tolerance = <5>;
+ l2-rates = <38400 10 12>;
+ l2-cpufreq = <384000 60 120>;
+ l2-volt = <110 110 115>;
+ l2-supply = <_s1a>;
+};
--
2.27.0
