Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v5.16 2021-12-01T19:02:11+00:00 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 2021-08-12T04:24:07+00:00 Viresh Kumar viresh.kumar@linaro.org 2021-08-10T06:34:33+00:00 urn:sha1:c17495b01b72b53bd290f442d39b060e015c7aea Many cpufreq drivers register with the energy model for each policy and do exactly the same thing. Follow the footsteps of thermal-cooling, to get it done from the cpufreq core itself. Provide a new callback, which will be called, if present, by the cpufreq core at the right moment (more on that in the code's comment). Also provide a generic implementation that uses dev_pm_opp_of_register_em(). This also allows us to register with the EM at a later point of time, compared to ->init(), from where the EM core can access cpufreq policy directly using cpufreq_cpu_get() type of helpers and perform other work, like marking few frequencies inefficient, this will be done separately. Reviewed-by: Quentin Perret <qperret@google.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> 2021-08-04T18:16:32+00:00 Sebastian Andrzej Siewior bigeasy@linutronix.de 2021-08-03T14:16:11+00:00 urn:sha1:09681a0772f773dddffd3c2d1796c87bd0d903b9 The functions get_online_cpus() and put_online_cpus() have been deprecated during the CPU hotplug rework. They map directly to cpus_read_lock() and cpus_read_unlock(). Replace deprecated CPU-hotplug functions with the official version. The behavior remains unchanged. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2021-06-30T17:45:42+00:00 Viresh Kumar viresh.kumar@linaro.org 2021-06-29T06:27:08+00:00 urn:sha1:b3beca76181681fce9cf72f37d19c3030e3353c0 Commit e3c062360870 ("cpufreq: add cpufreq_driver_resolve_freq()") introduced this callback, back in 2016, for drivers that provide the ->target() callback. The kernel hasn't seen a single user of it in the past 5 years and it is not likely to be used any time soon. Remove it for now. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>