kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-10 20:48:12 +00:00
Code Issues Releases Packages Activity
linux/drivers/acpi/processor_perflib.c

787 lines
19 KiB
Raw Normal View History

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157 Based on 3 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [graeme] [gregory] [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema] [hk] [hemahk]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1105 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-27 08:55:06 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor_perflib: Cleanup print messages The log messages in processor_perflib.c is not in consistency, we have some printk() calls with PREFIX, but some are not; we use pr_*() functions without prefix. So add pr_fmt() and unify them with pr_*() functions. While at it, fix some obvious coding style issues when going through the functions. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-02 16:54:32 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 17:04:11 +09:00
ACPI: Clean up inclusions of ACPI header files Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h> inclusions and remove some inclusions of those files that aren't necessary. First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h> should not be included directly from any files that are built for CONFIG_ACPI unset, because that generally leads to build warnings about undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set, <linux/acpi.h> includes those files and for CONFIG_ACPI unset it provides stub ACPI symbols to be used in that case. Second, there are ordering dependencies between those files that always have to be met. Namely, it is required that <acpi/acpi_bus.h> be included prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the latter depends on are always there. And <acpi/acpi.h> which provides basic ACPICA type declarations should always be included prior to any other ACPI headers in CONFIG_ACPI builds. That also is taken care of including <linux/acpi.h> as appropriate. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tony Luck <tony.luck@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff) Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-12-03 08:49:16 +08:00
ACPI: cpufreq, processor: fix compile error in drivers/acpi/processor_perflib.c When trying to build 2.6.28-rc1 on ia64, make aborts with: CC drivers/acpi/processor_perflib.o drivers/acpi/processor_perflib.c:41:28: error: asm/cpufeature.h: No such file or directory drivers/acpi/processor_perflib.c: In function ‘acpi_processor_get_performance_info’: drivers/acpi/processor_perflib.c:364: error: implicit declaration of function ‘boot_cpu_has’ drivers/acpi/processor_perflib.c:364: error: ‘X86_FEATURE_EST’ undeclared (first use in this function) drivers/acpi/processor_perflib.c:364: error: (Each undeclared identifier is reported only once drivers/acpi/processor_perflib.c:364: error: for each function it appears in.) make[2]: *** [drivers/acpi/processor_perflib.o] Error 1 make[1]: *** [drivers/acpi] Error 2 make: *** [drivers] Error 2 this patch fix it. Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> Acked-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2008-10-24 17:22:04 +08:00
ACPI: cpufreq, processor: Detect old BIOS, not supporting CPU freq on a recent CPU. On Intel CPUs it is rather common and a good hint that BIOSes which do provide _PPC func, but not the frequencies itself in _PSS function, are old and need to be updated for CPU freq support. Tell the user/vendor he has a BIOS/firmware problem. Make use of FW_BUG interface to give vendors and users the ability to automatically check with (or let linuxfirmwarekit do that): dmesg |grep "Firmware Bug" Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-09-01 14:27:04 +02:00
ACPI: cpufreq, processor: fix compile error in drivers/acpi/processor_perflib.c When trying to build 2.6.28-rc1 on ia64, make aborts with: CC drivers/acpi/processor_perflib.o drivers/acpi/processor_perflib.c:41:28: error: asm/cpufeature.h: No such file or directory drivers/acpi/processor_perflib.c: In function ‘acpi_processor_get_performance_info’: drivers/acpi/processor_perflib.c:364: error: implicit declaration of function ‘boot_cpu_has’ drivers/acpi/processor_perflib.c:364: error: ‘X86_FEATURE_EST’ undeclared (first use in this function) drivers/acpi/processor_perflib.c:364: error: (Each undeclared identifier is reported only once drivers/acpi/processor_perflib.c:364: error: for each function it appears in.) make[2]: *** [drivers/acpi/processor_perflib.o] Error 1 make[1]: *** [drivers/acpi] Error 2 make: *** [drivers] Error 2 this patch fix it. Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> Acked-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2008-10-24 17:22:04 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
cpufreq acpi: only call _PPC after cpufreq ACPI init funcs got called already Ingo Molnar provided a fix to not call _PPC at processor driver initialization time in "[PATCH] ACPI: fix cpufreq regression" (git commit e4233dec749a3519069d9390561b5636a75c7579) But it can still happen that _PPC is called at processor driver initialization time. This patch should make sure that this is not possible anymore. Signed-off-by: Thomas Renninger <trenn@suse.de> Cc: Andi Kleen <andi@firstfloor.org> Cc: Len Brown <lenb@kernel.org> Cc: Dave Jones <davej@codemonkey.org.uk> Cc: Ingo Molnar <mingo@elte.hu> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-29 22:32:58 -07:00
ACPI: Fix thermal shutdowns Do not use unsigned int if there is test for negative number... See drivers/acpi/processor_perflib.c static unsigned int ignore_ppc = -1; ... if (event == CPUFREQ_START && ignore_ppc <= 0) { ignore_ppc = 0; ... Signed-off-by: Milan Broz <mbroz@redhat.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-08-12 17:48:27 +02:00
ACPI: Fix now signed module parameter. Signed-off-by: Milan Broz <mbroz@redhat.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-08-16 02:11:28 +02:00
ACPI: add "processor.ignore_ppc" hook to workaround BIOS _PPC weirdness There have been fixes using _PPC, which seem to unhide a problem on HP nx6125 (double cpufreq switch freezes the machine for several seconds). This one should provide a workaround for the nx6125 and for possible other machines that show any weird _PPC behaviour. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2007-05-18 21:59:28 -05:00
ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier 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>
2019-08-28 14:20:13 +05:30
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
ACPI: Change acpi_evaluate_integer to support 64-bit on 32-bit kernels As of version 2.0, ACPI can return 64-bit integers. The current acpi_evaluate_integer only supports 64-bit integers on 64-bit platforms. Change the argument to take a pointer to an acpi_integer so we support 64-bit integers on all platforms. lenb: replaced use of "acpi_integer" with "unsigned long long" lenb: fixed bug in acpi_thermal_trips_update() Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-10-10 02:22:59 -04:00
ACPI: processor: perflib: Use the "no limit" frequency QoS When _PPC returns 0, it means that the CPU frequency is not limited by the platform firmware, so make acpi_processor_get_platform_limit() update the frequency QoS request used by it to "no limit" in that case. This addresses a problem with limiting CPU frequency artificially on some systems after CPU offline/online to the frequency that corresponds to the first entry in the _PSS return package. Reported-by: Pratyush Yadav <ptyadav@amazon.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Pratyush Yadav <ptyadav@amazon.de> Tested-by: Pratyush Yadav <ptyadav@amazon.de>
2022-12-28 22:21:49 +01:00
ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier 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>
2019-08-28 14:20:13 +05:30
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: delete tracing macros from drivers/acpi/*.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-27 00:41:40 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor: perflib: Eliminate redundant status check One of the "status != AE_NOT_FOUND" checks in acpi_processor_get_platform_limit() is redundant, so rearrange the code to eliminate it. No functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-03-05 19:40:36 +01:00
ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier 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>
2019-08-28 14:20:13 +05:30
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor: perflib: Eliminate redundant status check One of the "status != AE_NOT_FOUND" checks in acpi_processor_get_platform_limit() is redundant, so rearrange the code to eliminate it. No functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-03-05 19:40:36 +01:00
ACPI: utils: Introduce acpi_evaluation_failure_warn() Quite a few users of ACPI objects want to log a warning message if the evaluation fails which is a repeating pattern, so introduce a helper function for that purpose and convert some code where it is open-coded to using it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-03-05 19:41:44 +01:00
ACPI: processor: perflib: Eliminate redundant status check One of the "status != AE_NOT_FOUND" checks in acpi_processor_get_platform_limit() is redundant, so rearrange the code to eliminate it. No functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-03-05 19:40:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor: perflib: Use the "no limit" frequency QoS When _PPC returns 0, it means that the CPU frequency is not limited by the platform firmware, so make acpi_processor_get_platform_limit() update the frequency QoS request used by it to "no limit" in that case. This addresses a problem with limiting CPU frequency artificially on some systems after CPU offline/online to the frequency that corresponds to the first entry in the _PSS return package. Reported-by: Pratyush Yadav <ptyadav@amazon.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Pratyush Yadav <ptyadav@amazon.de> Tested-by: Pratyush Yadav <ptyadav@amazon.de>
2022-12-28 22:21:49 +01:00
ACPI: cpufreq: Print _PPC changes via cpufreq debug layer enabled with CPU_FREQ_DEBUG Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2007-10-31 15:41:42 +01:00
ACPI: processor: perflib: Avoid updating frequency QoS unnecessarily Modify acpi_processor_get_platform_limit() to avoid updating its frequency QoS request when the _PPC return value has not changed by comparing that value to the previous _PPC return value stored in the performance_platform_limit field of the struct acpi_processor corresponding to the given CPU. While at it, do the _PPC return value check against the state count earlier, to avoid setting performance_platform_limit to an invalid value, and make acpi_processor_ppc_init() use FREQ_QOS_MAX_DEFAULT_VALUE as the "no limit" frequency QoS for consistency. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-28 22:24:10 +01:00
ACPI: processor: perflib: Use the "no limit" frequency QoS When _PPC returns 0, it means that the CPU frequency is not limited by the platform firmware, so make acpi_processor_get_platform_limit() update the frequency QoS request used by it to "no limit" in that case. This addresses a problem with limiting CPU frequency artificially on some systems after CPU offline/online to the frequency that corresponds to the first entry in the _PSS return package. Reported-by: Pratyush Yadav <ptyadav@amazon.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Pratyush Yadav <ptyadav@amazon.de> Tested-by: Pratyush Yadav <ptyadav@amazon.de>
2022-12-28 22:21:49 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor: perflib: Avoid updating frequency QoS unnecessarily Modify acpi_processor_get_platform_limit() to avoid updating its frequency QoS request when the _PPC return value has not changed by comparing that value to the previous _PPC return value stored in the performance_platform_limit field of the struct acpi_processor corresponding to the given CPU. While at it, do the _PPC return value check against the state count earlier, to avoid setting performance_platform_limit to an invalid value, and make acpi_processor_ppc_init() use FREQ_QOS_MAX_DEFAULT_VALUE as the "no limit" frequency QoS for consistency. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-28 22:24:10 +01:00
ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier 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>
2019-08-28 14:20:13 +05:30
ACPI: processor: perflib: Use the "no limit" frequency QoS When _PPC returns 0, it means that the CPU frequency is not limited by the platform firmware, so make acpi_processor_get_platform_limit() update the frequency QoS request used by it to "no limit" in that case. This addresses a problem with limiting CPU frequency artificially on some systems after CPU offline/online to the frequency that corresponds to the first entry in the _PSS return package. Reported-by: Pratyush Yadav <ptyadav@amazon.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Pratyush Yadav <ptyadav@amazon.de> Tested-by: Pratyush Yadav <ptyadav@amazon.de>
2022-12-28 22:21:49 +01:00
ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier 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>
2019-08-28 14:20:13 +05:30
ACPI: delete tracing macros from drivers/acpi/*.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-27 00:41:40 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: Notify the _PPC evaluation status to the platform According to the ACPI spec(section 8.4.4.3) OSPM should convey the _PPC evaluations status to the platform if there exists the _OST object. The _OST contains two arguments: The first is the PERFORMANCE notificatin event. The second is the status of _PPC object. OSPM will convey the _PPC evaluation status to the platform. Of course when the module parameter of "ignore_ppc" is added, OSPM won't evaluate the _PPC object. But it will call the _OST object. At the same time the _OST object will be evaluated only when the PERFORMANCE notification event is received. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-10-16 09:20:41 +08:00
ACPI: fix various typos in comments Fix trivial ACPI driver comment typos. s/notifcations/notifications/ s/Ajust/Adjust/ s/preform/perform/ s/atrributes/attributes/ s/Souce/Source/ s/Evalutes/Evaluates/ s/Evalutes/Evaluates/ s/specifiy/specify/ s/promixity/proximity/ s/presuambly/presumably/ s/Evalute/Evaluate/ s/specificed/specified/ s/rountine/routine/ s/previosuly/previously/ Change comment referencing pcc_send_cmd to send_pcc_cmd. Signed-off-by: Tom Saeger <tom.saeger@oracle.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-03-12 18:55:35 -07:00
ACPI: Notify the _PPC evaluation status to the platform According to the ACPI spec(section 8.4.4.3) OSPM should convey the _PPC evaluations status to the platform if there exists the _OST object. The _OST contains two arguments: The first is the PERFORMANCE notificatin event. The second is the status of _PPC object. OSPM will convey the _PPC evaluation status to the platform. Of course when the module parameter of "ignore_ppc" is added, OSPM won't evaluate the _PPC object. But it will call the _OST object. At the same time the _OST object will be evaluated only when the PERFORMANCE notification event is received. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-10-16 09:20:41 +08:00
ACPI / processor: use acpi_evaluate_ost() to replace open-coded version Use public function acpi_evaluate_ost() to replace open-coded version of evaluating ACPI _OST method. Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-19 14:02:18 +08:00
ACPI: Notify the _PPC evaluation status to the platform According to the ACPI spec(section 8.4.4.3) OSPM should convey the _PPC evaluations status to the platform if there exists the _OST object. The _OST contains two arguments: The first is the PERFORMANCE notificatin event. The second is the status of _PPC object. OSPM will convey the _PPC evaluation status to the platform. Of course when the module parameter of "ignore_ppc" is added, OSPM won't evaluate the _PPC object. But it will call the _OST object. At the same time the _OST object will be evaluated only when the PERFORMANCE notification event is received. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-10-16 09:20:41 +08:00
ACPI / processor: Make acpi_processor_ppc_has_changed() void The return value of acpi_processor_ppc_has_changed() is never used, so make it void. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
2016-11-18 13:57:54 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: add "processor.ignore_ppc" hook to workaround BIOS _PPC weirdness There have been fixes using _PPC, which seem to unhide a problem on HP nx6125 (double cpufreq switch freezes the machine for several seconds). This one should provide a workaround for the nx6125 and for possible other machines that show any weird _PPC behaviour. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2007-05-18 21:59:28 -05:00
ACPI: processor_perflib: Do not send _PPC change notification if not ready The following warning was triggered after resumed from S3 - if all the nonboot CPUs were put offline before suspend: [ 1840.329515] unchecked MSR access error: RDMSR from 0x771 at rIP: 0xffffffff86061e3a (native_read_msr+0xa/0x30) [ 1840.329516] Call Trace: [ 1840.329521] __rdmsr_on_cpu+0x33/0x50 [ 1840.329525] generic_exec_single+0x81/0xb0 [ 1840.329527] smp_call_function_single+0xd2/0x100 [ 1840.329530] ? acpi_ds_result_pop+0xdd/0xf2 [ 1840.329532] ? acpi_ds_create_operand+0x215/0x23c [ 1840.329534] rdmsrl_on_cpu+0x57/0x80 [ 1840.329536] ? cpumask_next+0x1b/0x20 [ 1840.329538] ? rdmsrl_on_cpu+0x57/0x80 [ 1840.329541] intel_pstate_update_perf_limits+0xf3/0x220 [ 1840.329544] ? notifier_call_chain+0x4a/0x70 [ 1840.329546] intel_pstate_set_policy+0x4e/0x150 [ 1840.329548] cpufreq_set_policy+0xcd/0x2f0 [ 1840.329550] cpufreq_update_policy+0xb2/0x130 [ 1840.329552] ? cpufreq_update_policy+0x130/0x130 [ 1840.329556] acpi_processor_ppc_has_changed+0x65/0x80 [ 1840.329558] acpi_processor_notify+0x80/0x100 [ 1840.329561] acpi_ev_notify_dispatch+0x44/0x5c [ 1840.329563] acpi_os_execute_deferred+0x14/0x20 [ 1840.329565] process_one_work+0x193/0x3c0 [ 1840.329567] worker_thread+0x35/0x3b0 [ 1840.329569] kthread+0x125/0x140 [ 1840.329571] ? process_one_work+0x3c0/0x3c0 [ 1840.329572] ? kthread_park+0x60/0x60 [ 1840.329575] ? do_syscall_64+0x67/0x180 [ 1840.329577] ret_from_fork+0x25/0x30 [ 1840.329585] unchecked MSR access error: WRMSR to 0x774 (tried to write 0x0000000000000000) at rIP: 0xffffffff86061f78 (native_write_msr+0x8/0x30) [ 1840.329586] Call Trace: [ 1840.329587] __wrmsr_on_cpu+0x37/0x40 [ 1840.329589] generic_exec_single+0x81/0xb0 [ 1840.329592] smp_call_function_single+0xd2/0x100 [ 1840.329594] ? acpi_ds_create_operand+0x215/0x23c [ 1840.329595] ? cpumask_next+0x1b/0x20 [ 1840.329597] wrmsrl_on_cpu+0x57/0x70 [ 1840.329598] ? rdmsrl_on_cpu+0x57/0x80 [ 1840.329599] ? wrmsrl_on_cpu+0x57/0x70 [ 1840.329602] intel_pstate_hwp_set+0xd3/0x150 [ 1840.329604] intel_pstate_set_policy+0x119/0x150 [ 1840.329606] cpufreq_set_policy+0xcd/0x2f0 [ 1840.329607] cpufreq_update_policy+0xb2/0x130 [ 1840.329610] ? cpufreq_update_policy+0x130/0x130 [ 1840.329613] acpi_processor_ppc_has_changed+0x65/0x80 [ 1840.329615] acpi_processor_notify+0x80/0x100 [ 1840.329617] acpi_ev_notify_dispatch+0x44/0x5c [ 1840.329619] acpi_os_execute_deferred+0x14/0x20 [ 1840.329620] process_one_work+0x193/0x3c0 [ 1840.329622] worker_thread+0x35/0x3b0 [ 1840.329624] kthread+0x125/0x140 [ 1840.329625] ? process_one_work+0x3c0/0x3c0 [ 1840.329626] ? kthread_park+0x60/0x60 [ 1840.329628] ? do_syscall_64+0x67/0x180 [ 1840.329631] ret_from_fork+0x25/0x30 This is because if there's only one online CPU, the MSR_PM_ENABLE (package wide)can not be enabled after resumed, due to intel_pstate_hwp_enable() will only be invoked on AP's online process after resumed - if there's no AP online, the HWP remains disabled after resumed (BIOS has disabled it in S3). Then if there comes a _PPC change notification which touches HWP register during this stage, the warning is triggered. Since we don't call acpi_processor_register_performance() when HWP is enabled, the pr->performance will be NULL. When this is NULL we don't need to do _PPC change notification. Reported-by: Doug Smythies <dsmythies@telus.net> Suggested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Yu Chen <yu.c.chen@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-01-29 10:26:46 +08:00
ACPI: Notify the _PPC evaluation status to the platform According to the ACPI spec(section 8.4.4.3) OSPM should convey the _PPC evaluations status to the platform if there exists the _OST object. The _OST contains two arguments: The first is the PERFORMANCE notificatin event. The second is the status of _PPC object. OSPM will convey the _PPC evaluation status to the platform. Of course when the module parameter of "ignore_ppc" is added, OSPM won't evaluate the _PPC object. But it will call the _OST object. At the same time the _OST object will be evaluated only when the PERFORMANCE notification event is received. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-10-16 09:20:41 +08:00
ACPI / processor: Make acpi_processor_ppc_has_changed() void The return value of acpi_processor_ppc_has_changed() is never used, so make it void. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
2016-11-18 13:57:54 +01:00
ACPI: Notify the _PPC evaluation status to the platform According to the ACPI spec(section 8.4.4.3) OSPM should convey the _PPC evaluations status to the platform if there exists the _OST object. The _OST contains two arguments: The first is the PERFORMANCE notificatin event. The second is the status of _PPC object. OSPM will convey the _PPC evaluation status to the platform. Of course when the module parameter of "ignore_ppc" is added, OSPM won't evaluate the _PPC object. But it will call the _OST object. At the same time the _OST object will be evaluated only when the PERFORMANCE notification event is received. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-10-16 09:20:41 +08:00
ACPI: add "processor.ignore_ppc" hook to workaround BIOS _PPC weirdness There have been fixes using _PPC, which seem to unhide a problem on HP nx6125 (double cpufreq switch freezes the machine for several seconds). This one should provide a workaround for the nx6125 and for possible other machines that show any weird _PPC behaviour. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2007-05-18 21:59:28 -05:00
ACPI: Notify the _PPC evaluation status to the platform According to the ACPI spec(section 8.4.4.3) OSPM should convey the _PPC evaluations status to the platform if there exists the _OST object. The _OST contains two arguments: The first is the PERFORMANCE notificatin event. The second is the status of _PPC object. OSPM will convey the _PPC evaluation status to the platform. Of course when the module parameter of "ignore_ppc" is added, OSPM won't evaluate the _PPC object. But it will call the _OST object. At the same time the _OST object will be evaluated only when the PERFORMANCE notification event is received. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-10-16 09:20:41 +08:00
ACPI / processor: Make acpi_processor_ppc_has_changed() void The return value of acpi_processor_ppc_has_changed() is never used, so make it void. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
2016-11-18 13:57:54 +01:00
cpufreq: intel_pstate: Driver-specific handling of _PPC updates In some cases, the platform firmware disables or enables turbo frequencies for all CPUs globally before triggering a _PPC change notification for one of them. Obviously, that global change affects all CPUs, not just the notified one, and it needs to be acted upon by cpufreq. The intel_pstate driver is able to detect such global changes of the settings, but it also needs to update policy limits for all CPUs if that happens, in particular if turbo frequencies are enabled globally - to allow them to be used. For this reason, introduce a new cpufreq driver callback to be invoked on _PPC notifications, if present, instead of simply calling cpufreq_update_policy() for the notified CPU and make intel_pstate use it to trigger policy updates for all CPUs in the system if global settings change. Link: https://bugzilla.kernel.org/show_bug.cgi?id=200759 Reported-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-03-26 12:15:13 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[ACPI/CPUFREQ] Introduce bios_limit per cpu cpufreq sysfs interface This interface is mainly intended (and implemented) for ACPI _PPC BIOS frequency limitations, but other cpufreq drivers can also use it for similar use-cases. Why is this needed: Currently it's not obvious why cpufreq got limited. People see cpufreq/scaling_max_freq reduced, but this could have happened by: - any userspace prog writing to scaling_max_freq - thermal limitations - hardware (_PPC in ACPI case) limitiations Therefore export bios_limit (in kHz) to: - Point the user that it's the BIOS (broken or intended) which limits frequency - Export it as a sysfs interface for userspace progs. While this was a rarely used feature on laptops, there will appear more and more server implemenations providing "Green IT" features like allowing the service processor to limit the frequency. People want to know about HW/BIOS frequency limitations. All ACPI P-state driven cpufreq drivers are covered with this patch: - powernow-k8 - powernow-k7 - acpi-cpufreq Tested with a patched DSDT which limits the first two cores (_PPC returns 1) via _PPC, exposed by bios_limit: # echo 2200000 >cpu2/cpufreq/scaling_max_freq # cat cpu*/cpufreq/scaling_max_freq 2600000 2600000 2200000 2200000 # #scaling_max_freq shows general user/thermal/BIOS limitations # cat cpu*/cpufreq/bios_limit 2600000 2600000 2800000 2800000 # #bios_limit only shows the HW/BIOS limitation CC: Pallipadi Venkatesh <venkatesh.pallipadi@intel.com> CC: Len Brown <lenb@kernel.org> CC: davej@codemonkey.org.uk CC: linux@dominikbrodowski.net Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Dave Jones <davej@redhat.com>
2009-11-19 12:31:01 +01:00
ACPI: processor: perflib: Adjust white space Some inconsistent usage of white space in the ACPI processor performance library code causes that code to be somewhat harder to read that it would have been otherwise, so adjust the white space in there to address that. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:03:30 +01:00
[ACPI/CPUFREQ] Introduce bios_limit per cpu cpufreq sysfs interface This interface is mainly intended (and implemented) for ACPI _PPC BIOS frequency limitations, but other cpufreq drivers can also use it for similar use-cases. Why is this needed: Currently it's not obvious why cpufreq got limited. People see cpufreq/scaling_max_freq reduced, but this could have happened by: - any userspace prog writing to scaling_max_freq - thermal limitations - hardware (_PPC in ACPI case) limitiations Therefore export bios_limit (in kHz) to: - Point the user that it's the BIOS (broken or intended) which limits frequency - Export it as a sysfs interface for userspace progs. While this was a rarely used feature on laptops, there will appear more and more server implemenations providing "Green IT" features like allowing the service processor to limit the frequency. People want to know about HW/BIOS frequency limitations. All ACPI P-state driven cpufreq drivers are covered with this patch: - powernow-k8 - powernow-k7 - acpi-cpufreq Tested with a patched DSDT which limits the first two cores (_PPC returns 1) via _PPC, exposed by bios_limit: # echo 2200000 >cpu2/cpufreq/scaling_max_freq # cat cpu*/cpufreq/scaling_max_freq 2600000 2600000 2200000 2200000 # #scaling_max_freq shows general user/thermal/BIOS limitations # cat cpu*/cpufreq/bios_limit 2600000 2600000 2800000 2800000 # #bios_limit only shows the HW/BIOS limitation CC: Pallipadi Venkatesh <venkatesh.pallipadi@intel.com> CC: Len Brown <lenb@kernel.org> CC: davej@codemonkey.org.uk CC: linux@dominikbrodowski.net Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Dave Jones <davej@redhat.com>
2009-11-19 12:31:01 +01:00
ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier 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>
2019-08-28 14:20:13 +05:30
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier 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>
2019-08-28 14:20:13 +05:30
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
cpufreq: Use per-policy frequency QoS 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-16 12:47:06 +02:00
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
ACPI: processor: Add QoS requests for all CPUs 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-25 02:41:40 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor: Add QoS requests for all CPUs 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-25 02:41:40 +02:00
ACPI: processor: Avoid NULL pointer dereferences at init time 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-10-15 19:35:20 +02:00
ACPI: processor: Add QoS requests for all CPUs 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-25 02:41:40 +02:00
ACPI: processor: perflib: Avoid updating frequency QoS unnecessarily Modify acpi_processor_get_platform_limit() to avoid updating its frequency QoS request when the _PPC return value has not changed by comparing that value to the previous _PPC return value stored in the performance_platform_limit field of the struct acpi_processor corresponding to the given CPU. While at it, do the _PPC return value check against the state count earlier, to avoid setting performance_platform_limit to an invalid value, and make acpi_processor_ppc_init() use FREQ_QOS_MAX_DEFAULT_VALUE as the "no limit" frequency QoS for consistency. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-28 22:24:10 +01:00
ACPI: processor: Add QoS requests for all CPUs 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-25 02:41:40 +02:00
ACPI: processor: perflib: Avoid updating frequency QoS unnecessarily Modify acpi_processor_get_platform_limit() to avoid updating its frequency QoS request when the _PPC return value has not changed by comparing that value to the previous _PPC return value stored in the performance_platform_limit field of the struct acpi_processor corresponding to the given CPU. While at it, do the _PPC return value check against the state count earlier, to avoid setting performance_platform_limit to an invalid value, and make acpi_processor_ppc_init() use FREQ_QOS_MAX_DEFAULT_VALUE as the "no limit" frequency QoS for consistency. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-28 22:24:10 +01:00
ACPI: processor: Add QoS requests for all CPUs 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-25 02:41:40 +02:00
ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier 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>
2019-08-28 14:20:13 +05:30
cpufreq: Use per-policy frequency QoS 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-16 12:47:06 +02:00
ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier 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>
2019-08-28 14:20:13 +05:30
ACPI: processor: Add QoS requests for all CPUs 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-25 02:41:40 +02:00
ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier 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>
2019-08-28 14:20:13 +05:30
ACPI: processor: Add QoS requests for all CPUs 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-25 02:41:40 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor_perflib: extend X86 dependency The majority of the processor_perflib code is only used by cpufreq drivers on the x86 architecture and makes no sense without the x86 SMI interactions that rely on I/O port access. Replace the existing #ifdef checks with one that covers all of the code that is only used by x86 drivers, saving a little bit of kernel code size on other architectures. There is likely more code under CONFIG_ACPI_PROCESSOR that falls into this category, but changing those would require a larger rework. Suggested-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20241030123701.1538919-1-arnd@kernel.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-30 12:36:40 +00:00
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
ACPI: utils: Introduce acpi_evaluation_failure_warn() Quite a few users of ACPI objects want to log a warning message if the evaluation fails which is a repeating pattern, so introduce a helper function for that purpose and convert some code where it is open-coded to using it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-03-05 19:41:44 +01:00
ACPI: delete tracing macros from drivers/acpi/*.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-27 00:41:40 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
ACPI: processor: perflib: Drop redundant parentheses Drop some redundant parentheses and rearrange some checks using them in the ACPI processor performance library code for better code clarity. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:04:59 +01:00
ACPI: processor_perflib: Cleanup print messages The log messages in processor_perflib.c is not in consistency, we have some printk() calls with PREFIX, but some are not; we use pr_*() functions without prefix. So add pr_fmt() and unify them with pr_*() functions. While at it, fix some obvious coding style issues when going through the functions. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-02 16:54:32 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor: perflib: Drop redundant parentheses Drop some redundant parentheses and rearrange some checks using them in the ACPI processor performance library code for better code clarity. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:04:59 +01:00
ACPI: processor_perflib: Cleanup print messages The log messages in processor_perflib.c is not in consistency, we have some printk() calls with PREFIX, but some are not; we use pr_*() functions without prefix. So add pr_fmt() and unify them with pr_*() functions. While at it, fix some obvious coding style issues when going through the functions. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-02 16:54:32 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor: perflib: Drop redundant parentheses Drop some redundant parentheses and rearrange some checks using them in the ACPI processor performance library code for better code clarity. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:04:59 +01:00
ACPI: processor_perflib: Cleanup print messages The log messages in processor_perflib.c is not in consistency, we have some printk() calls with PREFIX, but some are not; we use pr_*() functions without prefix. So add pr_fmt() and unify them with pr_*() functions. While at it, fix some obvious coding style issues when going through the functions. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-02 16:54:32 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor_perflib: Cleanup print messages The log messages in processor_perflib.c is not in consistency, we have some printk() calls with PREFIX, but some are not; we use pr_*() functions without prefix. So add pr_fmt() and unify them with pr_*() functions. While at it, fix some obvious coding style issues when going through the functions. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-02 16:54:32 +08:00
ACPI: delete acpi_os_free(), use kfree() directly Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-30 03:19:10 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: delete tracing macros from drivers/acpi/*.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-27 00:41:40 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: Add fixups for AMD P-state figures Some AMD systems may round the frequencies in ACPI tables to 100MHz boundaries. We can obtain the real frequencies from MSRs, so add a quirk to fix these frequencies up on AMD systems. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andre Przywara <andre.przywara@amd.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-09-04 08:28:06 +00:00
ACPI: processor: perflib: Adjust white space Some inconsistent usage of white space in the ACPI processor performance library code causes that code to be somewhat harder to read that it would have been otherwise, so adjust the white space in there to address that. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:03:30 +01:00
ACPI: Add fixups for AMD P-state figures Some AMD systems may round the frequencies in ACPI tables to 100MHz boundaries. We can obtain the real frequencies from MSRs, so add a quirk to fix these frequencies up on AMD systems. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andre Przywara <andre.przywara@amd.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-09-04 08:28:06 +00:00
ACPI: Check MSR valid bit before using P-state frequencies To fix incorrect P-state frequencies which can happen on some AMD systems f594065faf4f9067c2283a34619fc0714e79a98d "ACPI: Add fixups for AMD P-state figures" introduced a quirk to obtain the correct values by reading from AMD specific MSRs. This did cause a regression when running a kernel using that quirk under Xen which does (currently) not pass through MSR reads to the HW. Instead the guest gets a 0 in return. And this seems to cause a failure to initialize the ondemand governour (hard to say for sure as all P-states appear to run at the same frequency). While this should also be fixed in the hypervisor (to allow a guest to read that MSR), this patch is intended to work around the issue in the meantime. In discussion it turned out that indeed real HW/BIOSes may choose to not set the valid bit and thus mark the P-state as invalid. So this could be considered a fix for broken BIOSes that also works around the issue on Xen. Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Cc: 3.7+ <stable@vger.kernel.org> Acked-by: Borislav Petkov <bp@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-22 13:37:21 +01:00
ACPI: Add fixups for AMD P-state figures Some AMD systems may round the frequencies in ACPI tables to 100MHz boundaries. We can obtain the real frequencies from MSRs, so add a quirk to fix these frequencies up on AMD systems. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andre Przywara <andre.przywara@amd.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-09-04 08:28:06 +00:00
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
ACPI: Ignore invalid _PSS entries, but use valid ones The EliteBook 8560W has non-initialized entries in its _PSS ACPI table. Instead of bailing out when the first non-initialized entry is found, ignore it and use only the valid entries. Only bail out if there is no valid entry at all. [v3: Fixes suggested by Konrad] Signed-off-by: Marco Aurelio da Costa <costa@gamic.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-05-04 18:53:44 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
ACPI: utils: Introduce acpi_evaluation_failure_warn() Quite a few users of ACPI objects want to log a warning message if the evaluation fails which is a repeating pattern, so introduce a helper function for that purpose and convert some code where it is open-coded to using it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-03-05 19:41:44 +01:00
ACPI: delete tracing macros from drivers/acpi/*.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-27 00:41:40 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: Remove unnecessary from/to-void* and to-void casts in drivers/acpi Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Len Brown <len.brown@intel.com>
2006-10-01 00:28:50 +02:00
ACPI: processor: perflib: Drop redundant parentheses Drop some redundant parentheses and rearrange some checks using them in the ACPI processor performance library code for better code clarity. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:04:59 +01:00
ACPI: processor_perflib: Cleanup print messages The log messages in processor_perflib.c is not in consistency, we have some printk() calls with PREFIX, but some are not; we use pr_*() functions without prefix. So add pr_fmt() and unify them with pr_*() functions. While at it, fix some obvious coding style issues when going through the functions. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-02 16:54:32 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor: Get rid of ACPICA message printing The ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() macros are used for message printing in the ACPICA code and they should not be used elsewhere. Special configuration (either kernel command line or sysfs-based) is needed to see the messages printed by them and the format of those messages is also special and convoluted. For this reason, replace all of the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances in the ACPI processor driver with corresponding dev_*(), acpi_handle_*() and pr_*() calls depending on the context in which they appear. Also drop the ACPI_PROCESSOR_COMPONENT definition that is not going to be necessary any more. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
2021-02-22 19:59:13 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
treewide: kmalloc() -> kmalloc_array() The kmalloc() function has a 2-factor argument form, kmalloc_array(). This patch replaces cases of: kmalloc(a * b, gfp) with: kmalloc_array(a * b, gfp) as well as handling cases of: kmalloc(a * b * c, gfp) with: kmalloc(array3_size(a, b, c), gfp) as it's slightly less ugly than: kmalloc_array(array_size(a, b), c, gfp) This does, however, attempt to ignore constant size factors like: kmalloc(4 * 1024, gfp) though any constants defined via macros get caught up in the conversion. Any factors with a sizeof() of "unsigned char", "char", and "u8" were dropped, since they're redundant. The tools/ directory was manually excluded, since it has its own implementation of kmalloc(). The Coccinelle script used for this was: // Fix redundant parens around sizeof(). @@ type TYPE; expression THING, E; @@ ( kmalloc( - (sizeof(TYPE)) * E + sizeof(TYPE) * E , ...) | kmalloc( - (sizeof(THING)) * E + sizeof(THING) * E , ...) ) // Drop single-byte sizes and redundant parens. @@ expression COUNT; typedef u8; typedef __u8; @@ ( kmalloc( - sizeof(u8) * (COUNT) + COUNT , ...) | kmalloc( - sizeof(__u8) * (COUNT) + COUNT , ...) | kmalloc( - sizeof(char) * (COUNT) + COUNT , ...) | kmalloc( - sizeof(unsigned char) * (COUNT) + COUNT , ...) | kmalloc( - sizeof(u8) * COUNT + COUNT , ...) | kmalloc( - sizeof(__u8) * COUNT + COUNT , ...) | kmalloc( - sizeof(char) * COUNT + COUNT , ...) | kmalloc( - sizeof(unsigned char) * COUNT + COUNT , ...) ) // 2-factor product with sizeof(type/expression) and identifier or constant. @@ type TYPE; expression THING; identifier COUNT_ID; constant COUNT_CONST; @@ ( - kmalloc + kmalloc_array ( - sizeof(TYPE) * (COUNT_ID) + COUNT_ID, sizeof(TYPE) , ...) | - kmalloc + kmalloc_array ( - sizeof(TYPE) * COUNT_ID + COUNT_ID, sizeof(TYPE) , ...) | - kmalloc + kmalloc_array ( - sizeof(TYPE) * (COUNT_CONST) + COUNT_CONST, sizeof(TYPE) , ...) | - kmalloc + kmalloc_array ( - sizeof(TYPE) * COUNT_CONST + COUNT_CONST, sizeof(TYPE) , ...) | - kmalloc + kmalloc_array ( - sizeof(THING) * (COUNT_ID) + COUNT_ID, sizeof(THING) , ...) | - kmalloc + kmalloc_array ( - sizeof(THING) * COUNT_ID + COUNT_ID, sizeof(THING) , ...) | - kmalloc + kmalloc_array ( - sizeof(THING) * (COUNT_CONST) + COUNT_CONST, sizeof(THING) , ...) | - kmalloc + kmalloc_array ( - sizeof(THING) * COUNT_CONST + COUNT_CONST, sizeof(THING) , ...) ) // 2-factor product, only identifiers. @@ identifier SIZE, COUNT; @@ - kmalloc + kmalloc_array ( - SIZE * COUNT + COUNT, SIZE , ...) // 3-factor product with 1 sizeof(type) or sizeof(expression), with // redundant parens removed. @@ expression THING; identifier STRIDE, COUNT; type TYPE; @@ ( kmalloc( - sizeof(TYPE) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kmalloc( - sizeof(TYPE) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kmalloc( - sizeof(TYPE) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kmalloc( - sizeof(TYPE) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kmalloc( - sizeof(THING) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | kmalloc( - sizeof(THING) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | kmalloc( - sizeof(THING) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | kmalloc( - sizeof(THING) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) ) // 3-factor product with 2 sizeof(variable), with redundant parens removed. @@ expression THING1, THING2; identifier COUNT; type TYPE1, TYPE2; @@ ( kmalloc( - sizeof(TYPE1) * sizeof(TYPE2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | kmalloc( - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | kmalloc( - sizeof(THING1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | kmalloc( - sizeof(THING1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | kmalloc( - sizeof(TYPE1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) | kmalloc( - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) ) // 3-factor product, only identifiers, with redundant parens removed. @@ identifier STRIDE, SIZE, COUNT; @@ ( kmalloc( - (COUNT) * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | kmalloc( - COUNT * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | kmalloc( - COUNT * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kmalloc( - (COUNT) * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | kmalloc( - COUNT * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kmalloc( - (COUNT) * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kmalloc( - (COUNT) * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kmalloc( - COUNT * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) ) // Any remaining multi-factor products, first at least 3-factor products, // when they're not all constants... @@ expression E1, E2, E3; constant C1, C2, C3; @@ ( kmalloc(C1 * C2 * C3, ...) | kmalloc( - (E1) * E2 * E3 + array3_size(E1, E2, E3) , ...) | kmalloc( - (E1) * (E2) * E3 + array3_size(E1, E2, E3) , ...) | kmalloc( - (E1) * (E2) * (E3) + array3_size(E1, E2, E3) , ...) | kmalloc( - E1 * E2 * E3 + array3_size(E1, E2, E3) , ...) ) // And then all remaining 2 factors products when they're not all constants, // keeping sizeof() as the second factor argument. @@ expression THING, E1, E2; type TYPE; constant C1, C2, C3; @@ ( kmalloc(sizeof(THING) * C2, ...) | kmalloc(sizeof(TYPE) * C2, ...) | kmalloc(C1 * C2 * C3, ...) | kmalloc(C1 * C2, ...) | - kmalloc + kmalloc_array ( - sizeof(TYPE) * (E2) + E2, sizeof(TYPE) , ...) | - kmalloc + kmalloc_array ( - sizeof(TYPE) * E2 + E2, sizeof(TYPE) , ...) | - kmalloc + kmalloc_array ( - sizeof(THING) * (E2) + E2, sizeof(THING) , ...) | - kmalloc + kmalloc_array ( - sizeof(THING) * E2 + E2, sizeof(THING) , ...) | - kmalloc + kmalloc_array ( - (E1) * E2 + E1, E2 , ...) | - kmalloc + kmalloc_array ( - (E1) * (E2) + E1, E2 , ...) | - kmalloc + kmalloc_array ( - E1 * E2 + E1, E2 , ...) ) Signed-off-by: Kees Cook <keescook@chromium.org>
2018-06-12 13:55:00 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor: Get rid of ACPICA message printing The ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() macros are used for message printing in the ACPICA code and they should not be used elsewhere. Special configuration (either kernel command line or sysfs-based) is needed to see the messages printed by them and the format of those messages is also special and convoluted. For this reason, replace all of the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances in the ACPI processor driver with corresponding dev_*(), acpi_handle_*() and pr_*() calls depending on the context in which they appear. Also drop the ACPI_PROCESSOR_COMPONENT definition that is not going to be necessary any more. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
2021-02-22 19:59:13 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor: Get rid of ACPICA message printing The ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() macros are used for message printing in the ACPICA code and they should not be used elsewhere. Special configuration (either kernel command line or sysfs-based) is needed to see the messages printed by them and the format of those messages is also special and convoluted. For this reason, replace all of the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances in the ACPI processor driver with corresponding dev_*(), acpi_handle_*() and pr_*() calls depending on the context in which they appear. Also drop the ACPI_PROCESSOR_COMPONENT definition that is not going to be necessary any more. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
2021-02-22 19:59:13 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: Add fixups for AMD P-state figures Some AMD systems may round the frequencies in ACPI tables to 100MHz boundaries. We can obtain the real frequencies from MSRs, so add a quirk to fix these frequencies up on AMD systems. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andre Przywara <andre.przywara@amd.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-09-04 08:28:06 +00:00
ACPI: processor: Get rid of ACPICA message printing The ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() macros are used for message printing in the ACPICA code and they should not be used elsewhere. Special configuration (either kernel command line or sysfs-based) is needed to see the messages printed by them and the format of those messages is also special and convoluted. For this reason, replace all of the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances in the ACPI processor driver with corresponding dev_*(), acpi_handle_*() and pr_*() calls depending on the context in which they appear. Also drop the ACPI_PROCESSOR_COMPONENT definition that is not going to be necessary any more. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
2021-02-22 19:59:13 +01:00
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
ACPI: processor: Get rid of ACPICA message printing The ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() macros are used for message printing in the ACPICA code and they should not be used elsewhere. Special configuration (either kernel command line or sysfs-based) is needed to see the messages printed by them and the format of those messages is also special and convoluted. For this reason, replace all of the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances in the ACPI processor driver with corresponding dev_*(), acpi_handle_*() and pr_*() calls depending on the context in which they appear. Also drop the ACPI_PROCESSOR_COMPONENT definition that is not going to be necessary any more. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
2021-02-22 19:59:13 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: sanity check _PSS frequency to prevent cpufreq crash When BIOS SETUP is changed to disable EIST, some BIOS hand the OS an un-initialized _PSS: Name (_PSS, Package (0x06) { Package (0x06) { 0x80000000, // frequency [MHz] 0x80000000, // power [mW] 0x80000000, // latency [us] 0x80000000, // BM latency [us] 0x80000000, // control 0x80000000 // status }, ... These are outrageous values for frequency, power and latency, raising the question where to draw the line between legal and illegal. We tend to survive garbage in the power and latency fields, but we can BUG_ON when garbage is in the frequency field. Cpufreq multiplies the frequency by 1000 and stores it in a u32 KHz. So disregard a _PSS with a frequency so large that it can't be represented by cpufreq. https://bugzilla.redhat.com/show_bug.cgi?id=500311 Signed-off-by: Len Brown <len.brown@intel.com>
2009-05-26 15:11:06 -04:00
ACPI: Fix whitespace inconsistencies 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>
2020-11-05 03:06:00 +01:00
ACPI: sanity check _PSS frequency to prevent cpufreq crash When BIOS SETUP is changed to disable EIST, some BIOS hand the OS an un-initialized _PSS: Name (_PSS, Package (0x06) { Package (0x06) { 0x80000000, // frequency [MHz] 0x80000000, // power [mW] 0x80000000, // latency [us] 0x80000000, // BM latency [us] 0x80000000, // control 0x80000000 // status }, ... These are outrageous values for frequency, power and latency, raising the question where to draw the line between legal and illegal. We tend to survive garbage in the power and latency fields, but we can BUG_ON when garbage is in the frequency field. Cpufreq multiplies the frequency by 1000 and stores it in a u32 KHz. So disregard a _PSS with a frequency so large that it can't be represented by cpufreq. https://bugzilla.redhat.com/show_bug.cgi?id=500311 Signed-off-by: Len Brown <len.brown@intel.com>
2009-05-26 15:11:06 -04:00
ACPI: processor: perflib: Drop redundant parentheses Drop some redundant parentheses and rearrange some checks using them in the ACPI processor performance library code for better code clarity. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:04:59 +01:00
ACPI: processor_perflib: Cleanup print messages The log messages in processor_perflib.c is not in consistency, we have some printk() calls with PREFIX, but some are not; we use pr_*() functions without prefix. So add pr_fmt() and unify them with pr_*() functions. While at it, fix some obvious coding style issues when going through the functions. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-02 16:54:32 +08:00
ACPI: Ignore invalid _PSS entries, but use valid ones The EliteBook 8560W has non-initialized entries in its _PSS ACPI table. Instead of bailing out when the first non-initialized entry is found, ignore it and use only the valid entries. Only bail out if there is no valid entry at all. [v3: Fixes suggested by Konrad] Signed-off-by: Marco Aurelio da Costa <costa@gamic.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-05-04 18:53:44 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: Ignore invalid _PSS entries, but use valid ones The EliteBook 8560W has non-initialized entries in its _PSS ACPI table. Instead of bailing out when the first non-initialized entry is found, ignore it and use only the valid entries. Only bail out if there is no valid entry at all. [v3: Fixes suggested by Konrad] Signed-off-by: Marco Aurelio da Costa <costa@gamic.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-05-04 18:53:44 +02:00
ACPI: processor_perflib: Cleanup print messages The log messages in processor_perflib.c is not in consistency, we have some printk() calls with PREFIX, but some are not; we use pr_*() functions without prefix. So add pr_fmt() and unify them with pr_*() functions. While at it, fix some obvious coding style issues when going through the functions. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-02 16:54:32 +08:00
ACPI: Ignore invalid _PSS entries, but use valid ones The EliteBook 8560W has non-initialized entries in its _PSS ACPI table. Instead of bailing out when the first non-initialized entry is found, ignore it and use only the valid entries. Only bail out if there is no valid entry at all. [v3: Fixes suggested by Konrad] Signed-off-by: Marco Aurelio da Costa <costa@gamic.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-05-04 18:53:44 +02:00
ACPI: processor_perflib: Cleanup print messages The log messages in processor_perflib.c is not in consistency, we have some printk() calls with PREFIX, but some are not; we use pr_*() functions without prefix. So add pr_fmt() and unify them with pr_*() functions. While at it, fix some obvious coding style issues when going through the functions. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-02 16:54:32 +08:00
ACPI: delete acpi_os_free(), use kfree() directly Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-30 03:19:10 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: delete tracing macros from drivers/acpi/*.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-27 00:41:40 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
acpi: Export the acpi_processor_get_performance_info The git commit d5aaffa9dd531c978c6f3fea06a2972653bd7fc8 (cpufreq: handle cpufreq being disabled for all exported function) tightens the cpufreq API by returning errors when disable_cpufreq() had been called. The problem we are hitting is that the module xen-acpi-processor which uses the ACPI's functions: acpi_processor_register_performance, acpi_processor_preregister_performance, and acpi_processor_notify_smm fails at acpi_processor_register_performance with -22. Note that earlier during bootup in arch/x86/xen/setup.c there is also an call to cpufreq's API: disable_cpufreq(). This is b/c we want the Linux kernel to parse the ACPI data, but leave the cpufreq decisions to the hypervisor. In v3.9 all the checks that d5aaffa9dd531c978c6f3fea06a2972653bd7fc8 added are now hit and the calls to cpufreq_register_notifier will now fail. This means that acpi_processor_ppc_init ends up printing: "Warning: Processor Platform Limit not supported" and the acpi_processor_ppc_status is not set. The repercussions of that is that the call to acpi_processor_register_performance fails right away at: if (!(acpi_processor_ppc_status & PPC_REGISTERED)) and we don't progress any further on parsing and extracting the _P* objects. The only reason the Xen code called that function was b/c it was exported and the only way to gather the P-states. But we can also just make acpi_processor_get_performance_info be exported and not use acpi_processor_register_performance. This patch does so. Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2013-03-05 13:42:54 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: delete tracing macros from drivers/acpi/*.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-27 00:41:40 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: introduce helper function acpi_has_method() Introduce helper function acpi_has_method() and use it in a number of places to simplify code. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-29 00:24:38 +08:00
ACPI: processor: Get rid of ACPICA message printing The ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() macros are used for message printing in the ACPICA code and they should not be used elsewhere. Special configuration (either kernel command line or sysfs-based) is needed to see the messages printed by them and the format of those messages is also special and convoluted. For this reason, replace all of the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances in the ACPI processor driver with corresponding dev_*(), acpi_handle_*() and pr_*() calls depending on the context in which they appear. Also drop the ACPI_PROCESSOR_COMPONENT definition that is not going to be necessary any more. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
2021-02-22 19:59:13 +01:00
ACPI: delete tracing macros from drivers/acpi/*.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-27 00:41:40 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: cpufreq, processor: Detect old BIOS, not supporting CPU freq on a recent CPU. On Intel CPUs it is rather common and a good hint that BIOSes which do provide _PPC func, but not the frequencies itself in _PSS function, are old and need to be updated for CPU freq support. Tell the user/vendor he has a BIOS/firmware problem. Make use of FW_BUG interface to give vendors and users the ability to automatically check with (or let linuxfirmwarekit do that): dmesg |grep "Firmware Bug" Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-09-01 14:27:04 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: cpufreq, processor: Detect old BIOS, not supporting CPU freq on a recent CPU. On Intel CPUs it is rather common and a good hint that BIOSes which do provide _PPC func, but not the frequencies itself in _PSS function, are old and need to be updated for CPU freq support. Tell the user/vendor he has a BIOS/firmware problem. Make use of FW_BUG interface to give vendors and users the ability to automatically check with (or let linuxfirmwarekit do that): dmesg |grep "Firmware Bug" Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-09-01 14:27:04 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: Fix regression where _PPC is not read at boot even when ignore_ppc=0 Earlier, Ingo Molnar posted a patch to make it so that the kernel would avoid reading _PPC on his broken T60. Unfortunately, it seems that with Thomas Renninger's patch last July to eliminate _PPC evaluations when the processor driver loads, the kernel never actually reads _PPC at all! This is problematic if you happen to boot your non-T60 computer in a state where the BIOS _wants_ _PPC to be something other than zero. So, put the _PPC evaluation back into acpi_processor_get_performance_info if ignore_ppc isn't 1. Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-18 10:28:20 -08:00
ACPI: cpufreq, processor: Detect old BIOS, not supporting CPU freq on a recent CPU. On Intel CPUs it is rather common and a good hint that BIOSes which do provide _PPC func, but not the frequencies itself in _PSS function, are old and need to be updated for CPU freq support. Tell the user/vendor he has a BIOS/firmware problem. Make use of FW_BUG interface to give vendors and users the ability to automatically check with (or let linuxfirmwarekit do that): dmesg |grep "Firmware Bug" Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-09-01 14:27:04 +02:00
ACPI: introduce helper function acpi_has_method() Introduce helper function acpi_has_method() and use it in a number of places to simplify code. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-29 00:24:38 +08:00
ACPI: cpufreq, processor: Detect old BIOS, not supporting CPU freq on a recent CPU. On Intel CPUs it is rather common and a good hint that BIOSes which do provide _PPC func, but not the frequencies itself in _PSS function, are old and need to be updated for CPU freq support. Tell the user/vendor he has a BIOS/firmware problem. Make use of FW_BUG interface to give vendors and users the ability to automatically check with (or let linuxfirmwarekit do that): dmesg |grep "Firmware Bug" Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-09-01 14:27:04 +02:00
ACPI: processor_perflib: Cleanup print messages The log messages in processor_perflib.c is not in consistency, we have some printk() calls with PREFIX, but some are not; we use pr_*() functions without prefix. So add pr_fmt() and unify them with pr_*() functions. While at it, fix some obvious coding style issues when going through the functions. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-02 16:54:32 +08:00
ACPI: cpufreq, processor: Detect old BIOS, not supporting CPU freq on a recent CPU. On Intel CPUs it is rather common and a good hint that BIOSes which do provide _PPC func, but not the frequencies itself in _PSS function, are old and need to be updated for CPU freq support. Tell the user/vendor he has a BIOS/firmware problem. Make use of FW_BUG interface to give vendors and users the ability to automatically check with (or let linuxfirmwarekit do that): dmesg |grep "Firmware Bug" Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-09-01 14:27:04 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
acpi: Export the acpi_processor_get_performance_info The git commit d5aaffa9dd531c978c6f3fea06a2972653bd7fc8 (cpufreq: handle cpufreq being disabled for all exported function) tightens the cpufreq API by returning errors when disable_cpufreq() had been called. The problem we are hitting is that the module xen-acpi-processor which uses the ACPI's functions: acpi_processor_register_performance, acpi_processor_preregister_performance, and acpi_processor_notify_smm fails at acpi_processor_register_performance with -22. Note that earlier during bootup in arch/x86/xen/setup.c there is also an call to cpufreq's API: disable_cpufreq(). This is b/c we want the Linux kernel to parse the ACPI data, but leave the cpufreq decisions to the hypervisor. In v3.9 all the checks that d5aaffa9dd531c978c6f3fea06a2972653bd7fc8 added are now hit and the calls to cpufreq_register_notifier will now fail. This means that acpi_processor_ppc_init ends up printing: "Warning: Processor Platform Limit not supported" and the acpi_processor_ppc_status is not set. The repercussions of that is that the call to acpi_processor_register_performance fails right away at: if (!(acpi_processor_ppc_status & PPC_REGISTERED)) and we don't progress any further on parsing and extracting the _P* objects. The only reason the Xen code called that function was b/c it was exported and the only way to gather the P-states. But we can also just make acpi_processor_get_performance_info be exported and not use acpi_processor_register_performance. This patch does so. Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2013-03-05 13:42:54 -05:00
cpufreq: intel_pstate: Request P-states control from SMM if needed Currently, intel_pstate is unable to control P-states on my IvyBridge-based Acer Aspire S5, because they are controlled by SMM on that machine by default and it is necessary to request OS control of P-states from it via the SMI Command register exposed in the ACPI FADT. intel_pstate doesn't do that now, but acpi-cpufreq and other cpufreq drivers for x86 platforms do. Address this problem by making intel_pstate use the ACPI-defined mechanism as well. However, intel_pstate is not modular and it doesn't need the module refcount tricks played by acpi_processor_notify_smm(), so export the core of this function to it as acpi_processor_pstate_control() and make it call that. [The changes in processor_perflib.c related to this should not make any functional difference for the acpi_processor_notify_smm() users]. To be safe, only call acpi_processor_notify_smm() from intel_pstate if ACPI _PPC support is enabled in it. Suggested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
2016-11-17 22:47:47 +01:00
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
cpufreq: intel_pstate: Request P-states control from SMM if needed Currently, intel_pstate is unable to control P-states on my IvyBridge-based Acer Aspire S5, because they are controlled by SMM on that machine by default and it is necessary to request OS control of P-states from it via the SMI Command register exposed in the ACPI FADT. intel_pstate doesn't do that now, but acpi-cpufreq and other cpufreq drivers for x86 platforms do. Address this problem by making intel_pstate use the ACPI-defined mechanism as well. However, intel_pstate is not modular and it doesn't need the module refcount tricks played by acpi_processor_notify_smm(), so export the core of this function to it as acpi_processor_pstate_control() and make it call that. [The changes in processor_perflib.c related to this should not make any functional difference for the acpi_processor_notify_smm() users]. To be safe, only call acpi_processor_notify_smm() from intel_pstate if ACPI _PPC support is enabled in it. Suggested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
2016-11-17 22:47:47 +01:00
ACPI: processor: Get rid of ACPICA message printing The ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() macros are used for message printing in the ACPICA code and they should not be used elsewhere. Special configuration (either kernel command line or sysfs-based) is needed to see the messages printed by them and the format of those messages is also special and convoluted. For this reason, replace all of the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances in the ACPI processor driver with corresponding dev_*(), acpi_handle_*() and pr_*() calls depending on the context in which they appear. Also drop the ACPI_PROCESSOR_COMPONENT definition that is not going to be necessary any more. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
2021-02-22 19:59:13 +01:00
cpufreq: intel_pstate: Request P-states control from SMM if needed Currently, intel_pstate is unable to control P-states on my IvyBridge-based Acer Aspire S5, because they are controlled by SMM on that machine by default and it is necessary to request OS control of P-states from it via the SMI Command register exposed in the ACPI FADT. intel_pstate doesn't do that now, but acpi-cpufreq and other cpufreq drivers for x86 platforms do. Address this problem by making intel_pstate use the ACPI-defined mechanism as well. However, intel_pstate is not modular and it doesn't need the module refcount tricks played by acpi_processor_notify_smm(), so export the core of this function to it as acpi_processor_pstate_control() and make it call that. [The changes in processor_perflib.c related to this should not make any functional difference for the acpi_processor_notify_smm() users]. To be safe, only call acpi_processor_notify_smm() from intel_pstate if ACPI _PPC support is enabled in it. Suggested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
2016-11-17 22:47:47 +01:00
ACPI: processor: Get rid of ACPICA message printing The ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() macros are used for message printing in the ACPICA code and they should not be used elsewhere. Special configuration (either kernel command line or sysfs-based) is needed to see the messages printed by them and the format of those messages is also special and convoluted. For this reason, replace all of the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances in the ACPI processor driver with corresponding dev_*(), acpi_handle_*() and pr_*() calls depending on the context in which they appear. Also drop the ACPI_PROCESSOR_COMPONENT definition that is not going to be necessary any more. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
2021-02-22 19:59:13 +01:00
cpufreq: intel_pstate: Request P-states control from SMM if needed Currently, intel_pstate is unable to control P-states on my IvyBridge-based Acer Aspire S5, because they are controlled by SMM on that machine by default and it is necessary to request OS control of P-states from it via the SMI Command register exposed in the ACPI FADT. intel_pstate doesn't do that now, but acpi-cpufreq and other cpufreq drivers for x86 platforms do. Address this problem by making intel_pstate use the ACPI-defined mechanism as well. However, intel_pstate is not modular and it doesn't need the module refcount tricks played by acpi_processor_notify_smm(), so export the core of this function to it as acpi_processor_pstate_control() and make it call that. [The changes in processor_perflib.c related to this should not make any functional difference for the acpi_processor_notify_smm() users]. To be safe, only call acpi_processor_notify_smm() from intel_pstate if ACPI _PPC support is enabled in it. Suggested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
2016-11-17 22:47:47 +01:00
ACPI: processor: Remove initialization of static variable Address the following checkpatch error: ERROR: do not initialise statics to false Signed-off-by: Tian Tao <tiantao6@hisilicon.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-02-23 08:56:29 +08:00
ACPI: processor: perflib: Rearrange acpi_processor_notify_smm() Rearrange the code in acpi_processor_notify_smm() to consolidate error handling in it and improve the comments in there while at it. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:07:08 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier 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>
2019-08-28 14:20:13 +05:30
ACPI: delete tracing macros from drivers/acpi/*.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-27 00:41:40 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: delete tracing macros from drivers/acpi/*.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-27 00:41:40 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor: perflib: Rearrange acpi_processor_notify_smm() Rearrange the code in acpi_processor_notify_smm() to consolidate error handling in it and improve the comments in there while at it. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:07:08 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor: perflib: Rearrange acpi_processor_notify_smm() Rearrange the code in acpi_processor_notify_smm() to consolidate error handling in it and improve the comments in there while at it. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:07:08 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor: perflib: Rearrange acpi_processor_notify_smm() Rearrange the code in acpi_processor_notify_smm() to consolidate error handling in it and improve the comments in there while at it. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:07:08 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
cpufreq: intel_pstate: Request P-states control from SMM if needed Currently, intel_pstate is unable to control P-states on my IvyBridge-based Acer Aspire S5, because they are controlled by SMM on that machine by default and it is necessary to request OS control of P-states from it via the SMI Command register exposed in the ACPI FADT. intel_pstate doesn't do that now, but acpi-cpufreq and other cpufreq drivers for x86 platforms do. Address this problem by making intel_pstate use the ACPI-defined mechanism as well. However, intel_pstate is not modular and it doesn't need the module refcount tricks played by acpi_processor_notify_smm(), so export the core of this function to it as acpi_processor_pstate_control() and make it call that. [The changes in processor_perflib.c related to this should not make any functional difference for the acpi_processor_notify_smm() users]. To be safe, only call acpi_processor_notify_smm() from intel_pstate if ACPI _PPC support is enabled in it. Suggested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
2016-11-17 22:47:47 +01:00
ACPI: processor: perflib: Rearrange acpi_processor_notify_smm() Rearrange the code in acpi_processor_notify_smm() to consolidate error handling in it and improve the comments in there while at it. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:07:08 +01:00
ACPI: processor: perflib: Adjust acpi_processor_notify_smm() return value Avoid returning a confusing error code from acpi_processor_notify_smm() if it is called for the second time in the case when SMM notification regarding P-state control is not supported. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:08:00 +01:00
ACPI: processor: perflib: Rearrange acpi_processor_notify_smm() Rearrange the code in acpi_processor_notify_smm() to consolidate error handling in it and improve the comments in there while at it. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:07:08 +01:00
ACPI: processor: perflib: Adjust acpi_processor_notify_smm() return value Avoid returning a confusing error code from acpi_processor_notify_smm() if it is called for the second time in the case when SMM notification regarding P-state control is not supported. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:08:00 +01:00
ACPI: processor: perflib: Rearrange acpi_processor_notify_smm() Rearrange the code in acpi_processor_notify_smm() to consolidate error handling in it and improve the comments in there while at it. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:07:08 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor: perflib: Rearrange acpi_processor_notify_smm() Rearrange the code in acpi_processor_notify_smm() to consolidate error handling in it and improve the comments in there while at it. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:07:08 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor: perflib: Rearrange acpi_processor_notify_smm() Rearrange the code in acpi_processor_notify_smm() to consolidate error handling in it and improve the comments in there while at it. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:07:08 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:44:28 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
xen/acpi: upload _PSD info for non Dom0 CPUs too All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and changing only the acpi_id. For processors which P-state coordination type is HW_ALL (0xFD) it is OK to upload bogus P-state dependency information (_PSD), because Xen will ignore any cpufreq domains created for past CPUs. Albeit for platforms which expose coordination types as SW_ANY or SW_ALL, this will have some unintended side effects. Effectively, it will look at the P-state domain existence and *if it already exists* it will skip the acpi-cpufreq initialization and thus inherit the policy from the first CPU in the cpufreq domain. This will finally lead to the original cpu not changing target freq to P0 other than the first in the domain. Which will make turbo boost not getting enabled (e.g. for 'performance' governor) for all cpus. This patch fixes that, by also evaluating _PSD when we enumerate all ACPI processors and thus always uploading the correct info to Xen. We export acpi_processor_get_psd() for that this purpose, but change signature to not assume an existent of acpi_processor given that ACPI isn't creating an acpi_processor for non-dom0 CPUs. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2018-03-15 14:22:05 +00:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
xen/acpi: upload _PSD info for non Dom0 CPUs too All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and changing only the acpi_id. For processors which P-state coordination type is HW_ALL (0xFD) it is OK to upload bogus P-state dependency information (_PSD), because Xen will ignore any cpufreq domains created for past CPUs. Albeit for platforms which expose coordination types as SW_ANY or SW_ALL, this will have some unintended side effects. Effectively, it will look at the P-state domain existence and *if it already exists* it will skip the acpi-cpufreq initialization and thus inherit the policy from the first CPU in the cpufreq domain. This will finally lead to the original cpu not changing target freq to P0 other than the first in the domain. Which will make turbo boost not getting enabled (e.g. for 'performance' governor) for all cpus. This patch fixes that, by also evaluating _PSD when we enumerate all ACPI processors and thus always uploading the correct info to Xen. We export acpi_processor_get_psd() for that this purpose, but change signature to not assume an existent of acpi_processor given that ACPI isn't creating an acpi_processor for non-dom0 CPUs. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2018-03-15 14:22:05 +00:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: delete newly added debugging macros in processor_perflib.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-05-11 00:28:12 -04:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: Remove unnecessary from/to-void* and to-void casts in drivers/acpi Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Len Brown <len.brown@intel.com>
2006-10-01 00:28:50 +02:00
ACPI: processor: perflib: Drop redundant parentheses Drop some redundant parentheses and rearrange some checks using them in the ACPI processor performance library code for better code clarity. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:04:59 +01:00
ACPI: processor_perflib: Cleanup print messages The log messages in processor_perflib.c is not in consistency, we have some printk() calls with PREFIX, but some are not; we use pr_*() functions without prefix. So add pr_fmt() and unify them with pr_*() functions. While at it, fix some obvious coding style issues when going through the functions. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-02 16:54:32 +08:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: processor_perflib: Cleanup print messages The log messages in processor_perflib.c is not in consistency, we have some printk() calls with PREFIX, but some are not; we use pr_*() functions without prefix. So add pr_fmt() and unify them with pr_*() functions. While at it, fix some obvious coding style issues when going through the functions. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-02 16:54:32 +08:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: processor: perflib: Adjust white space Some inconsistent usage of white space in the ACPI processor performance library code causes that code to be somewhat harder to read that it would have been otherwise, so adjust the white space in there to address that. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:03:30 +01:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: processor_perflib: Cleanup print messages The log messages in processor_perflib.c is not in consistency, we have some printk() calls with PREFIX, but some are not; we use pr_*() functions without prefix. So add pr_fmt() and unify them with pr_*() functions. While at it, fix some obvious coding style issues when going through the functions. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-02 16:54:32 +08:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: processor_perflib: Cleanup print messages The log messages in processor_perflib.c is not in consistency, we have some printk() calls with PREFIX, but some are not; we use pr_*() functions without prefix. So add pr_fmt() and unify them with pr_*() functions. While at it, fix some obvious coding style issues when going through the functions. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-02 16:54:32 +08:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: processor_perflib: Cleanup print messages The log messages in processor_perflib.c is not in consistency, we have some printk() calls with PREFIX, but some are not; we use pr_*() functions without prefix. So add pr_fmt() and unify them with pr_*() functions. While at it, fix some obvious coding style issues when going through the functions. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-02 16:54:32 +08:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: Avoid wiping out pr->performance during preregistering When cpufreq driver call acpi_processor_preregister_performance() , function will clean up pr->performance even if there is possibly already registered other cpufreq driver. The patch fix this potential problem. It also remove double checks in P domain basic validity code and move these checks to function where _PSD data is captured. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-03-24 13:41:59 +01:00
ACPI: processor_perflib: Cleanup print messages The log messages in processor_perflib.c is not in consistency, we have some printk() calls with PREFIX, but some are not; we use pr_*() functions without prefix. So add pr_fmt() and unify them with pr_*() functions. While at it, fix some obvious coding style issues when going through the functions. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-02 16:54:32 +08:00
ACPI: Avoid wiping out pr->performance during preregistering When cpufreq driver call acpi_processor_preregister_performance() , function will clean up pr->performance even if there is possibly already registered other cpufreq driver. The patch fix this potential problem. It also remove double checks in P domain basic validity code and move these checks to function where _PSD data is captured. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-03-24 13:41:59 +01:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: delete acpi_os_free(), use kfree() directly Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-30 03:19:10 -04:00
ACPI: delete newly added debugging macros in processor_perflib.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-05-11 00:28:12 -04:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
xen/acpi: upload _PSD info for non Dom0 CPUs too All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and changing only the acpi_id. For processors which P-state coordination type is HW_ALL (0xFD) it is OK to upload bogus P-state dependency information (_PSD), because Xen will ignore any cpufreq domains created for past CPUs. Albeit for platforms which expose coordination types as SW_ANY or SW_ALL, this will have some unintended side effects. Effectively, it will look at the P-state domain existence and *if it already exists* it will skip the acpi-cpufreq initialization and thus inherit the policy from the first CPU in the cpufreq domain. This will finally lead to the original cpu not changing target freq to P0 other than the first in the domain. Which will make turbo boost not getting enabled (e.g. for 'performance' governor) for all cpus. This patch fixes that, by also evaluating _PSD when we enumerate all ACPI processors and thus always uploading the correct info to Xen. We export acpi_processor_get_psd() for that this purpose, but change signature to not assume an existent of acpi_processor given that ACPI isn't creating an acpi_processor for non-dom0 CPUs. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2018-03-15 14:22:05 +00:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
percpu: add __percpu sparse annotations to what's left Add __percpu sparse annotations to places which didn't make it in one of the previous patches. All converions are trivial. These annotations are to make sparse consider percpu variables to be in a different address space and warn if accessed without going through percpu accessors. This patch doesn't affect normal builds. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Borislav Petkov <borislav.petkov@amd.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Huang Ying <ying.huang@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: Neil Brown <neilb@suse.de>
2010-02-02 14:39:15 +09:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI / processor: Drop unused variable from processor_perflib.c The count variable in acpi_processor_preregister_performance() is only initalized as 1 for one CPU and incremented when another CPU sharing the same dependency domain is found. It isn't referenced anywhere else, so drop it. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-25 10:06:45 +08:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
cpumask: convert shared_cpu_map in acpi_processor* structs to cpumask_var_t Impact: Reduce memory usage, use new API. This is part of an effort to reduce structure sizes for machines configured with large NR_CPUS. cpumask_t gets replaced by cpumask_var_t, which is either struct cpumask[1] (small NR_CPUS) or struct cpumask * (large NR_CPUS). (Changes to powernow-k* by <travis>.) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-31 18:08:47 -08:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
cpumask: use zalloc_cpumask_var() where possible Remove open-coded zalloc_cpumask_var() and zalloc_cpumask_var_node(). Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2009-06-15 14:58:26 +08:00
cpumask: convert shared_cpu_map in acpi_processor* structs to cpumask_var_t Impact: Reduce memory usage, use new API. This is part of an effort to reduce structure sizes for machines configured with large NR_CPUS. cpumask_t gets replaced by cpumask_var_t, which is either struct cpumask[1] (small NR_CPUS) or struct cpumask * (large NR_CPUS). (Changes to powernow-k* by <travis>.) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-31 18:08:47 -08:00
ACPI: resolve merge conflict between sem2mutex and processor_perflib.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-15 22:19:31 -04:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: Avoid wiping out pr->performance during preregistering When cpufreq driver call acpi_processor_preregister_performance() , function will clean up pr->performance even if there is possibly already registered other cpufreq driver. The patch fix this potential problem. It also remove double checks in P domain basic validity code and move these checks to function where _PSD data is captured. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-03-24 13:41:59 +01:00
ACPI: use for_each_possible_cpu() instead of for_each_cpu() for_each_cpu() actually iterates across all possible CPUs. We've had mistakes in the past where people were using for_each_cpu() where they should have been iterating across only online or present CPUs. This is inefficient and possibly buggy. We're renaming for_each_cpu() to for_each_possible_cpu() to avoid this in the future. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-27 05:25:00 -04:00
ACPI: change processors from array to per_cpu variable Change processors from an array sized by NR_CPUS to a per_cpu variable. Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-09 16:22:23 -07:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: Avoid wiping out pr->performance during preregistering When cpufreq driver call acpi_processor_preregister_performance() , function will clean up pr->performance even if there is possibly already registered other cpufreq driver. The patch fix this potential problem. It also remove double checks in P domain basic validity code and move these checks to function where _PSD data is captured. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-03-24 13:41:59 +01:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
alloc_percpu: change percpu_ptr to per_cpu_ptr Impact: cleanup There are two allocated per-cpu accessor macros with almost identical spelling. The original and far more popular is per_cpu_ptr (44 files), so change over the other 4 files. tj: kill percpu_ptr() and update UP too Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: mingo@redhat.com Cc: lenb@kernel.org Cc: cpufreq@vger.kernel.org Signed-off-by: Tejun Heo <tj@kernel.org>
2009-02-20 16:29:08 +09:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: Avoid wiping out pr->performance during preregistering When cpufreq driver call acpi_processor_preregister_performance() , function will clean up pr->performance even if there is possibly already registered other cpufreq driver. The patch fix this potential problem. It also remove double checks in P domain basic validity code and move these checks to function where _PSD data is captured. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-03-24 13:41:59 +01:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: Avoid wiping out pr->performance during preregistering When cpufreq driver call acpi_processor_preregister_performance() , function will clean up pr->performance even if there is possibly already registered other cpufreq driver. The patch fix this potential problem. It also remove double checks in P domain basic validity code and move these checks to function where _PSD data is captured. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-03-24 13:41:59 +01:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
alloc_percpu: change percpu_ptr to per_cpu_ptr Impact: cleanup There are two allocated per-cpu accessor macros with almost identical spelling. The original and far more popular is per_cpu_ptr (44 files), so change over the other 4 files. tj: kill percpu_ptr() and update UP too Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: mingo@redhat.com Cc: lenb@kernel.org Cc: cpufreq@vger.kernel.org Signed-off-by: Tejun Heo <tj@kernel.org>
2009-02-20 16:29:08 +09:00
xen/acpi: upload _PSD info for non Dom0 CPUs too All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and changing only the acpi_id. For processors which P-state coordination type is HW_ALL (0xFD) it is OK to upload bogus P-state dependency information (_PSD), because Xen will ignore any cpufreq domains created for past CPUs. Albeit for platforms which expose coordination types as SW_ANY or SW_ALL, this will have some unintended side effects. Effectively, it will look at the P-state domain existence and *if it already exists* it will skip the acpi-cpufreq initialization and thus inherit the policy from the first CPU in the cpufreq domain. This will finally lead to the original cpu not changing target freq to P0 other than the first in the domain. Which will make turbo boost not getting enabled (e.g. for 'performance' governor) for all cpus. This patch fixes that, by also evaluating _PSD when we enumerate all ACPI processors and thus always uploading the correct info to Xen. We export acpi_processor_get_psd() for that this purpose, but change signature to not assume an existent of acpi_processor given that ACPI isn't creating an acpi_processor for non-dom0 CPUs. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2018-03-15 14:22:05 +00:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: Fix whitespace inconsistencies 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>
2020-11-05 03:06:00 +01:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: use for_each_possible_cpu() instead of for_each_cpu() for_each_cpu() actually iterates across all possible CPUs. We've had mistakes in the past where people were using for_each_cpu() where they should have been iterating across only online or present CPUs. This is inefficient and possibly buggy. We're renaming for_each_cpu() to for_each_possible_cpu() to avoid this in the future. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-27 05:25:00 -04:00
ACPI: change processors from array to per_cpu variable Change processors from an array sized by NR_CPUS to a per_cpu variable. Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-09 16:22:23 -07:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
cpumask: convert shared_cpu_map in acpi_processor* structs to cpumask_var_t Impact: Reduce memory usage, use new API. This is part of an effort to reduce structure sizes for machines configured with large NR_CPUS. cpumask_t gets replaced by cpumask_var_t, which is either struct cpumask[1] (small NR_CPUS) or struct cpumask * (large NR_CPUS). (Changes to powernow-k* by <travis>.) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-31 18:08:47 -08:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
cpumask: convert shared_cpu_map in acpi_processor* structs to cpumask_var_t Impact: Reduce memory usage, use new API. This is part of an effort to reduce structure sizes for machines configured with large NR_CPUS. cpumask_t gets replaced by cpumask_var_t, which is either struct cpumask[1] (small NR_CPUS) or struct cpumask * (large NR_CPUS). (Changes to powernow-k* by <travis>.) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-31 18:08:47 -08:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: HW P-state coordination support Treat HW coordination as independent CPUs. This enables per-cpu monintoring of P-states http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-26 00:34:43 -04:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: HW P-state coordination support Treat HW coordination as independent CPUs. This enables per-cpu monintoring of P-states http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-26 00:34:43 -04:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: use for_each_possible_cpu() instead of for_each_cpu() for_each_cpu() actually iterates across all possible CPUs. We've had mistakes in the past where people were using for_each_cpu() where they should have been iterating across only online or present CPUs. This is inefficient and possibly buggy. We're renaming for_each_cpu() to for_each_possible_cpu() to avoid this in the future. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-27 05:25:00 -04:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: change processors from array to per_cpu variable Change processors from an array sized by NR_CPUS to a per_cpu variable. Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-09 16:22:23 -07:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
cpumask: convert shared_cpu_map in acpi_processor* structs to cpumask_var_t Impact: Reduce memory usage, use new API. This is part of an effort to reduce structure sizes for machines configured with large NR_CPUS. cpumask_t gets replaced by cpumask_var_t, which is either struct cpumask[1] (small NR_CPUS) or struct cpumask * (large NR_CPUS). (Changes to powernow-k* by <travis>.) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-31 18:08:47 -08:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: use for_each_possible_cpu() instead of for_each_cpu() for_each_cpu() actually iterates across all possible CPUs. We've had mistakes in the past where people were using for_each_cpu() where they should have been iterating across only online or present CPUs. This is inefficient and possibly buggy. We're renaming for_each_cpu() to for_each_possible_cpu() to avoid this in the future. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-27 05:25:00 -04:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: change processors from array to per_cpu variable Change processors from an array sized by NR_CPUS to a per_cpu variable. Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-09 16:22:23 -07:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: Fix whitespace inconsistencies 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>
2020-11-05 03:06:00 +01:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
cpumask: convert shared_cpu_map in acpi_processor* structs to cpumask_var_t Impact: Reduce memory usage, use new API. This is part of an effort to reduce structure sizes for machines configured with large NR_CPUS. cpumask_t gets replaced by cpumask_var_t, which is either struct cpumask[1] (small NR_CPUS) or struct cpumask * (large NR_CPUS). (Changes to powernow-k* by <travis>.) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-31 18:08:47 -08:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: use for_each_possible_cpu() instead of for_each_cpu() for_each_cpu() actually iterates across all possible CPUs. We've had mistakes in the past where people were using for_each_cpu() where they should have been iterating across only online or present CPUs. This is inefficient and possibly buggy. We're renaming for_each_cpu() to for_each_possible_cpu() to avoid this in the future. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-27 05:25:00 -04:00
ACPI: change processors from array to per_cpu variable Change processors from an array sized by NR_CPUS to a per_cpu variable. Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-09 16:22:23 -07:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
cpumask: convert shared_cpu_map in acpi_processor* structs to cpumask_var_t Impact: Reduce memory usage, use new API. This is part of an effort to reduce structure sizes for machines configured with large NR_CPUS. cpumask_t gets replaced by cpumask_var_t, which is either struct cpumask[1] (small NR_CPUS) or struct cpumask * (large NR_CPUS). (Changes to powernow-k* by <travis>.) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-31 18:08:47 -08:00
ACPI: processor: fix NONE coordination for domain mapping failure 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-14 12:07:40 +00:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: Avoid wiping out pr->performance during preregistering When cpufreq driver call acpi_processor_preregister_performance() , function will clean up pr->performance even if there is possibly already registered other cpufreq driver. The patch fix this potential problem. It also remove double checks in P domain basic validity code and move these checks to function where _PSD data is captured. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-03-24 13:41:59 +01:00
ACPI: resolve merge conflict between sem2mutex and processor_perflib.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-15 22:19:31 -04:00
cpumask: convert shared_cpu_map in acpi_processor* structs to cpumask_var_t Impact: Reduce memory usage, use new API. This is part of an effort to reduce structure sizes for machines configured with large NR_CPUS. cpumask_t gets replaced by cpumask_var_t, which is either struct cpumask[1] (small NR_CPUS) or struct cpumask * (large NR_CPUS). (Changes to powernow-k* by <travis>.) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-31 18:08:47 -08:00
ACPI: delete newly added debugging macros in processor_perflib.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-05-11 00:28:12 -04:00
P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-12-14 15:05:00 -05:00
ACPI: processor: perflib: Adjust white space Some inconsistent usage of white space in the ACPI processor performance library code causes that code to be somewhat harder to read that it would have been otherwise, so adjust the white space in there to address that. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:03:30 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier 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>
2019-08-28 14:20:13 +05:30
ACPI: delete tracing macros from drivers/acpi/*.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-27 00:41:40 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
sem2mutex: drivers/acpi/processor_perflib.c Semaphore to mutex conversion. The conversion was generated via scripts, and the result was validated automatically via a script as well. Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-27 05:25:00 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: change processors from array to per_cpu variable Change processors from an array sized by NR_CPUS to a per_cpu variable. Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-09 16:22:23 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
sem2mutex: drivers/acpi/processor_perflib.c Semaphore to mutex conversion. The conversion was generated via scripts, and the result was validated automatically via a script as well. Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-27 05:25:00 -04:00
ACPI: delete tracing macros from drivers/acpi/*.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-27 00:41:40 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
sem2mutex: drivers/acpi/processor_perflib.c Semaphore to mutex conversion. The conversion was generated via scripts, and the result was validated automatically via a script as well. Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-27 05:25:00 -04:00
ACPI: delete tracing macros from drivers/acpi/*.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-27 00:41:40 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] powernow-k8 crash workaround From: Andrew Morton <akpm@osdl.org> Work around the oops reported in http://bugzilla.kernel.org/show_bug.cgi?id=6478. Thanks to Ralf Hildebrandt <ralf.hildebrandt@charite.de> for testing and reporting. Acked-by: Dave Jones <davej@codemonkey.org.uk> Cc: "Brown, Len" <len.brown@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-10 09:54:13 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
sem2mutex: drivers/acpi/processor_perflib.c Semaphore to mutex conversion. The conversion was generated via scripts, and the result was validated automatically via a script as well. Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-27 05:25:00 -04:00
ACPI: delete tracing macros from drivers/acpi/*.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-27 00:41:40 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
sem2mutex: drivers/acpi/processor_perflib.c Semaphore to mutex conversion. The conversion was generated via scripts, and the result was validated automatically via a script as well. Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-27 05:25:00 -04:00
ACPI: delete tracing macros from drivers/acpi/*.c Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-27 00:41:40 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI / processor: Drop an unused argument of a cleanup routine acpi_processor_unregister_performance() actually doesn't use its first argument, so drop it and update the callers accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
2015-07-22 22:11:16 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
sem2mutex: drivers/acpi/processor_perflib.c Semaphore to mutex conversion. The conversion was generated via scripts, and the result was validated automatically via a script as well. Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-27 05:25:00 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: change processors from array to per_cpu variable Change processors from an array sized by NR_CPUS to a per_cpu variable. Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-09 16:22:23 -07:00
ACPI: processor: perflib: Rearrange unregistration routine Rearrange acpi_processor_unregister_performance() to follow a more common error handling pattern and drop a redundant "return" statement from the end of it. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:05:55 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] powernow-k8 crash workaround From: Andrew Morton <akpm@osdl.org> Work around the oops reported in http://bugzilla.kernel.org/show_bug.cgi?id=6478. Thanks to Ralf Hildebrandt <ralf.hildebrandt@charite.de> for testing and reporting. Acked-by: Dave Jones <davej@codemonkey.org.uk> Cc: "Brown, Len" <len.brown@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-10 09:54:13 -07:00
ACPI: processor: perflib: Adjust white space Some inconsistent usage of white space in the ACPI processor performance library code causes that code to be somewhat harder to read that it would have been otherwise, so adjust the white space in there to address that. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:03:30 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor: perflib: Rearrange unregistration routine Rearrange acpi_processor_unregister_performance() to follow a more common error handling pattern and drop a redundant "return" statement from the end of it. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-05 20:05:55 +01:00
sem2mutex: drivers/acpi/processor_perflib.c Semaphore to mutex conversion. The conversion was generated via scripts, and the result was validated automatically via a script as well. Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-27 05:25:00 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ACPI: processor_perflib: extend X86 dependency The majority of the processor_perflib code is only used by cpufreq drivers on the x86 architecture and makes no sense without the x86 SMI interactions that rely on I/O port access. Replace the existing #ifdef checks with one that covers all of the code that is only used by x86 drivers, saving a little bit of kernel code size on other architectures. There is likely more code under CONFIG_ACPI_PROCESSOR that falls into this category, but changing those would require a larger rework. Suggested-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20241030123701.1538919-1-arnd@kernel.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-30 12:36:40 +00:00