History log of /linux/drivers/cpufreq/acpi-cpufreq.c (Results 1326 – 1334 of 1334)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 152bf8c5 11-Jan-2006 Andi Kleen <ak@suse.de>

[PATCH] x86_64: Use X86_FEATURE_CONSTANT_TSC now to clean up Intel speedstep drivers

They previously tried to figure this out on their own.

Suggested by Venkatesh.

Cc: venkatesh.pallipadi@intel.co

[PATCH] x86_64: Use X86_FEATURE_CONSTANT_TSC now to clean up Intel speedstep drivers

They previously tried to figure this out on their own.

Suggested by Venkatesh.

Cc: venkatesh.pallipadi@intel.com
Cc: davej@redhat.com
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

show more ...


# 35f652b5 06-Jan-2006 Benoit Boissinot <bboissin@gmail.com>

[ACPI] fix acpi_cpufreq.c build warrning

Signed-off-by: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>


Revision tags: v2.6.15-rc5, v2.6.15-rc4, v2.6.15-rc3, v2.6.15-rc2, v2.6.15-rc1, v2.6.14
# 05131ecc 23-Oct-2005 Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>

[ACPI] Avoid BIOS inflicted crashes by evaluating _PDC only once

Linux invokes the AML _PDC method (Processor Driver Capabilities)
to tell the BIOS what features it can handle. While the ACPI
spec

[ACPI] Avoid BIOS inflicted crashes by evaluating _PDC only once

Linux invokes the AML _PDC method (Processor Driver Capabilities)
to tell the BIOS what features it can handle. While the ACPI
spec says nothing about the OS invoking _PDC multiple times,
doing so with changing bits seems to hopelessly confuse the BIOS
on multiple platforms up to and including crashing the system.

Factor out the _PDC invocation so Linux invokes it only once.

http://bugzilla.kernel.org/show_bug.cgi?id=5483

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

show more ...


# dad2ad82 07-Nov-2005 Linus Torvalds <torvalds@g5.osdl.org>

Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreq


# 4e57b681 30-Oct-2005 Tim Schmielau <tim@physik3.uni-rostock.de>

[PATCH] fix missing includes

I recently picked up my older work to remove unnecessary #includes of
sched.h, starting from a patch by Dave Jones to not include sched.h
from module.h. This reduces the

[PATCH] fix missing includes

I recently picked up my older work to remove unnecessary #includes of
sched.h, starting from a patch by Dave Jones to not include sched.h
from module.h. This reduces the number of indirect includes of sched.h
by ~300. Another ~400 pointless direct includes can be removed after
this disentangling (patch to follow later).
However, quite a few indirect includes need to be fixed up for this.

In order to feed the patches through -mm with as little disturbance as
possible, I've split out the fixes I accumulated up to now (complete for
i386 and x86_64, more archs to follow later) and post them before the real
patch. This way this large part of the patch is kept simple with only
adding #includes, and all hunks are independent of each other. So if any
hunk rejects or gets in the way of other patches, just drop it. My scripts
will pick it up again in the next round.

Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

show more ...


# bfdc708d 20-Oct-2005 Dave Jones <davej@redhat.com>

[CPUFREQ] kzalloc conversions for i386 drivers.

Signed-off-by: Dave Jones <davej@redhat.com>


Revision tags: v2.6.14-rc5, v2.6.14-rc4, v2.6.14-rc3, v2.6.14-rc2, v2.6.14-rc1, v2.6.13
# d395bf12 25-Aug-2005 Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>

[ACPI] Reduce acpi-cpufreq switching latency by 50%

The acpi-cpufreq driver does a P-state get after a P-state set
to verify whether set went through successfully. This test
is kind of redundant as

[ACPI] Reduce acpi-cpufreq switching latency by 50%

The acpi-cpufreq driver does a P-state get after a P-state set
to verify whether set went through successfully. This test
is kind of redundant as set goes throught most of the times,
and the test is also expensive as a get of P-states can
take a lot of time (same as a set operation) as it goes
through SMM mode. Effectively, we are doubling the P-state
latency due to this get opertion.

momdule parameter "acpi_pstate_strict" restores orginal paranoia.

http://bugzilla.kernel.org/show_bug.cgi?id=5129

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

show more ...


Revision tags: v2.6.13-rc7, v2.6.13-rc6, v2.6.13-rc5, v2.6.13-rc4, v2.6.13-rc3, v2.6.13-rc2, v2.6.13-rc1, v2.6.12, v2.6.12-rc6, v2.6.12-rc5
# 4b31e774 18-May-2005 Dominik Brodowski <linux@dominikbrodowski.net>

[ACPI] Always set P-state on initialization

Otherwise a platform that supports ACPI based cpufreq
and boots up at lowest possible speed could stay there
forever. This because the governor may reque

[ACPI] Always set P-state on initialization

Otherwise a platform that supports ACPI based cpufreq
and boots up at lowest possible speed could stay there
forever. This because the governor may request max speed,
but the code doesn't update if there is no change in
speed, and it assumed the initial state of max speed.

http://bugzilla.kernel.org/show_bug.cgi?id=4634

Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

show more ...


Revision tags: v2.6.12-rc4, v2.6.12-rc3, v2.6.12-rc2
# 1da177e4 16-Apr-2005 Linus Torvalds <torvalds@ppc970.osdl.org>

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

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!

show more ...


1...<<51525354