summaryrefslogtreecommitdiffstats
path: root/drivers/cpufreq/cpufreq_userspace.c
Commit message (Collapse)AuthorAgeFilesLines
* [CPUFREQ] Remove hotplug cpu crapDave Jones2007-02-111-2/+0Star
| | | | | | | | | The hotplug CPU locking in cpufreq is horrendous. No-one seems to care enough to fix it, so just remove it so that the 99.9% of the real world users of this code can use cpufreq without being bothered by warnings. Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] handle sysfs errorsJeff Garzik2006-10-211-2/+9
| | | | | | Signed-off-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Dave Jones <davej@redhat.com>
* [PATCH] Reorganize the cpufreq cpu hotplug locking to not be totally bizareArjan van de Ven2006-07-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch below moves the cpu hotplugging higher up in the cpufreq layering; this is needed to avoid recursive taking of the cpu hotplug lock and to otherwise detangle the mess. The new rules are: 1. you must do lock_cpu_hotplug() around the following functions: __cpufreq_driver_target __cpufreq_governor (for CPUFREQ_GOV_LIMITS operation only) __cpufreq_set_policy 2. governer methods (.governer) must NOT take the lock_cpu_hotplug() lock in any way; they are called with the lock taken already 3. if your governer spawns a thread that does things, like calling __cpufreq_driver_target, your thread must honor rule #1. 4. the policy lock and other cpufreq internal locks nest within the lock_cpu_hotplug() lock. I'm not entirely happy about how the __cpufreq_governor rule ended up (conditional locking rule depending on the argument) but basically all callers pass this as a constant so it's not too horrible. The patch also removes the cpufreq_governor() function since during the locking audit it turned out to be entirely unused (so no need to fix it) The patch works on my testbox, but it could use more testing (otoh... it can't be much worse than the current code) Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Remove obsolete #include <linux/config.h>Jörn Engel2006-06-301-1/+0Star
| | | | | Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
* [CPUFREQ] Lots of whitespace & CodingStyle cleanup.Dave Jones2006-02-281-6/+6
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Get rid of userspace policy struct, make userspace gov _PPC safe.Thomas Renninger2006-01-271-25/+28
| | | | | | | | | | | | | | | | Userspace governor need not to hold it's own cpufreq_policy, better make use of the global core policy. Also fixes a bug in case of frequency changes via _PPC. Old min/max values have wrongly been passed to __cpufreq_driver_target() (kind of buffered) and when max freq was available again, only the old max(normally lowest freq) was still active. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Dave Jones <davej@redhat.com> cpufreq_userspace.c | 53 +++++++++++++++++++++++++++------------------------- 1 files changed, 28 insertions(+), 25 deletions(-)
* [CPUFREQ] Convert drivers/cpufreq semaphores to mutexes.akpm@osdl.org2006-01-181-12/+13
| | | | | | | | | | | | 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: Dave Jones <davej@redhat.com>
* Linux-2.6.12-rc2Linus Torvalds2005-04-171-0/+207
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!