On Fri, Nov 10, 2023 at 05:49:29PM -0800, 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 frequency domain. > > Co-developed-by: Saravana Kannan <saravanak@xxxxxxxxxx> > Signed-off-by: Saravana Kannan <saravanak@xxxxxxxxxx> > Signed-off-by: David Dai <davidai@xxxxxxxxxx> > --- > .../cpufreq/qemu,cpufreq-virtual.yaml | 99 +++++++++++++++++++ > 1 file changed, 99 insertions(+) > create mode 100644 Documentation/devicetree/bindings/cpufreq/qemu,cpufreq-virtual.yaml > > diff --git a/Documentation/devicetree/bindings/cpufreq/qemu,cpufreq-virtual.yaml b/Documentation/devicetree/bindings/cpufreq/qemu,cpufreq-virtual.yaml > new file mode 100644 > index 000000000000..16606cf1fd1a > --- /dev/null > +++ b/Documentation/devicetree/bindings/cpufreq/qemu,cpufreq-virtual.yaml > @@ -0,0 +1,99 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/cpufreq/qemu,cpufreq-virtual.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +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. Each vCPU > + is associated with a frequency domain which can be shared with other vCPUs. > + Each frequency domain has its own set of registers for frequency controls. > + Are these register controls described somewhere ? The reason I ask is we should be able to have single implementation of this virtual cpufreq irrespective of the firmware used(DT vs ACPI) IMO. > +properties: > + compatible: > + const: qemu,virtual-cpufreq > + > + reg: > + maxItems: 1 > + description: > + Address and size of region containing frequency controls for each of the > + frequency domains. Regions for each frequency domain is placed > + contiugously and contain registers for controlling DVFS(Dynamic Frequency > + and Voltage) characteristics. The size of the region is proportional to > + total number of frequency domains. > + > +required: > + - compatible > + - reg > + > +additionalProperties: false > + > +examples: > + - | > + // This example shows a two CPU configuration with a frequency domain > + // for each CPU. > + cpus { > + #address-cells = <1>; > + #size-cells = <0>; > + > + cpu@0 { > + compatible = "arm,armv8"; > + device_type = "cpu"; > + reg = <0x0>; > + operating-points-v2 = <&opp_table0>; > + }; > + > + cpu@1 { > + compatible = "arm,armv8"; > + device_type = "cpu"; > + reg = <0x0>; > + operating-points-v2 = <&opp_table1>; > + }; > + }; > + > + opp_table0: opp-table-0 { > + compatible = "operating-points-v2"; > + opp-shared; > + > + 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"; > + opp-shared; > + > + opp1106000000 { > + opp-hz = /bits/ 64 <1106000000>; > + opp-level = <1>; > + }; > + > + opp1277000000 { > + opp-hz = /bits/ 64 <1277000000>; > + opp-level = <2>; > + }; > + }; > I think using OPP with absolute frequencies seems not appropriate here. Why can't these fetched from the registers and have some abstract values instead ? > + soc { > + #address-cells = <1>; > + #size-cells = <1>; > + > + cpufreq@1040000 { > + compatible = "qemu,virtual-cpufreq"; > + reg = <0x1040000 0x10>; So just 16bytes for 2 CPU system ? How does the register layout look like ? I assume just 4 x 32bit registers: 2 for reading and 2 for setting the frequencies ? -- Regards, Sudeep
