Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v5.18 2022-02-09T07:48:49+00:00 2022-02-09T07:48:49+00:00 Bjorn Andersson bjorn.andersson@linaro.org 2022-01-28T03:25:53+00:00 urn:sha1:4f774c4a65bf3987d1a95c966e884f38c8a942af This effectively revert '4bf8e582119e ("cpufreq: Remove ready() callback")', in order to reintroduce the ready callback. This is needed in order to be able to leave the thermal pressure interrupts in the Qualcomm CPUfreq driver disabled during initialization, so that it doesn't fire while related_cpus are still 0. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> [ Viresh: Added the Chinese translation as well and updated commit msg ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> 2021-12-28T18:13:12+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2021-12-28T13:19:12+00:00 urn:sha1:fe262d5c1fc54fac8703d3d82a14aaad9627a168 There are currently 2 ways to create a set of sysfs files for a kobj_type, through the default_attrs field, and the default_groups field. Move the cpufreq code to use default_groups field which has been the preferred way since aa30f47cf666 ("kobject: Add support for default attribute groups to kobj_type") so that we can soon get rid of the obsolete default_attrs field. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2021-12-17T15:45:53+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2021-12-16T19:32:15+00:00 urn:sha1:521223d8b3ec078f670c7c35a1a04b1b2af07966 The min and max frequency QoS requests in the cpufreq core are initialized to whatever the current min and max frequency values are at the init time, but if any of these values change later (for example, cpuinfo.max_freq is updated by the driver), these initial request values will be limiting the CPU frequency unnecessarily unless they are changed by user space via sysfs. To address this, initialize min_freq_req and max_freq_req to FREQ_QOS_MIN_DEFAULT_VALUE and FREQ_QOS_MAX_DEFAULT_VALUE, respectively, so they don't really limit anything until user space updates them. Reported-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2021-12-01T19:02:11+00:00 Tang Yizhou tangyizhou@huawei.com 2021-12-01T07:40:20+00:00 urn:sha1:1e81d3e06de24aedac5c27df13cfa40d912b221b Make the comment in blocking_notifier_call_chain() easier to understand. Signed-off-by: Tang Yizhou <tangyizhou@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2021-12-01T18:50:56+00:00 Xiongfeng Wang wangxiongfeng2@huawei.com 2021-11-29T08:02:48+00:00 urn:sha1:2c1b5a84669d2477d8fffe9136e86a2cff591729 When I hot added a CPU, I found 'cpufreq' directory was not created below /sys/devices/system/cpu/cpuX/. It is because get_cpu_device() failed in add_cpu_dev_symlink(). cpufreq_add_dev() is the .add_dev callback of a CPU subsys interface. It will be called when the CPU device registered into the system. The call chain is as follows: register_cpu() ->device_register() ->device_add() ->bus_probe_device() ->cpufreq_add_dev() But only after the CPU device has been registered, we can get the CPU device by get_cpu_device(), otherwise it will return NULL. Since we already have the CPU device in cpufreq_add_dev(), pass it to add_cpu_dev_symlink(). I noticed that the 'kobj' of the CPU device has been added into the system before cpufreq_add_dev(). Fixes: 2f0ba790df51 ("cpufreq: Fix creation of symbolic links to policy directories") Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2021-10-05T14:33:05+00:00 Vincent Donnefort vincent.donnefort@arm.com 2021-09-08T14:05:29+00:00 urn:sha1:b894d20e6867f04827c7817fbc155460ff108f6f Let the governors schedutil, conservative and ondemand to work, if possible on efficient frequencies only. Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2021-10-05T14:33:05+00:00 Vincent Donnefort vincent.donnefort@arm.com 2021-09-08T14:05:28+00:00 urn:sha1:1f39fa0dccff71d4788089b5e617229b19166867 This newly introduced flag can be applied by a governor to a CPUFreq relation, when looking for a frequency within the policy table. The resolution would then only walk through efficient frequencies. Even with the flag set, the policy max limit will still be honoured. If no efficient frequencies can be found within the limits of the policy, an inefficient one would be returned. Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2021-10-05T14:33:05+00:00 Vincent Donnefort vincent.donnefort@arm.com 2021-09-08T14:05:26+00:00 urn:sha1:15171769069408789a72f9aa9a52cc931b839b56 When applying the policy min/max limits, the requested frequency is simply clamped to not be out of range. It means, however, if one of the boundaries isn't an available frequency, the frequency resolution can return a value out of those limits, depending on the relation used. e.g. freq{0,1,2} being available frequencies. freq0 policy->min freq1 policy->max freq2 | | | | | 17kHz 18kHz 19kHz 20kHz 21kHz __resolve_freq(21kHz, CPUFREQ_RELATION_L) -> 21kHz (out of bounds) __resolve_freq(17kHz, CPUFREQ_RELATION_H) -> 17kHz (out of bounds) If, during the policy init, we resolve the requested min/max to existing frequencies, we ensure that any CPUFREQ_RELATION_* would resolve to a frequency which is inside the policy min/max range. Making the policy limits rigid helps to introduce the inefficient frequencies support. Resolving an inefficient frequency to an efficient one should not transgress policy->max (which can be set for thermal reason) and having a value we can trust simplify this comparison. Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2021-09-02T16:04:17+00:00 Viresh Kumar viresh.kumar@linaro.org 2021-09-01T09:11:57+00:00 urn:sha1:4bf8e582119ed9767f907abb6dc62ef9dddf10df This isn't used anymore, get rid of it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2021-08-31T12:02:16+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2021-08-31T12:02:16+00:00 urn:sha1:b2a6181e27c325f0e654b8d33e5fb621fc3db52b Pull ARM cpufreq driver changes for v5.15 from Viresh Kumar: "This contains: - Update cpufreq-dt blocklist with more platforms (Bjorn Andersson). - Allow freq changes from any CPU for qcom-hw driver (Taniya Das). - Add DSVS interrupt's support for qcom-hw driver (Thara Gopinath). - A new callback (->register_em()) to register EM at a more convenient point of time." * 'cpufreq/arm/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: qcom-hw: Set dvfs_possible_from_any_cpu cpufreq driver flag cpufreq: blocklist more Qualcomm platforms in cpufreq-dt-platdev cpufreq: qcom-cpufreq-hw: Add dcvs interrupt support cpufreq: scmi: Use .register_em() to register with energy model cpufreq: vexpress: Use .register_em() to register with energy model cpufreq: scpi: Use .register_em() to register with energy model cpufreq: qcom-cpufreq-hw: Use .register_em() to register with energy model cpufreq: omap: Use .register_em() to register with energy model cpufreq: mediatek: Use .register_em() to register with energy model cpufreq: imx6q: Use .register_em() to register with energy model cpufreq: dt: Use .register_em() to register with energy model cpufreq: Add callback to register with energy model cpufreq: vexpress: Set CPUFREQ_IS_COOLING_DEV flag