Linux Kernel https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.11.9 2020-12-22T22:12:10Z 2020-12-22T22:12:10Z Linus Torvalds torvalds@linux-foundation.org 2020-12-22T22:12:10Z urn:sha1:4960821a4d80781fd3e63cd71fb1b38c2dadb915 Pull more power management updates from Rafael Wysocki: "These update the CPPC cpufreq driver and intel_pstate (which involves updating the cpufreq core and the schedutil governor) and make janitorial changes in the ACPI code handling processor objects. Specifics: - Rework the passive-mode "fast switch" path in the intel_pstate driver to allow it receive the minimum (required) and target (desired) performance information from the schedutil governor so as to avoid running some workloads too fast (Rafael Wysocki). - Make the intel_pstate driver allow the policy max limit to be increased after the guaranteed performance value for the given CPU has increased (Rafael Wysocki). - Clean up the handling of CPU coordination types in the CPPC cpufreq driver and make it export frequency domains information to user space via sysfs (Ionela Voinescu). - Fix the ACPI code handling processor objects to use a correct coordination type when it fails to map frequency domains and drop a redundant CPU map initialization from it (Ionela Voinescu, Punit Agrawal)" * tag 'pm-5.11-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: intel_pstate: Use most recent guaranteed performance values cpufreq: intel_pstate: Implement the ->adjust_perf() callback cpufreq: Add special-purpose fast-switching callback for drivers cpufreq: schedutil: Add util to struct sg_cpu cppc_cpufreq: replace per-cpu data array with a list cppc_cpufreq: expose information on frequency domains cppc_cpufreq: clarify support for coordination types cppc_cpufreq: use policy->cpu as driver of frequency setting ACPI: processor: fix NONE coordination for domain mapping failure 2020-12-15T18:11:24Z Ionela Voinescu ionela.voinescu@arm.com 2020-12-14T12:07:40Z urn:sha1:bca3e43c903f5c58daeab1fea0af566233ea003c For errors parsing the _PSD domains, a separate domain is returned for each CPU in the failed _PSD domain with no coordination (as per previous comment). But contrary to the intention, the code was setting CPUFREQ_SHARED_TYPE_ALL as coordination type. Change shared_type to CPUFREQ_SHARED_TYPE_NONE in case of errors parsing the domain information. The function still returns the error and the caller is free to bail out the domain initialisation altogether in that case. Given that both functions return domains with a single CPU, this change does not affect the functionality, but clarifies the intention. Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Subject edit ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2020-12-15T14:33:18Z Rafael J. Wysocki rafael.j.wysocki@intel.com 2020-12-15T14:33:18Z urn:sha1:25fe64232ee5bdd328c1c4ae24e8fd2b88251834 * acpi-apei: ACPI, APEI: make apei_resources_all static * acpi-misc: ACPI: acpi_drivers.h: Update the kernel doc ACPI: acpi_drivers.h: Remove the leftover dead code ACPI: tiny-power-button: Simplify the code using module_acpi_driver() ACPI: SBS: Simplify the code using module_acpi_driver() ACPI: SBS: Simplify the driver init code ACPI: debug: Remove the not used function ACPI: processor: Remove the duplicated ACPI_PROCESSOR_CLASS macro * acpi-processor: ACPI: processor: Drop duplicate setting of shared_cpu_map 2020-11-25T15:44:36Z Punit Agrawal punitagrawal@gmail.com 2020-11-23T23:59:51Z urn:sha1:55130fb22a1c396139c3da46f939bf5a6a92095e 'shared_cpu_map', stored as part of the per-processor acpi_processor_performance structre, is used to store CPUs that share a performance domain. By definition it contains the owning CPU. While building the 'shared_cpu_map' it is being set twice - once while initialising the performance domains and again when matching CPUs belonging to the same domain. Drop the unnecessary initialisation. Signed-off-by: Punit Agrawal <punitagrawal@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2020-11-17T17:12:34Z Hanjun Guo guohanjun@huawei.com 2020-11-13T02:08:44Z urn:sha1:eb37ba316fdec9c6af36b8b155732568c5b2a2d4 The ACPI_PROCESSOR_CLASS macro is defined in <acpi/processor.h>, and ACPI drivers for processor already included <acpi/processor.h>, so we can remove those duplicated ACPI_PROCESSOR_CLASS macros. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2020-11-09T18:08:06Z Maximilian Luz luzmaximilian@gmail.com 2020-11-05T02:06:00Z urn:sha1:c6237b210ddc4f026a368172e957cbd3d5b5c78a Replaces spaces with tabs where spaces have been (inconsistently) used for indentation and removes trailing whitespaces. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2019-10-25T09:33:48Z Rafael J. Wysocki rafael.j.wysocki@intel.com 2019-10-25T00:41:40Z urn:sha1:a1bb46c36ce389d4a24a42e5b6047b0626caa3ea The _PPC change notifications from the platform firmware are per-CPU, so acpi_processor_ppc_init() needs to add a frequency QoS request for each CPU covered by a cpufreq policy to take all of them into account. Even though ACPI thermal control of CPUs sets frequency limits per processor package, it also needs a frequency QoS request for each CPU in a cpufreq policy in case some of them are taken offline and the frequency limit needs to be set through the remaining online ones (this is slightly excessive, because all CPUs covered by one cpufreq policy will set the same frequency limit through their QoS requests, but it is not incorrect). Modify the code in accordance with the above observations. Fixes: d15ce412737a ("ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> 2019-10-21T00:05:21Z Rafael J. Wysocki rafael.j.wysocki@intel.com 2019-10-16T10:47:06Z urn:sha1:3000ce3c52f8b8db093e4dc649cd172390f71137 Replace the CPU device PM QoS used for the management of min and max frequency constraints in cpufreq (and its users) with per-policy frequency QoS to avoid problems with cpufreq policies covering more then one CPU. Namely, a cpufreq driver is registered with the subsys interface which calls cpufreq_add_dev() for each CPU, starting from CPU0, so currently the PM QoS notifiers are added to the first CPU in the policy (i.e. CPU0 in the majority of cases). In turn, when the cpufreq driver is unregistered, the subsys interface doing that calls cpufreq_remove_dev() for each CPU, starting from CPU0, and the PM QoS notifiers are only removed when cpufreq_remove_dev() is called for the last CPU in the policy, say CPUx, which as a rule is not CPU0 if the policy covers more than one CPU. Then, the PM QoS notifiers cannot be removed, because CPUx does not have them, and they are still there in the device PM QoS notifiers list of CPU0, which prevents new PM QoS notifiers from being registered for CPU0 on the next attempt to register the cpufreq driver. The same issue occurs when the first CPU in the policy goes offline before unregistering the driver. After this change it does not matter which CPU is the policy CPU at the driver registration time and whether or not it is online all the time, because the frequency QoS is per policy and not per CPU. Fixes: 67d874c3b2c6 ("cpufreq: Register notifiers with the PM QoS framework") Reported-by: Dmitry Osipenko <digetx@gmail.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Reported-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Diagnosed-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/linux-pm/5ad2624194baa2f53acc1f1e627eb7684c577a19.1562210705.git.viresh.kumar@linaro.org/T/#md2d89e95906b8c91c15f582146173dce2e86e99f Link: https://lore.kernel.org/linux-pm/20191017094612.6tbkwoq4harsjcqv@vireshk-i7/T/#m30d48cc23b9a80467fbaa16e30f90b3828a5a29b Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> 2019-10-16T11:02:45Z Rafael J. Wysocki rafael.j.wysocki@intel.com 2019-10-15T17:35:20Z urn:sha1:2d8b39a62a5d386a73f339e46fe05354a3a4895b If there are neither processor objects nor processor device objects in the ACPI tables, the per-CPU processors table will not be initialized and attempting to dereference pointers from there will cause the kernel to crash. This happens in acpi_processor_ppc_init() and acpi_thermal_cpufreq_init() after commit d15ce412737a ("ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier") which didn't add the requisite NULL pointer checks in there. Add the NULL pointer checks to acpi_processor_ppc_init() and acpi_thermal_cpufreq_init(), and to the corresponding "exit" routines. While at it, drop redundant return instructions from acpi_processor_ppc_init() and acpi_thermal_cpufreq_init(). Fixes: d15ce412737a ("ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier") Reported-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> 2019-08-28T09:21:53Z Viresh Kumar viresh.kumar@linaro.org 2019-08-28T08:50:13Z urn:sha1:d15ce412737accaba5e4c7d653b184772da47365 The cpufreq core now takes the min/max frequency constraints via QoS requests and the CPUFREQ_ADJUST notifier shall get removed later on. Switch over to using the QoS request for maximum frequency constraint for acpi driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>