On Sat, Aug 5, 2023 at 12:38 PM Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: > > 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@xxxxxxxxxx> > > Signed-off-by: Saravana Kannan <saravanak@xxxxxxxxxx> > > Signed-off-by: David Dai <davidai@xxxxxxxxxx> > > --- > > .../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@xxxxxxxxxx> > > + - Saravana Kannan <saravanak@xxxxxxxxxx> > > + > > +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... Why do you say this? This patch series was obviously tested very well with all the data we collected. -Saravana
