- Nov 24, 2022
-
-
The cpufreq cooling devices have been removed by 52e3b2ca ("arm64: dts: qcom: sdm845: Remove cpufreq cooling devices for CPU thermal zones") but the per-CPU thermal zones remain. Per monitor_thermal_zone(), we get one polling workqueue per TZ, which is a lot of noise considering the only time those thermal zones will affect the system will be upon crossing a critical trip point. Remove the per-CPU thermal zones and let the cluster-wide ones handle critical temperature trip points. Signed-off-by:
Valentin Schneider <valentin.schneider@arm.com>
-
This is a temporary hack. Currently trace points for PELT are only triggered when the PELT metrics consumed by the scheduler are actually updated, i.e. util_avg. This means no updates if no 1 ms boundary is being crossed by the update. When reconstructing the PELT signal based on this data, the peak PELT value can therefore be up to 1 ms worth of PELT accumulation off (23 in absolute terms). This leads to a discrepancy that causes test cases to fail. This patch ensures that trace events are always emitted even if the metrics haven't been updated which should allow accurate reconstruction of the PELT signals.
-
Signed-off-by:Ionela Voinescu <ionela.voinescu@arm.com>
-
arm and arm64: Add Debug per_cpu maps access Add Prove Locking Add Scheduler statistics arm: Add kernel .config support and /proc/config.gz arm64: Add Scheduler debugging Add Ftrace Signed-off-by:
Dietmar Eggemann <dietmar.eggemann@arm.com> -
arm and arm64: Add Cgroups (+ FAIR_GROUP_SCHED and FREEZER) Add Uclamp support for tasks and taskgroups Add CpuFreq governors and make schedutil default arm: Add Cpuset support Add Scheduler autogroups Add DIE (SCHED_MC) sched domain level Add Energy Model Signed-off-by:Dietmar Eggemann <dietmar.eggemann@arm.com>
Signed-off-by: -
This reverts commit 5d777b18. [ionela.voinescu@arm.com: modify capacity of current CPU only]
-
-
This config is causing instability on Juno boards.
-
For Arm: Add ARM vexpress-spc cpufreq driver Add ARM Big.Little cpuidle driver Add Sensor Vexpress Disable CONFIG_HARDEN_BRANCH_HISTORY
-
-
- Nov 21, 2022
-
-
Deepak Kumar Mishra authored
-
- Nov 18, 2022
-
-
Rafael J. Wysocki authored
* pm-cpufreq: cpufreq: ACPI: Remove unused variables 'acpi_cpufreq_online' and 'ret'
-
Rafael J. Wysocki authored
* acpi-video: ACPI: video: Prefer native over vendor ACPI: video: Simplify __acpi_video_get_backlight_type() ACPI: video: Add force_native quirk for Sony Vaio VPCY11S1E ACPI: video: Add force_vendor quirk for Sony Vaio PCG-FRV35 ACPI: video: Change Sony Vaio VPCEH3U1E quirk to force_native ACPI: video: Change GIGABYTE GB-BXBT-2807 quirk to force_none ACPI: video: Add a few bugtracker links to DMI quirks * acpi-misc: ACPI: processor: Silence missing prototype warnings ACPI: PM: Silence missing prototype warning ACPI: FFH: Silence missing prototype warnings ACPI: processor_idle: Silence missing prototype warnings ACPI: APEI: Silence missing prototype warnings arm64: Add architecture specific ACPI FFH Opregion callbacks ACPI: Implement a generic FFH Opregion handler
-
- Nov 16, 2022
-
-
Nathan Chancellor authored
Clang warns: drivers/cpufreq/acpi-cpufreq.c:970:24: error: variable 'ret' is uninitialized when used here [-Werror,-Wuninitialized] acpi_cpufreq_online = ret; ^~~ drivers/cpufreq/acpi-cpufreq.c:960:9: note: initialize the variable 'ret' to silence this warning int ret; ^ = 0 1 error generated. Both ret and acpi_cpufreq_online are now unused so they can be safely removed, clearing up the warning. Fixes: 13fdbc8b ("cpufreq: ACPI: Defer setting boost MSRs") Link: https://github.com/ClangBuiltLinux/linux/issues/1757 Signed-off-by:Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Sudeep Holla authoredSilence the following warnings when built with W=1: | CC drivers/acpi/acpi_processor.c | warning: no previous prototype for 'arch_register_cpu' [-Wmissing-prototypes] | int __weak arch_register_cpu(int cpu) | ^ | CC drivers/acpi/acpi_processor.c | warning: no previous prototype for 'arch_unregister_cpu' [-Wmissing-prototypes] | void __weak arch_unregister_cpu(int cpu) {} | ^ Reported-by:kernel test robot <lkp@intel.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: -
Sudeep Holla authored
Silence the following warning when built with W=1: | CC drivers/acpi/device_pm.c | warning: no previous prototype for function 'acpi_subsys_restore_early' [-Wmissing-prototypes] | int acpi_subsys_restore_early(struct device *dev) | ^ Reported-by:
Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: -
Sudeep Holla authored
Silence the following warnings when built with W=1: | CC drivers/acpi/acpi_ffh.c | warning: no previous prototype for 'acpi_ffh_address_space_arch_setup' [-Wmissing-prototypes] | int __weak acpi_ffh_address_space_arch_setup(void *handler_ctxt, | ^ | CC drivers/acpi/acpi_ffh.c | warning: no previous prototype for 'acpi_ffh_address_space_arch_handler' [-Wmissing-prototypes] | int __weak acpi_ffh_address_space_arch_handler(acpi_integer *value, | ^ Reported-by:
Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: -
Sudeep Holla authored
Silence the following warnings when built with W=1: | CC drivers/acpi/processor_idle.c | warning: no previous prototype for 'acpi_processor_ffh_lpi_probe' [-Wmissing-prototypes] | int __weak acpi_processor_ffh_lpi_probe(unsigned int cpu) | ^ | CC drivers/acpi/processor_idle.c | warning: no previous prototype for 'acpi_processor_ffh_lpi_enter' [-Wmissing-prototypes] | int __weak acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi) | ^ Reported-by:
Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: -
Sudeep Holla authored
Silence the following warnings when make W=1: | CC drivers/acpi/apei/apei-base.c | warning: no previous prototype for 'arch_apei_enable_cmcff' [-Wmissing-prototypes] | int __weak arch_apei_enable_cmcff(struct acpi_hest_header *hest_hdr, | ^ | CC drivers/acpi/apei/apei-base.c | warning: no previous prototype for 'arch_apei_report_mem_error' [-Wmissing-prototypes] | void __weak arch_apei_report_mem_error(int sev, | ^ Reported-by:
Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: -
Rafael J. Wysocki authored
-
Hans de Goede authored
When available prefer native backlight control over vendor backlight control. Testing has shown that there are quite a few laptop models which rely on native backlight control (they don't have ACPI video bus backlight control) and on which acpi_osi_is_win8() returns false. Currently __acpi_video_get_backlight_type() returns vendor on these laptops, leading to an empty /sys/class/backlight. As a workaround for this acpi_video_backlight_use_native() has been temporarily changed to always return true. This re-introduces the problem of having multiple backlight devices under /sys/class/backlight for a single panel. Change __acpi_video_get_backlight_type() to prefer native over vendor when available. So that it returns native on these models. And change acpi_video_backlight_use_native() back to only return true when __acpi_video_get_backlight_type() returns native. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
Simplify __acpi_video_get_backlight_type() removing a nested if which makes the flow harder to follow. This also results in having only 1 exit point with return acpi_backlight_native instead of 2. Note this drops the (video_caps & ACPI_VIDEO_BACKLIGHT) check from the if (acpi_osi_is_win8() && native_available) return native path. Windows 8's hardware certification requirements include that there must be ACPI video bus backlight control, so the ACPI_VIDEO_BACKLIGHT check is redundant. Signed-off-by:
-
Hans de Goede authored
The Sony Vaio VPCY11S1E advertises both native and ACPI video backlight control interfaces, but only the native interface works and the default heuristics end up picking ACPI video on this model. Add a video_detect_force_native DMI quirk for this. Reported-by:
Stefan Joosten <stefan@atcomputing.nl> Signed-off-by:
-
Hans de Goede authored
The Sony Vaio PCG-FRV35 advertises both native and vendor backlight control interfaces. With the upcoming changes to prefer native over vendor acpi_video_get_backlight_type() will start returning native on these laptops. But the native radeon_bl0 interface does not work, where as the sony vendor interface does work. Add a quirk to force use of the vendor interface. Signed-off-by:
-
Hans de Goede authored
According to: https://bugzilla.kernel.org/show_bug.cgi?id=202401 the Sony Vaio VPCEH3U1E quirk was added to disable the acpi_video0 backlight interface because that was not working, so that userspace will pick the actually working native nv_backlight interface instead. With the new kernel behavior of hiding native interfaces unless acpi_video_get_backlight_type() returns native, the current video_detect_force_vendor quirk will cause the working nv_backlight interface will be disabled too. Change the quirk to video_detect_force_native to get the desired result of only registering the nv_backlight interface. After this all currently remaining force_vendor quirks in video_detect_dmi_table[] are there to prefer a vendor interface over a non working ACPI video interface, add a comment to document this. Signed-off-by:
-
Hans de Goede authored
The GIGABYTE GB-BXBT-2807 DMI quirk was added by commit 25417185 ("ACPI: video: Add DMI quirk for GIGABYTE GB-BXBT-2807") which says the following in its commit message: "The GIGABYTE GB-BXBT-2807 is a mini-PC which uses off the shelf components, like an Intel GPU which is meant for mobile systems. As such, it, by default, has a backlight controller exposed. Unfortunately, the backlight controller only confuses userspace, which sees the existence of a backlight device node and has the unrealistic belief that there is actually a backlight there! Add a DMI quirk to force the backlight off on this system." So in essence this quirk was using a video_detect_force_vendor quirk to disable backlight control. Now a days we have a specific "none" backlight type for this. Change the quirk to video_detect_force_none and group it together with the other force_none quirks. Signed-off-by:
-
Hans de Goede authored
Add a couple of missing bugtracker links to DMI quirks Signed-off-by:
-
Rafael J. Wysocki authored
* thermal-core: thermal/core: Protect thermal device operations against thermal device removal thermal/core: Remove thermal_zone_set_trips() thermal/core: Protect sysfs accesses to thermal operations with thermal zone mutex thermal/core: Protect hwmon accesses to thermal operations with thermal zone mutex thermal/core: Introduce locked version of thermal_zone_device_update thermal/core: Move parameter validation from __thermal_zone_get_temp to thermal_zone_get_temp thermal/core: Ensure that thermal device is registered in thermal_zone_get_temp thermal/core: Delete device under thermal device zone lock thermal/core: Destroy thermal zone device mutex in release function
-
Tianchen Ding authored
We found a long tail latency in schbench whem m*t is close to nr_cpus. (e.g., "schbench -m 2 -t 16" on a machine with 32 cpus.) This is because when the wakee cpu is idle, rq->ttwu_pending is cleared too early, and idle_cpu() will return true until the wakee task enqueued. This will mislead the waker when selecting idle cpu, and wake multiple worker threads on the same wakee cpu. This situation is enlarged by commit f3dd3f67 ("sched: Remove the limitation of WF_ON_CPU on wakelist if wakee cpu is idle") because it tends to use wakelist. Here is the result of "schbench -m 2 -t 16" on a VM with 32vcpu (Intel(R) Xeon(R) Platinum 8369B). Latency percentiles (usec): base base+revert_f3dd3f674555 base+this_patch 50.0000th: 9 13 9 75.0000th: 12 19 12 90.0000th: 15 22 15 95.0000th: 18 24 17 *99.0000th: 27 31 24 99.5000th: 3364 33 27 99.9000th: 12560 36 30 We also tested on unixbench and hackbench, and saw no performance change. Signed-off-by:
Tianchen Ding <dtcccc@linux.alibaba.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
Mel Gorman <mgorman@suse.de> Link: https://lkml.kernel.org/r/20221104023601.12844-1-dtcccc@linux.alibaba.com
-
- Nov 14, 2022
-
-
Sudeep Holla authored
FFH Operation Region space can be used to trigger SMC or HVC calls, using the Arm SMC Calling Convention (SMCCC). The choice of conduit (SMC or HVC) is based on what the kernel choose based on PSCI as with any other users of SMCCC within the kernel. Function identifiers only in the SMCCC SiP Service, OEM Service and FF-A specific call range are allowed in FFH Opregions. Offset can be either 0(32 bit calling convention) or 1(64 bit calling convention). The length must be set with the range applicable based on the value of the offset. Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: -
Sudeep Holla authored
This registers the FFH OpRegion handler before ACPI tables are loaded. The platform support for the same is checked via Platform-Wide OSPM Capabilities(OSC) before registering the OpRegion handler. It relies on the special context data passed to offset and the length. However the interpretation of the values is platform/architecture specific. This generic handler just passed all the information to the platform/architecture specific callback. It also implements the default callbacks which return as not supported. Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: -
Guenter Roeck authored
Thermal device operations may be called after thermal zone device removal. After thermal zone device removal, thermal zone device operations must no longer be called. To prevent such calls from happening, ensure that the thermal device is registered before executing any thermal device operations. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Guenter Roeck authored
Since no callers of thermal_zone_set_trips() are left, remove the function. Document __thermal_zone_set_trips() instead. Explicitly state that the thermal zone lock must be held when calling the function, and that the pointer to the thermal zone must be valid. Signed-off-by:
-
Guenter Roeck authored
Protect access to thermal operations against thermal zone removal by acquiring the thermal zone device mutex. After acquiring the mutex, check if the thermal zone device is registered and abort the operation if not. With this change, we can call __thermal_zone_device_update() instead of thermal_zone_device_update() from trip_point_temp_store() and from emul_temp_store(). Similar, we can call __thermal_zone_set_trips() instead of thermal_zone_set_trips() from trip_point_hyst_store(). Signed-off-by:
-
Guenter Roeck authored
In preparation to protecting access to thermal operations against thermal zone device removal, protect hwmon accesses to thermal zone operations with the thermal zone mutex. After acquiring the mutex, ensure that the thermal zone device is registered before proceeding. Signed-off-by:
-
Guenter Roeck authored
In thermal_zone_device_set_mode(), the thermal zone mutex is released only to be reacquired in the subsequent call to thermal_zone_device_update(). Introduce __thermal_zone_device_update(), which is similar to thermal_zone_device_update() but has to be called with the thermal device mutex held. Call the new function from thermal_zone_device_set_mode() to avoid the extra thermal device mutex release/acquire sequence in that function. With the new function in place, re-implement thermal_zone_device_update() as wrapper around __thermal_zone_device_update() to acquire and release the thermal device mutex. Signed-off-by:
-
Guenter Roeck authored
All callers of __thermal_zone_get_temp() already validated the thermal zone parameters. Move validation to thermal_zone_get_temp() where it is actually needed. Also add kernel documentation for __thermal_zone_get_temp(), listing the requirement that the function must be called with validated parameters and with thermal device mutex held. Signed-off-by:
-
Guenter Roeck authored
Calls to thermal_zone_get_temp() are not protected against thermal zone device removal. As result, it is possible that the thermal zone operations callbacks are no longer valid when thermal_zone_get_temp() is called. This may result in crashes such as BUG: unable to handle page fault for address: ffffffffc04ef420 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 5d60e067 P4D 5d60e067 PUD 5d610067 PMD 110197067 PTE 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 3209 Comm: cat Tainted: G W 5.10.136-19389-g615abc6eb807 #1 02df41ac0b12f3a64f4b34245188d8875bb3bce1 Hardware name: Google Coral/Coral, BIOS Google_Coral.10068.92.0 11/27/2018 RIP: 0010:thermal_zone_get_temp+0x26/0x73 Code: 89 c3 eb d3 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 53 48 85 ff 74 50 48 89 fb 48 81 ff 00 f0 ff ff 77 44 48 8b 83 98 03 00 00 <48> 83 78 10 00 74 36 49 89 f6 4c 8d bb d8 03 00 00 4c 89 ff e8 9f RSP: 0018:ffffb3758138fd38 EFLAGS: 00010287 RAX: ffffffffc04ef410 RBX: ffff98f14d7fb000 RCX: 0000000000000000 RDX: ffff98f17cf90000 RSI: ffffb3758138fd64 RDI: ffff98f14d7fb000 RBP: ffffb3758138fd50 R08: 0000000000001000 R09: ffff98f17cf90000 R10: 0000000000000000 R11: ffffffff8dacad28 R12: 0000000000001000 R13: ffff98f1793a7d80 R14: ffff98f143231708 R15: ffff98f14d7fb018 FS: 00007ec166097800(0000) GS:ffff98f1bbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc04ef420 CR3: 000000010ee9a000 CR4: 00000000003506e0 Call Trace: temp_show+0x31/0x68 dev_attr_show+0x1d/0x4f sysfs_kf_seq_show+0x92/0x107 seq_read_iter+0xf5/0x3f2 vfs_read+0x205/0x379 __x64_sys_read+0x7c/0xe2 do_syscall_64+0x43/0x55 entry_SYSCALL_64_after_hwframe+0x61/0xc6 if a thermal device is removed while accesses to its device attributes are ongoing. The problem is exposed by code in iwl_op_mode_mvm_start(), which registers a thermal zone device only to unregister it shortly afterwards if an unrelated failure is encountered while accessing the hardware. Check if the thermal zone device is registered after acquiring the thermal zone device mutex to ensure this does not happen. The code was tested by triggering the failure in iwl_op_mode_mvm_start() on purpose. Without this patch, the kernel crashes reliably. The crash is no longer observed after applying this and the preceding patches. Signed-off-by:
-
Guenter Roeck authored
Thermal device attributes may still be opened after unregistering the thermal zone and deleting the thermal device. Currently there is no protection against accessing thermal device operations after unregistering a thermal zone. To enable adding such protection, protect the device delete operation with the thermal zone device mutex. This requires splitting the call to device_unregister() into its components, device_del() and put_device(). Only the first call can be executed under mutex protection, since put_device() may result in releasing the thermal zone device memory. Signed-off-by:
-
Guenter Roeck authored
Accesses to thermal zones, and with it the thermal zone device mutex, are still possible after the thermal zone device has been unregistered. For example, thermal_zone_get_temp() can be called from temp_show() in thermal_sysfs.c if the sysfs attribute was opened before the thermal device was unregistered. Move the call to mutex_destroy from thermal_zone_device_unregister() to thermal_release() to ensure that it is only destroyed after it is guaranteed to be no longer accessed. Signed-off-by:
-
