Messages in this thread | | | Date | Sat, 5 Aug 2023 21:38:34 +0200 | Subject | Re: [PATCH v3 1/2] dt-bindings: cpufreq: add bindings for virtual cpufreq | From | Krzysztof Kozlowski <> |
| |
On 31/07/2023 19:46, David Dai wrote: > Adding bindings to represent a virtual cpufreq device. > > Virtual machines may expose MMIO regions for a virtual cpufreq device for > guests to read frequency information or to request frequency selection. The > virtual cpufreq device has an individual controller for each CPU.
A nit, subject: drop second/last, redundant "bindings for". The "dt-bindings" prefix is already stating that these are bindings.
> > Co-developed-by: Saravana Kannan <saravanak@google.com> > Signed-off-by: Saravana Kannan <saravanak@google.com> > Signed-off-by: David Dai <davidai@google.com> > --- > .../bindings/cpufreq/cpufreq-virtual.yaml | 89 +++++++++++++++++++ > 1 file changed, 89 insertions(+) > create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-virtual.yaml > > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-virtual.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-virtual.yaml > new file mode 100644 > index 000000000000..f377cfc972ca > --- /dev/null > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-virtual.yaml > @@ -0,0 +1,89 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/cpufreq/cpufreq-virtual.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yamll# > + > +title: Virtual CPUFreq > + > +maintainers: > + - David Dai <davidai@google.com> > + - Saravana Kannan <saravanak@google.com> > + > +description: > + Virtual CPUFreq is a virtualized driver in guest kernels that sends frequency > + selection of its vCPUs as a hint to the host through MMIO regions. The host > + uses the hint to schedule vCPU threads and select physical CPU frequency. It > + enables accurate Per-Entity Load Tracking for tasks running in the guest by > + querying host CPU frequency unless a virtualized FIE (ex. AMU) exists.
Why do you need DT for this? You control hypervisor, thus control the interface to the guest. I think Rob made it pretty clear that discoverable usecases (which is yours) are not for DT.
Incomplete style-review follows:
> + > +properties: > + compatible: > + const: virtual,cpufreq
Missing blank line.
> + reg: > + maxItems: 1 > + > +required: > + - compatible > + - reg > + > +additionalProperties: false > + > +examples: > + - | > + cpus { > + #address-cells = <1>; > + #size-cells = <0>; > + > + cpu@0 { > + compatible = "arm,arm-v8"; > + device_type = "cpu"; > + reg = <0x0>; > + operating-points-v2 = <&opp_table0>; > + }; > + > + cpu@1 { > + compatible = "arm,arm-v8"; > + device_type = "cpu"; > + reg = <0x0>; > + operating-points-v2 = <&opp_table1>; > + }; > + }; > + > + opp_table0: opp-table-0 { > + compatible = "operating-points-v2"; > + > + opp1098000000 { > + opp-hz = /bits/ 64 <1098000000>; > + opp-level = <1>; > + }; > + > + opp1197000000 { > + opp-hz = /bits/ 64 <1197000000>; > + opp-level = <2>; > + }; > + }; > + > + opp_table1: opp-table-1 { > + compatible = "operating-points-v2"; > + > + opp1106000000 { > + opp-hz = /bits/ 64 <1106000000>; > + opp-level = <1>; > + }; > + > + opp1277000000 { > + opp-hz = /bits/ 64 <1277000000>; > + opp-level = <2>; > + }; > + }; > + > + soc { > + #address-cells = <1>; > + #size-cells = <1>; > + > + cpufreq {
Missing unit address
> + reg = <0x1040000 0x10>; > + compatible = "virtual,cpufreq";
compatible is always the first property.
Also, you did not test it...
Best regards, Krzysztof
| |