summaryrefslogtreecommitdiff
path: root/drivers/acpi/acpi_pad.c
AgeCommit message (Collapse)AuthorFilesLines
2013-03-25ACPI / acpi_pad: Used PTR_RETAlexandru Gheorghiu1-1/+1
Use PTR_RET instead of explicit checking with IS_ERR. Signed-off-by: Alexandru Gheorghiu <gheorghiuandru@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-26ACPI: Remove useless type argument of driver .remove() operationRafael J. Wysocki1-2/+1
The second argument of ACPI driver .remove() operation is only used by the ACPI processor driver and the value passed to that driver through it is always available from the given struct acpi_device object's removal_type field. For this reason, the second ACPI driver .remove() argument is in fact useless, so drop it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jiang Liu <jiang.liu@huawei.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2012-11-15ACPI: strict_strtoul() and printk() cleanup in acpi_padJosh1-4/+4
Replace a few calls to strict_strtoul() in acpi_pad.c with kstrtoul() and use pr_warn() instead of printk() in the same file. [rjw: Modified the subject and changelog.] Signed-off-by: Josh Taylor <joshua.taylor0@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-07-26Merge branches 'acpi_pad', 'acpica', 'apei-bugzilla-43282', 'battery', ↵Len Brown1-3/+4
'cpuidle-coupled', 'cpuidle-tweaks', 'intel_idle-ivb', 'ost', 'red-hat-bz-772730', 'thermal', 'thermal-spear' and 'turbostat-v2' into release
2012-07-14ACPI: acpi_pad: tune round_robin_timeLen Brown1-1/+1
In an effort to be fair to bound processes, acpi_pad periodically moves its forced-idle threads. The default interval for moving the threads is 10 seconds. Measurements show that reducing this to 1 second has no power or performance impact, so reduce default to 1 second. Signed-off-by: Len Brown <len.brown@intel.com>
2012-06-30acpi_pad: fix power_saving thread deadlockStuart Hayes1-3/+4
The acpi_pad driver can get stuck in destroy_power_saving_task() waiting for kthread_stop() to stop a power_saving thread. The problem is that the isolated_cpus_lock mutex is owned when destroy_power_saving_task() calls kthread_stop(), which waits for a power_saving thread to end, and the power_saving thread tries to acquire the isolated_cpus_lock when it calls round_robin_cpu(). This patch fixes the issue by making round_robin_cpu() use its own mutex. https://bugzilla.kernel.org/show_bug.cgi?id=42981 Cc: stable@vger.kernel.org Signed-off-by: Stuart Hayes <Stuart_Hayes@Dell.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-06-14ACPI: acpi_pad: rename "power_saving" thread to "acpi_pad" threadLen Brown1-1/+1
"acpi_pad/%d" is a better thread name than generic "power_saving/%d" because users who see these threads will know the name of the driver that caused them. Signed-off-by: Len Brown <len.brown@intel.com>
2011-03-23ACPI: minor printk format change in acpi_padNaga Chumbalkar1-1/+1
Minor format change. Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-03-23ACPI: make acpi_pad /sys output more readableNaga Chumbalkar1-4/+7
Make /sys output from acpi_pad more readable. Before the fix: # cat idlecpus idlepct rrtime 00000000510 After the fix: # cat idlecpus idlepct rrtime 00000000 5 10 Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-22Merge branch 'x86-idle-for-linus' of ↵Linus Torvalds1-6/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-idle-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86, hotplug: In the MWAIT case of play_dead, CLFLUSH the cache line x86, hotplug: Move WBINVD back outside the play_dead loop x86, hotplug: Use mwait to offline a processor, fix the legacy case x86, mwait: Move mwait constants to a common header file
2010-09-29ACPI: acpi_pad: simplify code to avoid false gcc build warningLen Brown1-16/+18
acpi_pad.c:432: warning: ‘num_cpus’ may be used uninitialized in this function gcc 4.4.4 was unable to notice that num_cpus is always set. Re-arrange the code to un-confuse gcc, and also make it easier for humans to read.... Signed-off-by: Len Brown <len.browns@intel.com>
2010-09-18x86, mwait: Move mwait constants to a common header fileH. Peter Anvin1-6/+1
We have MWAIT constants spread across three different .c files, for no good reason. Move them all into a common header file. Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Reviewed-by: Arjan van de Ven <arjan@linux.intel.com> Cc: Len Brown <lenb@kernel.org> LKML-Reference: <tip-*@git.kernel.org>
2010-07-27time: Kill off CONFIG_GENERIC_TIMEJohn Stultz1-1/+1
Now that all arches have been converted over to use generic time via clocksources or arch_gettimeoffset(), we can remove the GENERIC_TIME config option and simplify the generic code. Signed-off-by: John Stultz <johnstul@us.ibm.com> LKML-Reference: <1279068988-21864-4-git-send-email-johnstul@us.ibm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2010-06-04ACPI: acpi_pad: Don't needlessly mark LAPIC unstableChen Gong1-12/+24
As suggested in Venki's suggestion in the commit 0dc698b, add LAPIC unstable detection in the acpi_pad drvier too. Signed-off-by: Chen Gong <gong.chen@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-29Merge branch 'idle-release' of ↵Linus Torvalds1-9/+0
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-idle-2.6 * 'idle-release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-idle-2.6: intel_idle: native hardware cpuidle driver for latest Intel processors ACPI: acpi_idle: touch TS_POLLING only in the non-MWAIT case acpi_pad: uses MONITOR/MWAIT, so it doesn't need to clear TS_POLLING sched: clarify commment for TS_POLLING ACPI: allow a native cpuidle driver to displace ACPI cpuidle: make cpuidle_curr_driver static cpuidle: add cpuidle_unregister_driver() error check cpuidle: fail to register if !CONFIG_CPU_IDLE
2010-05-28ACPI: Don't let acpi_pad needlessly mark TSC unstableVenkatesh Pallipadi1-2/+11
acpi pad driver kind of aggressively marks TSC as unstable at init time, on mwait capable and non X86_FEATURE_NONSTOP_TSC systems. This is irrespective of whether pad driver is ever going to be used on the system or deep C-states are supported/used. This will affect every user who just happens to compile in (or get a kernel version which compiles in) acpi pad driver. Move mark_tsc_unstable() out of init to the actual idle invocation path of the pad driver. There is also another bug/missing_feature in the code that it does not support 'always running apic timer' and switches to broadcast mode unconditionally. Shaohua, can you take a look at that please. Signed-off-by: Venkatesh Pallipadi <venki@google.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-28acpi_pad: uses MONITOR/MWAIT, so it doesn't need to clear TS_POLLINGLen Brown1-9/+0
api_pad exclusively uses MONITOR/MWAIT to sleep in idle, so it does not need the wakeup IPI during idle sleep that is provoked by clearing TS_POLLING. Signed-off-by: Len Brown <len.brown@intel.com> Cc: Shaohua Li <shaohua.li@intel.com>
2010-05-06acpi_pad: "processor_aggregator" name too longDan Carpenter1-1/+1
cpi_device_class can only be 19 characters and a NULL terminator. With the current name we get a buffer overflow in acpi_pad_add() strcpy(acpi_device_class(device), ACPI_PROCESSOR_AGGREGATOR_CLASS); [akpm@linux-foundation.org: call it acpi_pad, per Shaohua Li] Signed-off-by: Dan Carpenter <error27@gmail.com> Cc: walter harms <wharms@bfs.de> Acked-by: Shaohua Li <shaohua.li@intel.com> Cc: Len Brown <lenb@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
2010-03-30include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo1-0/+1
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-01-20Merge branch 'acpi-pad' into releaseLen Brown1-17/+20
2009-12-31acpi_pad: fix error checksChen Gong1-17/+20
There are some fixes listed below: 1. When met a bogus BIOS, the return value of cpu number maybe is a negative value so that acpi_pad_pur get an unexpected result. 2. the return value of function acpi_pad_idle_cpus is useless. 3. enhance the process of create_power_saving_task/destroy_power_saving_task 4. Add more error checks when evaluating _PUR object. 5. one typo fix Signed-off-by: Chen Gong <gong.chen@linux.intel.com> Acked-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-16acpi_pad: squish warningAndrew Morton1-1/+2
drivers/acpi/acpi_pad.c: In function 'power_saving_thread': drivers/acpi/acpi_pad.c:103: warning: 'preferred_cpu' may be used uninitialized in this function Cc: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-01ACPI: create Processor Aggregator Device driverShaohua Li1-0/+514
ACPI 4.0 created the logical "processor aggregator device" as a mechinism for platforms to ask the OS to force otherwise busy processors to enter (power saving) idle. The intent is to lower power consumption to ride-out transient electrical and thermal emergencies, rather than powering off the server. On platforms that can save more power/performance via P-states, the platform will first exhaust P-states before forcing idle. However, the relative benefit of P-states vs. idle states is platform dependent, and thus this driver need not know or care about it. This driver does not use the kernel's CPU hot-plug mechanism because after the transient emergency is over, the system must be returned to its normal state, and hotplug would permanently break both cpusets and binding. So to force idle, the driver creates a power saving thread. The scheduler will migrate the thread to the preferred CPU. The thread has max priority and has SCHED_RR policy, so it can occupy one CPU. To save power, the thread will invoke the deep C-state entry instructions. To avoid starvation, the thread will sleep 5% of the time time for every second (current RT scheduler has threshold to avoid starvation, but if other CPUs are idle, the CPU can borrow CPU timer from other, which makes the mechanism not work here) Vaidyanathan Srinivasan has proposed scheduler enhancements to allow injecting idle time into the system. This driver doesn't depend on those enhancements, but could cut over to them when they are available. Peter Z. does not favor upstreaming this driver until the those scheduler enhancements are in place. However, we favor upstreaming this driver now because it is useful now, and can be enhanced over time. Signed-off-by: Shaohua Li <shaohua.li@intel.com> NACKed-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Signed-off-by: Len Brown <len.brown@intel.com>