Commit:     e4233dec749a3519069d9390561b5636a75c7579
Parent:     1e9a51dca19dc1d8807c63cb3bd4413d3f95aaf5
Author:     Ingo Molnar <[EMAIL PROTECTED]>
AuthorDate: Fri Jan 26 00:56:55 2007 -0800
Committer:  Linus Torvalds <[EMAIL PROTECTED]>
CommitDate: Fri Jan 26 13:50:58 2007 -0800

    [PATCH] ACPI: fix cpufreq regression
    Recently cpufreq support on my laptop (Lenovo T60) broke completely: when
    it's plugged into AC it would never go higher than 1 GHz - neither 1.3 GHz
    nor 1.83 GHz is possible - no matter which governor (userspace, speed or
    ondemand) is used.
    After some cpufreq debugging i tracked the regression back to the following
    (totally correct) bug-fix commit:
       commit 0916bd3ebb7cefdd0f432e8491abe24f4b5a101e
       Author: Dave Jones <[EMAIL PROTECTED]>
       Date:   Wed Nov 22 20:42:01 2006 -0500
        [PATCH] Correct bound checking from the value returned from _PPC method.
    This bugfix, which makes other laptops work, made a previously hidden
    (BIOS) bug visible on my laptop.
    The bug is the following: if the _PPC (Performance Present Capabilities)
    optional ACPI object is queried /after/ bootup then the BIOS reports an
    incorrect value of '2'.
    My laptop (Lenovo T60) has the following performance states supported:
       0: 1833000
       1: 1333000
       2: 1000000
    Per ACPI specification, a _PPC value of '0' means that all 3 performance
    states are usable.  A _PPC value of '1' means states 1 ..  2 are usable, a
    value of '2' means only state '2' (slowest) is usable.
    now, the _PPC object is optional, and it also comes with notification.
    Furthermore, when a CPU object is initialized, the _PPC object is
    initialized as well.  So the following evaluation of the _PPC object is
     [<c028ba5f>] acpi_processor_get_platform_limit+0xa1/0xaf
     [<c028c040>] acpi_processor_register_performance+0x3b9/0x3ef
     [<c0111a85>] acpi_cpufreq_cpu_init+0xb7/0x596
     [<c03dab74>] cpufreq_add_dev+0x160/0x4a8
     [<c02bed90>] sysdev_driver_register+0x5a/0xa0
     [<c03d9c4c>] cpufreq_register_driver+0xb4/0x176
     [<c068ac08>] acpi_cpufreq_init+0xe5/0xeb
     [<c010056e>] init+0x14f/0x3dd
    And this is the point where my laptop's BIOS returns the incorrect value of
    '2'.  Note that it has not sent any notification event, so the value is
    probably not really intentional (possibly spurious), and Windows likely
    doesnt query it after bootup either.  Maybe the value is kept at '2'
    normally, and is only set to the real value when a true asynchronous event
    (such as AC plug event, battery switch, etc.) occurs.
    So i /think/ this is a grey area of the ACPI spec: per the letter of the
    spec the _PPC value only changes when notified, so there's no reason to
    query it after the system has booted up.  So in my opinion the best (and
    most compatible) strategy would be to do the change below, and to not
    evaluate the _PPC object in the acpi_processor_get_performance_info() call,
    but only evaluate it if _PPC is present during CPU object init, or if it's
    notified during an asynchronous event.  This change is more permissive than
    the previous logic, so it definitely shouldnt break any existing system.
    This also happens to fix my laptop, which is merrily chugging along at
    1.83 GHz now. Yay!
    Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
    Cc: Dave Jones <[EMAIL PROTECTED]>
    Acked-by: Len Brown <[EMAIL PROTECTED]>
    Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
    Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
 drivers/acpi/processor_perflib.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index 5207f9e..cbb6f08 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -322,10 +322,6 @@ static int acpi_processor_get_performance_info(struct 
acpi_processor *pr)
        if (result)
                return result;
-       result = acpi_processor_get_platform_limit(pr);
-       if (result)
-               return result;
        return 0;
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to