[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH 04/31] cpufreq: make turbo settings to be configurable
On Mon, Dec 4, 2017 at 1:58 PM, Andre Przywara <andre.przywara@xxxxxxx> wrote: > Hi, Hi Andre > > .... > >> And the most important question is how to recognize in Xen on ARM >> (using SCPI protocol) which frequencies are turbo-frequencies >> actually? I couldn't find any information regarding that in protocol >> description. > > So traditionally on ARM there is no notion of a "turbo" frequency. The > idea is to expose the highest possible frequency, and let thermal > throttling (possibly in hardware or in firmware) limit the frequency if > the thermal budget is busted. > Also in the ARM world it is expected that an OS has much better > knowledge on how to handle frequencies, for instance when to give more > power to the GPU and when to the CPU. > >> For DT-based CPUFreq it is not an issue, since there is a specific >> property "turbo-mode" to mark corresponding OPPs. [1]. >> But neither SCPI DT bindings [2] nor the SCPI protocol itself [3] >> mentions about it. Perhaps, additional command should be added to pass >> such info. > > The DT binding you mentioned in Linux is a generic one. > In general DT only describes non-discoverable properties. But for SCPI > the OPPs are handled in the SCP and advertised via SCPI calls (3.2.9 Get > DVFS Info, command 0x9). > So the OPP table is not in the DT, and thus you don't have any way of > detecting turbo frequencies. > But as mentioned before, this is so by design, as ARM does not endorse > the concept of turbo frequencies in general. > > Now with the advent of more "server-y" chips and ACPI, this might change > in the future. For instance SCMI is designed to be closer to ACPI, so we > might inherit some turbo notion from there. > > So we should not completely rule out the idea of turbo, but for a start > we can somewhat assume that an ARM based system does not have turbo per se. Thank you for the detailed explanation. I will take a look at SCMI documentation. > > Cheers, > Andre. > >> [1] https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt >> [2] >> http://elixir.free-electrons.com/linux/v4.15-rc1/source/Documentation/devicetree/bindings/arm/arm,scpi.txt >> [3] >> http://infocenter.arm.com/help/topic/com.arm.doc.dui0922g/scp_message_interface_v1_2_DUI0922G_en.pdf >> >>> >>> >>>> diff --git a/xen/drivers/pm/stat.c b/xen/drivers/pm/stat.c >>>> index 2dbde1c..133e64d 100644 >>>> --- a/xen/drivers/pm/stat.c >>>> +++ b/xen/drivers/pm/stat.c >>>> @@ -290,7 +290,11 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op >>>> *op) >>>> &op->u.get_para.u.ondemand.sampling_rate, >>>> &op->u.get_para.u.ondemand.up_threshold); >>>> } >>>> +#ifdef CONFIG_HAS_CPU_TURBO >>>> op->u.get_para.turbo_enabled = cpufreq_get_turbo_status(op->cpuid); >>>> +#else >>>> + op->u.get_para.turbo_enabled = 0; >>>> +#endif >>>> >>>> return ret; >>>> } >>>> @@ -473,6 +477,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op) >>>> break; >>>> } >>>> >>>> +#ifdef CONFIG_HAS_CPU_TURBO >>>> case XEN_SYSCTL_pm_op_enable_turbo: >>>> { >>>> ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_ENABLED); >>>> @@ -484,6 +489,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op) >>>> ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_DISABLED); >>>> break; >>>> } >>>> +#endif /* CONFIG_HAS_CPU_TURBO */ >>>> >>>> default: >>>> printk("not defined sub-hypercall @ do_pm_op\n"); >>>> diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h >>>> index 30c70c9..2e0c16a 100644 >>>> --- a/xen/include/xen/cpufreq.h >>>> +++ b/xen/include/xen/cpufreq.h >>>> @@ -39,7 +39,9 @@ extern struct acpi_cpufreq_data >>>> *cpufreq_drv_data[NR_CPUS]; >>>> >>>> struct cpufreq_cpuinfo { >>>> unsigned int max_freq; >>>> +#ifdef CONFIG_HAS_CPU_TURBO >>>> unsigned int second_max_freq; /* P1 if Turbo Mode is on */ >>>> +#endif >>>> unsigned int min_freq; >>>> unsigned int transition_latency; /* in 10^(-9) s = nanoseconds >>>> */ >>>> }; >>>> @@ -72,9 +74,11 @@ struct cpufreq_policy { >>>> >>>> bool_t resume; /* flag for cpufreq 1st run >>>> * S3 wakeup, hotplug cpu, etc */ >>>> +#ifdef CONFIG_HAS_CPU_TURBO >>>> s8 turbo; /* tristate flag: 0 for unsupported >>>> * -1 for disable, 1 for enabled >>>> * See CPUFREQ_TURBO_* below for defines >>>> */ >>>> +#endif >>>> bool_t aperf_mperf; /* CPU has APERF/MPERF MSRs */ >>>> }; >>>> DECLARE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_policy); >>>> @@ -138,8 +142,10 @@ extern int cpufreq_driver_getavg(unsigned int cpu, >>>> unsigned int flag); >>>> #define CPUFREQ_TURBO_UNSUPPORTED 0 >>>> #define CPUFREQ_TURBO_ENABLED 1 >>>> >>>> +#ifdef CONFIG_HAS_CPU_TURBO >>>> extern int cpufreq_update_turbo(int cpuid, int new_state); >>>> extern int cpufreq_get_turbo_status(int cpuid); >>>> +#endif >>>> >>>> static __inline__ int >>>> __cpufreq_governor(struct cpufreq_policy *policy, unsigned int event) >> >> >> -- Regards, Oleksandr Tyshchenko _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |