08 Jul, 2015

1 commit


07 Dec, 2013

2 commits

  • Correct "coolign" to "cooling" and "*_ptg" to "*_pctg" as intended.

    This changes comment text only.

    Signed-off-by: Al Stone
    Signed-off-by: Rafael J. Wysocki

    Al Stone
     
  • Replace direct inclusions of , and
    , which are incorrect, with
    inclusions and remove some inclusions of those files that aren't
    necessary.

    First of all, , and
    should not be included directly from any files that are built for
    CONFIG_ACPI unset, because that generally leads to build warnings about
    undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set,
    includes those files and for CONFIG_ACPI unset it
    provides stub ACPI symbols to be used in that case.

    Second, there are ordering dependencies between those files that always
    have to be met. Namely, it is required that be included
    prior to so that the acpi_pci_root declarations the
    latter depends on are always there. And which provides
    basic ACPICA type declarations should always be included prior to any other
    ACPI headers in CONFIG_ACPI builds. That also is taken care of including
    as appropriate.

    Signed-off-by: Lv Zheng
    Cc: Greg Kroah-Hartman
    Cc: Matthew Garrett
    Cc: Tony Luck
    Cc: "H. Peter Anvin"
    Acked-by: Bjorn Helgaas (drivers/pci stuff)
    Acked-by: Konrad Rzeszutek Wilk (Xen stuff)
    Signed-off-by: Rafael J. Wysocki

    Lv Zheng
     

13 Aug, 2013

1 commit

  • acpi_processor_get_limit_info() is only called in the __acpi_processor_start()
    and what it does actually is just to check pr->flags.throttling and set limit.
    The pr pointer has been checked in the __acpi_processor_start() before
    acpi_processor_get_limit_info() being called. It doesn't make sense still to
    keep it as a function. So move code to __acpi_processor_start() and remove
    acpi_processor_get_limit_info().

    Signed-off-by: Lan Tianyu
    Acked-by: Zhang Rui
    Signed-off-by: Rafael J. Wysocki

    Lan Tianyu
     

26 Mar, 2013

1 commit

  • Fix a null pointer deference by acpi_driver_data() if device is
    null. We should only set pr and check this is OK after we are
    sure device is not null.

    Smatch analysis:

    drivers/acpi/processor_thermal.c:223 processor_get_max_state() warn:
    variable dereferenced before check 'device' (see line 221)
    drivers/acpi/processor_thermal.c:237 processor_get_cur_state() warn:
    variable dereferenced before check 'device' (see line 235)
    drivers/acpi/processor_thermal.c:255 processor_set_cur_state() warn:
    variable dereferenced before check 'device' (see line 251)

    Signed-off-by: Colin Ian King
    Signed-off-by: Rafael J. Wysocki

    Colin Ian King
     

22 Mar, 2012

1 commit

  • On Intel CPUs the processor typically uses the highest frequency
    set by any logical CPU. When the system overheats
    Linux first forces the frequency to the lowest available one
    to lower the temperature.

    However this was done only per logical CPU, which means all
    logical CPUs in a package would need to go through this before
    the frequency is actually lowered.

    Worse this delay actually prevents real throttling, because
    the real throttle code only proceeds when the lowest frequency
    is already reached.

    So when a throttle event happens force the lowest frequency
    for all CPUs in the package where it happened. The per CPU
    state is now kept per package, not per logical CPU. An alternative
    would be to do it per cpufreq unit, but since we want to bring
    down the temperature of the complete chip it's better
    to do it for all.

    In principle it may even make sense to do it for all CPUs,
    but I kept it on the package for now.

    With this change the frequency is actually lowered, which
    in terms also allows real throttling to proceed.

    I also removed an unnecessary per cpu variable initialization.

    v2: Fix package mapping

    Cc:
    Signed-off-by: Andi Kleen
    Signed-off-by: Len Brown

    Andi Kleen
     

22 Dec, 2011

1 commit

  • This moves the 'cpu sysdev_class' over to a regular 'cpu' subsystem
    and converts the devices to regular devices. The sysdev drivers are
    implemented as subsystem interfaces now.

    After all sysdev classes are ported to regular driver core entities, the
    sysdev implementation will be entirely removed from the kernel.

    Userspace relies on events and generic sysfs subsystem infrastructure
    from sysdev devices, which are made available with this conversion.

    Cc: Haavard Skinnemoen
    Cc: Hans-Christian Egtvedt
    Cc: Tony Luck
    Cc: Fenghua Yu
    Cc: Arnd Bergmann
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Martin Schwidefsky
    Cc: Heiko Carstens
    Cc: Paul Mundt
    Cc: "David S. Miller"
    Cc: Chris Metcalf
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "H. Peter Anvin"
    Cc: Borislav Petkov
    Cc: Tigran Aivazian
    Cc: Len Brown
    Cc: Zhang Rui
    Cc: Dave Jones
    Cc: Peter Zijlstra
    Cc: Russell King
    Cc: Andrew Morton
    Cc: Arjan van de Ven
    Cc: "Rafael J. Wysocki"
    Cc: "Srivatsa S. Bhat"
    Signed-off-by: Kay Sievers
    Signed-off-by: Greg Kroah-Hartman

    Kay Sievers
     

17 Jul, 2011

1 commit

  • Structs battery_file, acpi_dock_ops, file_operations,
    thermal_cooling_device_ops, thermal_zone_device_ops, kernel_param_ops
    are not changed in runtime. It is safe to make them const.
    register_hotplug_dock_device() was altered to take const "ops" argument
    to respect acpi_dock_ops' const notion.

    Signed-off-by: Vasiliy Kulikov
    Acked-by: Jeff Garzik
    Signed-off-by: Len Brown

    Vasiliy Kulikov
     

11 Dec, 2010

1 commit

  • When CONFIG_CPU_FREQ=n ...

    drivers/acpi/processor_thermal.c:159:12: warning: ‘acpi_thermal_cpufreq_increase’ defined but not used
    drivers/acpi/processor_thermal.c:163:12: warning: ‘acpi_thermal_cpufreq_decrease’ defined but not used

    Remove unused declaration of ‘acpi_thermal_cpufreq_increase’ and
    ‘acpi_thermal_cpufreq_decrease’

    Signed-off-by: Zhang Rui
    Signed-off-by: Len Brown

    Zhang Rui
     

20 Oct, 2010

2 commits


15 Aug, 2010

1 commit

  • Remove deprecated ACPI processor procfs I/F, including:
    /proc/acpi/processor/CPUX/power
    /proc/acpi/processor/CPUX/limit
    /proc/acpi/processor/CPUX/info

    /proc/acpi/processor/CPUX/throttling still exists,
    as we don't have sysfs I/F available for now.

    Signed-off-by: Zhang Rui
    Signed-off-by: Len Brown

    Zhang Rui
     

16 Jan, 2010

1 commit


19 Sep, 2009

1 commit


29 Aug, 2009

1 commit

  • Linux/ACPI core files using internal.h all PREFIX "ACPI: ",
    however, not all ACPI drivers use/want it -- and they
    should not have to #undef PREFIX to define their own.

    Add GPL commment to internal.h while we are there.

    This does not change any actual console output,
    asside from a whitespace fix.

    Signed-off-by: Len Brown

    Len Brown
     

27 Aug, 2009

1 commit

  • If the BIOS reports an invalid throttling state (which seems to be
    fairly common after system boot), a reset is done to state T0.
    Because of a check in acpi_processor_get_throttling_ptc(), the reset
    never actually gets executed, which results in the error reoccurring
    on every access of for example /proc/acpi/processor/CPU0/throttling.

    Add a 'force' option to acpi_processor_set_throttling() to ensure
    the reset really takes effect.

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

    This patch, together with the next one, fixes a regression introduced in
    2.6.30, listed on the regression list. They have been available for 2.5
    months now in bugzilla, but have not been picked up, despite various
    reminders and without any reason given.

    Google shows that numerous people are hitting this issue. The issue is in
    itself relatively minor, but the bug in the code is clear.

    The patches have been in all my kernels and today testing has shown that
    throttling works correctly with the patches applied when the system
    overheats (http://bugzilla.kernel.org/show_bug.cgi?id=13918#c14).

    Signed-off-by: Frans Pop
    Acked-by: Zhang Rui
    Cc: Len Brown
    Cc: "Rafael J. Wysocki"
    Cc: Rusty Russell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Frans Pop
     

24 Jun, 2009

1 commit


05 Apr, 2009

1 commit


04 Apr, 2009

1 commit


20 Feb, 2009

1 commit


08 Nov, 2008

1 commit


29 Apr, 2008

2 commits


02 Feb, 2008

1 commit

  • Register ACPI processor as thermal cooling devices.
    A combination of processor T-state and P-state are used for thermal throttling.
    the processor will reduce the frequency first and then set the T-state.

    we use cpufreq_thermal_reduction_pctg to calculate the cpufreq limit,
    and call cpufreq_verify_with_limit to set the cpufreq limit.
    if cpufreq driver is loaded, then we have four cooling state for cpufreq control.
    cooling state 0: cpufreq limit == max_freq
    cooling state 1: cpufreq limit == max_freq * 80%
    cooling state 2: cpufreq limit == max_freq * 60%
    cooling state 3: cpufreq limit == max_freq * 40%

    after the cpufreq limit is set to 40 percentage of the max_freq,
    we use T-state for cooling.

    eg. a processor has P-state support, and it has 8 T-state (T0-T7),
    the max_state of the proceesor is 10:

    state cpufreq-limit T-state
    0: max_freq T0
    1: max_freq * 80% T0
    2: max_freq * 60% T0
    3: max_freq * 40% T0
    4: max_freq * 40% T1
    5: max_freq * 40% T2
    6: max_freq * 40% T3
    7: max_freq * 40% T4
    8: max_freq * 40% T5
    9: max_freq * 40% T6
    10: max_freq * 40% T7

    Signed-off-by: Zhang Rui
    Signed-off-by: Zhao Yakui
    Signed-off-by: Thomas Sujith
    Signed-off-by: Len Brown

    Zhang Rui
     

13 Feb, 2007

2 commits


14 Oct, 2006

1 commit


27 Jun, 2006

3 commits


08 Jan, 2006

1 commit


07 Jan, 2006

1 commit


23 Dec, 2005

1 commit

  • Return logic was inverted.
    Going for changing the return value to not return zero as it is makes
    more sense regarding the naming of the function (cpu_has_cpufreq()).

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

    Signed-off-by: Thomas Renninger
    Signed-off-by: Len Brown

    Thomas Renninger
     

01 Dec, 2005

1 commit


05 Aug, 2005

1 commit


17 Apr, 2005

1 commit

  • 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