Eric Lee / smarc-fsl-linux-kernel

18 Aug, 2008

1 commit

15 Aug, 2008

1 commit

  • 9f497bcc6   ACPI: Fix thermal shutdowns ... Browse Code »

    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
    Signed-off-by: Andi Kleen

    Milan Broz
     

31 Jul, 2008

2 commits

17 Jul, 2008

1 commit

29 Apr, 2008

1 commit

  • cf7acfab0   acpi: use non-racy method for proc entries creation ... Browse Code »

    Use proc_create()/proc_create_data() to make sure that ->proc_fops and ->data
    be setup before gluing PDE to main tree.

    Add correct ->owner to proc_fops to fix reading/module unloading race.

    Signed-off-by: Denis V. Lunev
    Cc: Len Brown
    Cc: Alexey Dobriyan
    Cc: "Eric W. Biederman"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Denis V. Lunev
     

08 Feb, 2008

1 commit

02 Jan, 2008

1 commit

08 Aug, 2007

1 commit

  • 501092929   acpi-cpufreq: Fix some x86/x86-64 acpi-cpufreq driver issues ... Browse Code »

    This patch addresses some issues in x86/x86-64 acpi-cpufreq driver:

    1. Current memory allocation for acpi_perf_data is actually open-coded
    alloc_percpu(). The patch defines and handles acpi_perf_data as percpu
    data. The code will be cleaner and easier to be maintained with this
    change.

    2. Won't load driver in acpi_cpufreq_early_init() failure case.

    3. Add __init for acpi_cpufreq_early_init().

    Signed-off-by: Fenghua Yu
    Acked-by: Venkatesh Pallipadi
    Cc: Dave Jones
    Signed-off-by: Andrew Morton
    Signed-off-by: Len Brown

    Fenghua Yu
     

27 Apr, 2007

1 commit

13 Feb, 2007

2 commits

03 Feb, 2007

2 commits

27 Jan, 2007

1 commit

  • e4233dec7   [PATCH] ACPI: fix cpufreq regression ... Browse Code »

    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
    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
    superfluous:

    [] acpi_processor_get_platform_limit+0xa1/0xaf
    [] acpi_processor_register_performance+0x3b9/0x3ef
    [] acpi_cpufreq_cpu_init+0xb7/0x596
    [] cpufreq_add_dev+0x160/0x4a8
    [] sysdev_driver_register+0x5a/0xa0
    [] cpufreq_register_driver+0xb4/0x176
    [] acpi_cpufreq_init+0xe5/0xeb
    [] 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
    Cc: Dave Jones
    Acked-by: Len Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     

11 Jan, 2007

1 commit

16 Dec, 2006

1 commit

24 Nov, 2006

1 commit

  • 0916bd3eb   [PATCH] Correct bound checking from the value returned from _PPC method. ... Browse Code »

    processor_perflib.c::acpi_processor_ppc_notifier() check if the value
    returned by the processor's _PPC method is 0 and return failed if so.
    This is wrong since 0 indicate that the bios think the processor can go
    to the highest frequency. This patch for example fix the HP NX 6125 to
    allow its highest frequency to be available.

    Signed-off-by: Bruno Ducrot
    Cc: "Pallipadi, Venkatesh"
    Signed-off-by: Dave Jones
    Signed-off-by: Linus Torvalds

    Dave Jones
     

14 Oct, 2006

1 commit

30 Jun, 2006

1 commit

27 Jun, 2006

4 commits

26 Jun, 2006

1 commit

16 Jun, 2006

3 commits

11 Jun, 2006

1 commit

  • a913f5070   [PATCH] powernow-k8 crash workaround ... Browse Code »

    From: Andrew Morton

    Work around the oops reported in
    http://bugzilla.kernel.org/show_bug.cgi?id=6478.

    Thanks to Ralf Hildebrandt for testing and
    reporting.

    Acked-by: Dave Jones
    Cc: "Brown, Len"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

14 May, 2006

2 commits

  • 193de0c79   ACPI: use for_each_possible_cpu() instead of for_each_cpu() ... Browse Code »

    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
    Signed-off-by: Andrew Morton
    Signed-off-by: Len Brown

    KAMEZAWA Hiroyuki
     
  • 65c19bbd2   sem2mutex: drivers/acpi/processor_perflib.c ... Browse Code »

    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
    Signed-off-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Len Brown

    Arjan van de Ven
     

11 May, 2006

1 commit

09 Feb, 2006

1 commit

25 Jan, 2006

1 commit

07 Jan, 2006

1 commit

01 Dec, 2005

1 commit

  • 05131ecc9   [ACPI] Avoid BIOS inflicted crashes by evaluating _PDC only once ... Browse Code »

    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
    Signed-off-by: Len Brown

    Venkatesh Pallipadi
     

05 Aug, 2005

1 commit

12 Jul, 2005

1 commit

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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!

    Linus Torvalds