Aren/NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
2562de9c62
NetBSD/sys/dev/acpi/acpi_cpu.c

848 lines
18 KiB
C
Raw Normal View History

Simplify by moving the debug printfs to one place. No functional change.
2011-03-01 08:32:03 +03:00
/* $NetBSD: acpi_cpu.c,v 1.32 2011/03/01 05:32:03 jruoho Exp $ */
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
/*-
Rename couple of badly named functions for consistency. No functional change.
2011-02-25 15:08:35 +03:00
* Copyright (c) 2010, 2011 Jukka Ruohonen <jruohonen@iki.fi>
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
#include <sys/cdefs.h>
Simplify by moving the debug printfs to one place. No functional change.
2011-03-01 08:32:03 +03:00
__KERNEL_RCSID(0, "$NetBSD: acpi_cpu.c,v 1.32 2011/03/01 05:32:03 jruoho Exp $");
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
#include <sys/param.h>
#include <sys/cpu.h>
#include <sys/kernel.h>
#include <sys/kmem.h>
#include <sys/module.h>
On second thought, rename the mutex so it can be (logically) shared. We will not need such granularity that different states would require a different lock.
2010-07-30 10:11:14 +04:00
#include <sys/mutex.h>
Change the default behavior to enforce the maximum frequency when the firmware requests to do so. This cures severe overhating (> 120 C) observed on many laptops, being also on par with the specification(s). This can be reverted by using the new "hw.acpi.cpu.dynamic" sysctl variable.
2010-12-30 15:05:02 +03:00
#include <sys/sysctl.h>
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
#include <dev/acpi/acpireg.h>
#include <dev/acpi/acpivar.h>
#include <dev/acpi/acpi_cpu.h>
#include <machine/acpi_machdep.h>
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
#include <machine/cpuvar.h>
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
#define _COMPONENT ACPI_BUS_COMPONENT
ACPI_MODULE_NAME ("acpi_cpu")
static int acpicpu_match(device_t, cfdata_t, void *);
static void acpicpu_attach(device_t, device_t, void *);
static int acpicpu_detach(device_t, int);
static int acpicpu_once_attach(void);
static int acpicpu_once_detach(void);
Now that the deferred configuration actually works as expected and documented, use config_defer(9) instead of config_finalize_register(9), and simplify the code paths around the initialization.
2010-08-16 21:58:42 +04:00
static void acpicpu_start(device_t);
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
static void acpicpu_debug_print(device_t);
Simplify by moving the debug printfs to one place. No functional change.
2011-03-01 08:32:03 +03:00
static const char *acpicpu_debug_print_method(uint8_t);
Start to derive the percpu(9) (or per-domain) state coordination mechanisms by parsing the _CSD, _PSD, and _TSD objects by default.
2011-02-25 22:55:06 +03:00
static const char *acpicpu_debug_print_dep(uint32_t);
Change the default behavior to enforce the maximum frequency when the firmware requests to do so. This cures severe overhating (> 120 C) observed on many laptops, being also on par with the specification(s). This can be reverted by using the new "hw.acpi.cpu.dynamic" sysctl variable.
2010-12-30 15:05:02 +03:00
static void acpicpu_sysctl(device_t);
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
static ACPI_STATUS acpicpu_object(ACPI_HANDLE, struct acpicpu_object *);
static int acpicpu_find(struct cpu_info *,
struct acpi_devnode **);
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
static uint32_t acpicpu_cap(struct acpicpu_softc *);
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
static ACPI_STATUS acpicpu_cap_pdc(struct acpicpu_softc *, uint32_t);
static ACPI_STATUS acpicpu_cap_osc(struct acpicpu_softc *,
uint32_t, uint32_t *);
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
static void acpicpu_notify(ACPI_HANDLE, uint32_t, void *);
static bool acpicpu_suspend(device_t, const pmf_qual_t *);
static bool acpicpu_resume(device_t, const pmf_qual_t *);
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
static uint32_t acpicpu_count = 0;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
struct acpicpu_softc **acpicpu_sc = NULL;
Change the default behavior to enforce the maximum frequency when the firmware requests to do so. This cures severe overhating (> 120 C) observed on many laptops, being also on par with the specification(s). This can be reverted by using the new "hw.acpi.cpu.dynamic" sysctl variable.
2010-12-30 15:05:02 +03:00
static struct sysctllog *acpicpu_log = NULL;
static bool acpicpu_dynamic = true;
static bool acpicpu_passive = true;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
static const char * const acpicpu_hid[] = {
"ACPI0007",
NULL
};
CFATTACH_DECL_NEW(acpicpu, sizeof(struct acpicpu_softc),
acpicpu_match, acpicpu_attach, acpicpu_detach, NULL);
static int
acpicpu_match(device_t parent, cfdata_t match, void *aux)
{
Provide MD wrappers for match and attach.
2011-02-27 21:32:53 +03:00
struct cpu_info *ci;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
if (acpi_softc == NULL)
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
return 0;
Provide MD wrappers for match and attach.
2011-02-27 21:32:53 +03:00
ci = acpicpu_md_match(parent, match, aux);
if (ci == NULL)
XXX: If this is not correct, revert or fix. This makes my laptop boot instead of panic: panic: kernel diagnostic assertion "native_idle != NULL" failed: file "../../../../arch/x86/acpi/acpi_cpu_md.c", line 155 fatal breakpoint trap in supervisor mode type 1 code 0 rip ffffffff8022e4ad cs 8 rflags 246 cr2 0 cpl 0 rsp ffff80004c37db10 trace breakpoint() at netbsd:breakpoint+0x5 panic() at netbsd:panic+0x2ba kern_assert() at netbsd:kern_assert+0x2d acpicpu_md_idle_stop() at netbsd:acpicpu_md_idle_stop+0x62 acpicpu_cstate_callback() at netbsd:acpicpu_cstate_callback+0x34 sysmon_task_queue_thread() at netbsd:sysmon_task_queue_thread+0x41 1. ACPI seems to define cpuids 1..n; we define 0..n-1. Adjust for that 2. My laptop is dual core, but ACPI reports 4 cpu nodes. Instead of attaching the unmatched ones, make the match fail. Do we want to attach and do nothing instead? 3. Create a flag, and only set it after we are completely initialized, so the sysmon thread does not try to access unitialized state.
2010-07-19 04:59:32 +04:00
return 0;
Remove the recently added ACPICPU_FLAG_INIT and instead operate with the existing ACPICPU_FLAG_C, as was intended. Set that flag only after the idle-loop has been installed, so that the notify handler errors out if an interrupt is received before the idle-loop is in place.
2010-07-23 09:32:02 +04:00
Provide MD wrappers for match and attach.
2011-02-27 21:32:53 +03:00
return acpicpu_find(ci, NULL);
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
}
static void
acpicpu_attach(device_t parent, device_t self, void *aux)
{
struct acpicpu_softc *sc = device_private(self);
Provide MD wrappers for match and attach.
2011-02-27 21:32:53 +03:00
struct cpu_info *ci;
Store a pointer to cpu_info rather than cpu_info::ci_acpiid alone.
2011-02-25 09:18:02 +03:00
cpuid_t id;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
int rv;
Provide MD wrappers for match and attach.
2011-02-27 21:32:53 +03:00
ci = acpicpu_md_attach(parent, self, aux);
if (ci == NULL)
return;
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
sc->sc_ci = ci;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
sc->sc_dev = self;
Now that the deferred configuration actually works as expected and documented, use config_defer(9) instead of config_finalize_register(9), and simplify the code paths around the initialization.
2010-08-16 21:58:42 +04:00
sc->sc_cold = true;
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
sc->sc_node = NULL;
rv = acpicpu_find(ci, &sc->sc_node);
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
if (rv == 0) {
aprint_normal(": failed to match processor\n");
return;
}
Store a pointer to cpu_info rather than cpu_info::ci_acpiid alone.
2011-02-25 09:18:02 +03:00
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
if (acpicpu_once_attach() != 0) {
aprint_normal(": failed to initialize\n");
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
return;
}
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
KASSERT(acpi_softc != NULL);
KASSERT(acpicpu_sc != NULL);
KASSERT(sc->sc_node != NULL);
Store a pointer to cpu_info rather than cpu_info::ci_acpiid alone.
2011-02-25 09:18:02 +03:00
id = sc->sc_ci->ci_acpiid;
if (acpicpu_sc[id] != NULL) {
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
aprint_normal(": already attached\n");
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
return;
}
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
aprint_naive("\n");
aprint_normal(": ACPI CPU\n");
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
rv = acpicpu_object(sc->sc_node->ad_handle, &sc->sc_object);
if (ACPI_FAILURE(rv))
aprint_verbose_dev(self, "failed to obtain CPU object\n");
acpicpu_count++;
Store a pointer to cpu_info rather than cpu_info::ci_acpiid alone.
2011-02-25 09:18:02 +03:00
acpicpu_sc[id] = sc;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
sc->sc_cap = acpicpu_cap(sc);
Start to derive the percpu(9) (or per-domain) state coordination mechanisms by parsing the _CSD, _PSD, and _TSD objects by default.
2011-02-25 22:55:06 +03:00
sc->sc_ncpus = acpi_md_ncpus();
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
sc->sc_flags = acpicpu_md_flags();
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
KASSERT(acpicpu_count <= sc->sc_ncpus);
KASSERT(sc->sc_node->ad_device == NULL);
sc->sc_node->ad_device = self;
On second thought, rename the mutex so it can be (logically) shared. We will not need such granularity that different states would require a different lock.
2010-07-30 10:11:14 +04:00
mutex_init(&sc->sc_mtx, MUTEX_DEFAULT, IPL_NONE);
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
acpicpu_cstate_attach(self);
Merge P-state support for acpicpu(4). Remarks: 1. All processors (x86 or not) for which the vendor has implemented ACPI I/O access routines are supported. Native instructions are currently supported only for Intel's "Enhanced Speedstep". Code for "PowerNow!" (AMD) will be merged later. Native support for VIA's "PowerSaver" will be investigated. 2. Backwards compatibility with existing userland code is maintained. Comparable to the case with cpu_idle(9), the ACPI CPU driver installs alternative functions for the existing sysctl(8) controls. The "native" behavior (if any) is restored upon detachment. 3. The dynamic nature of ACPI-provided P-states needs more investigation. The maximum frequency induced (but not forced) by the firmware may change dynamically. Currently, the sysctl(8) controls error out with a value larger than the dynamic maximum. The code itself does not however yet react to the notifications from the firmware by changing the frequencies in-place. Presumably the system administrator should be able to choose whether to use dynamic or static frequencies.
2010-08-08 20:58:41 +04:00
acpicpu_pstate_attach(self);
Merge T-state a.k.a. throttling support for acpicpu(4). Remarks: 1. Native instructions are supported only on Intel. Native support for other x86 vendors will be investigated. By assumption, AMD and others use the I/O based approach. 2. The existing code, INTEL_ONDEMAND_CLOCKMOD, must be disabled in order to use acpicpu(4). Otherwise fatal MSR races may occur. Unlike with P-states, no attempt is done to disable the existing implementation. 3. There is no rationale to export controls to user land. 4. Throttling is an artefact from the past. T-states will not be used for power management per se. For CPU frequency management, P-states are preferred in all circumstances. No noticeable additional power savings were observed in various experiments. When the system has been scaled to the highest (i.e. lowest power) P-state, it is preferable to move from C0 to deeper C-states than it is to actively throttle the CPU. 5. But T-states need to be implemented for passive cooling via acpitz(4). As specified by ACPI and Intel documents, these can be used as the last line of defence against critical thermal conditions. Support for this will be added later.
2010-08-13 20:21:50 +04:00
acpicpu_tstate_attach(self);
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
acpicpu_debug_print(self);
(void)config_interrupts(self, acpicpu_start);
Merge P-state support for acpicpu(4). Remarks: 1. All processors (x86 or not) for which the vendor has implemented ACPI I/O access routines are supported. Native instructions are currently supported only for Intel's "Enhanced Speedstep". Code for "PowerNow!" (AMD) will be merged later. Native support for VIA's "PowerSaver" will be investigated. 2. Backwards compatibility with existing userland code is maintained. Comparable to the case with cpu_idle(9), the ACPI CPU driver installs alternative functions for the existing sysctl(8) controls. The "native" behavior (if any) is restored upon detachment. 3. The dynamic nature of ACPI-provided P-states needs more investigation. The maximum frequency induced (but not forced) by the firmware may change dynamically. Currently, the sysctl(8) controls error out with a value larger than the dynamic maximum. The code itself does not however yet react to the notifications from the firmware by changing the frequencies in-place. Presumably the system administrator should be able to choose whether to use dynamic or static frequencies.
2010-08-08 20:58:41 +04:00
(void)acpi_register_notify(sc->sc_node, acpicpu_notify);
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
(void)pmf_device_register(self, acpicpu_suspend, acpicpu_resume);
}
static int
acpicpu_detach(device_t self, int flags)
{
struct acpicpu_softc *sc = device_private(self);
int rv = 0;
Check the 'sc->sc_cold' flag also in P-state code, and set this flag once we start the detachment routine.
2010-08-11 20:22:18 +04:00
sc->sc_cold = true;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
acpi_deregister_notify(sc->sc_node);
if ((sc->sc_flags & ACPICPU_FLAG_C) != 0)
rv = acpicpu_cstate_detach(self);
if (rv != 0)
return rv;
Merge P-state support for acpicpu(4). Remarks: 1. All processors (x86 or not) for which the vendor has implemented ACPI I/O access routines are supported. Native instructions are currently supported only for Intel's "Enhanced Speedstep". Code for "PowerNow!" (AMD) will be merged later. Native support for VIA's "PowerSaver" will be investigated. 2. Backwards compatibility with existing userland code is maintained. Comparable to the case with cpu_idle(9), the ACPI CPU driver installs alternative functions for the existing sysctl(8) controls. The "native" behavior (if any) is restored upon detachment. 3. The dynamic nature of ACPI-provided P-states needs more investigation. The maximum frequency induced (but not forced) by the firmware may change dynamically. Currently, the sysctl(8) controls error out with a value larger than the dynamic maximum. The code itself does not however yet react to the notifications from the firmware by changing the frequencies in-place. Presumably the system administrator should be able to choose whether to use dynamic or static frequencies.
2010-08-08 20:58:41 +04:00
if ((sc->sc_flags & ACPICPU_FLAG_P) != 0)
rv = acpicpu_pstate_detach(self);
if (rv != 0)
return rv;
Merge T-state a.k.a. throttling support for acpicpu(4). Remarks: 1. Native instructions are supported only on Intel. Native support for other x86 vendors will be investigated. By assumption, AMD and others use the I/O based approach. 2. The existing code, INTEL_ONDEMAND_CLOCKMOD, must be disabled in order to use acpicpu(4). Otherwise fatal MSR races may occur. Unlike with P-states, no attempt is done to disable the existing implementation. 3. There is no rationale to export controls to user land. 4. Throttling is an artefact from the past. T-states will not be used for power management per se. For CPU frequency management, P-states are preferred in all circumstances. No noticeable additional power savings were observed in various experiments. When the system has been scaled to the highest (i.e. lowest power) P-state, it is preferable to move from C0 to deeper C-states than it is to actively throttle the CPU. 5. But T-states need to be implemented for passive cooling via acpitz(4). As specified by ACPI and Intel documents, these can be used as the last line of defence against critical thermal conditions. Support for this will be added later.
2010-08-13 20:21:50 +04:00
if ((sc->sc_flags & ACPICPU_FLAG_T) != 0)
rv = acpicpu_tstate_detach(self);
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
if (rv != 0)
return rv;
On second thought, rename the mutex so it can be (logically) shared. We will not need such granularity that different states would require a different lock.
2010-07-30 10:11:14 +04:00
mutex_destroy(&sc->sc_mtx);
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
sc->sc_node->ad_device = NULL;
acpicpu_count--;
acpicpu_once_detach();
On second thought, rename the mutex so it can be (logically) shared. We will not need such granularity that different states would require a different lock.
2010-07-30 10:11:14 +04:00
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
return 0;
}
static int
acpicpu_once_attach(void)
{
struct acpicpu_softc *sc;
unsigned int i;
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
if (acpicpu_count != 0)
return 0;
KASSERT(acpicpu_sc == NULL);
KASSERT(acpicpu_log == NULL);
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
acpicpu_sc = kmem_zalloc(maxcpus * sizeof(*sc), KM_SLEEP);
if (acpicpu_sc == NULL)
return ENOMEM;
for (i = 0; i < maxcpus; i++)
acpicpu_sc[i] = NULL;
return 0;
}
static int
acpicpu_once_detach(void)
{
struct acpicpu_softc *sc;
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
if (acpicpu_count != 0)
return EDEADLK;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
Change the default behavior to enforce the maximum frequency when the firmware requests to do so. This cures severe overhating (> 120 C) observed on many laptops, being also on par with the specification(s). This can be reverted by using the new "hw.acpi.cpu.dynamic" sysctl variable.
2010-12-30 15:05:02 +03:00
if (acpicpu_log != NULL)
sysctl_teardown(&acpicpu_log);
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
if (acpicpu_sc != NULL)
kmem_free(acpicpu_sc, maxcpus * sizeof(*sc));
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
return 0;
}
Now that the deferred configuration actually works as expected and documented, use config_defer(9) instead of config_finalize_register(9), and simplify the code paths around the initialization.
2010-08-16 21:58:42 +04:00
static void
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
acpicpu_start(device_t self)
Now that the deferred configuration actually works as expected and documented, use config_defer(9) instead of config_finalize_register(9), and simplify the code paths around the initialization.
2010-08-16 21:58:42 +04:00
{
struct acpicpu_softc *sc = device_private(self);
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
static uint32_t count = 0;
Now that the deferred configuration actually works as expected and documented, use config_defer(9) instead of config_finalize_register(9), and simplify the code paths around the initialization.
2010-08-16 21:58:42 +04:00
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
/*
* Run the state-specific initialization routines. These
* must run only once, after interrupts have been enabled,
* all CPUs are running, and all ACPI CPUs have attached.
*/
if (++count != acpicpu_count || acpicpu_count != sc->sc_ncpus) {
Now that the deferred configuration actually works as expected and documented, use config_defer(9) instead of config_finalize_register(9), and simplify the code paths around the initialization.
2010-08-16 21:58:42 +04:00
sc->sc_cold = false;
return;
}
/*
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
* Set the last ACPI CPU as non-cold
* only after C-states are enabled.
Now that the deferred configuration actually works as expected and documented, use config_defer(9) instead of config_finalize_register(9), and simplify the code paths around the initialization.
2010-08-16 21:58:42 +04:00
*/
if ((sc->sc_flags & ACPICPU_FLAG_C) != 0)
acpicpu_cstate_start(self);
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
sc->sc_cold = false;
Now that the deferred configuration actually works as expected and documented, use config_defer(9) instead of config_finalize_register(9), and simplify the code paths around the initialization.
2010-08-16 21:58:42 +04:00
if ((sc->sc_flags & ACPICPU_FLAG_P) != 0)
acpicpu_pstate_start(self);
if ((sc->sc_flags & ACPICPU_FLAG_T) != 0)
acpicpu_tstate_start(self);
Change the default behavior to enforce the maximum frequency when the firmware requests to do so. This cures severe overhating (> 120 C) observed on many laptops, being also on par with the specification(s). This can be reverted by using the new "hw.acpi.cpu.dynamic" sysctl variable.
2010-12-30 15:05:02 +03:00
acpicpu_sysctl(self);
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
aprint_debug_dev(self, "ACPI CPUs started\n");
Now that the deferred configuration actually works as expected and documented, use config_defer(9) instead of config_finalize_register(9), and simplify the code paths around the initialization.
2010-08-16 21:58:42 +04:00
}
Change the default behavior to enforce the maximum frequency when the firmware requests to do so. This cures severe overhating (> 120 C) observed on many laptops, being also on par with the specification(s). This can be reverted by using the new "hw.acpi.cpu.dynamic" sysctl variable.
2010-12-30 15:05:02 +03:00
static void
acpicpu_sysctl(device_t self)
{
const struct sysctlnode *node;
int err;
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
KASSERT(acpicpu_log == NULL);
Change the default behavior to enforce the maximum frequency when the firmware requests to do so. This cures severe overhating (> 120 C) observed on many laptops, being also on par with the specification(s). This can be reverted by using the new "hw.acpi.cpu.dynamic" sysctl variable.
2010-12-30 15:05:02 +03:00
err = sysctl_createv(&acpicpu_log, 0, NULL, &node,
CTLFLAG_PERMANENT, CTLTYPE_NODE, "hw", NULL,
NULL, 0, NULL, 0, CTL_HW, CTL_EOL);
if (err != 0)
goto fail;
err = sysctl_createv(&acpicpu_log, 0, &node, &node,
CTLFLAG_PERMANENT, CTLTYPE_NODE, "acpi", NULL,
NULL, 0, NULL, 0, CTL_CREATE, CTL_EOL);
if (err != 0)
goto fail;
err = sysctl_createv(&acpicpu_log, 0, &node, &node,
0, CTLTYPE_NODE, "cpu", SYSCTL_DESCR("ACPI CPU"),
NULL, 0, NULL, 0, CTL_CREATE, CTL_EOL);
if (err != 0)
goto fail;
err = sysctl_createv(&acpicpu_log, 0, &node, NULL,
CTLFLAG_READWRITE, CTLTYPE_BOOL, "dynamic",
SYSCTL_DESCR("Dynamic states"), NULL, 0,
&acpicpu_dynamic, 0, CTL_CREATE, CTL_EOL);
if (err != 0)
goto fail;
err = sysctl_createv(&acpicpu_log, 0, &node, NULL,
CTLFLAG_READWRITE, CTLTYPE_BOOL, "passive",
SYSCTL_DESCR("Passive cooling"), NULL, 0,
&acpicpu_passive, 0, CTL_CREATE, CTL_EOL);
if (err != 0)
goto fail;
return;
fail:
aprint_error_dev(self, "failed to initialize sysctl (err %d)\n", err);
}
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
static ACPI_STATUS
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
acpicpu_object(ACPI_HANDLE hdl, struct acpicpu_object *ao)
{
ACPI_OBJECT *obj;
ACPI_BUFFER buf;
ACPI_STATUS rv;
rv = acpi_eval_struct(hdl, NULL, &buf);
if (ACPI_FAILURE(rv))
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
goto out;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
obj = buf.Pointer;
if (obj->Type != ACPI_TYPE_PROCESSOR) {
rv = AE_TYPE;
goto out;
}
if (obj->Processor.ProcId > (uint32_t)maxcpus) {
rv = AE_LIMIT;
goto out;
}
KDASSERT((uint64_t)obj->Processor.PblkAddress < UINT32_MAX);
if (ao != NULL) {
ao->ao_procid = obj->Processor.ProcId;
ao->ao_pblklen = obj->Processor.PblkLength;
ao->ao_pblkaddr = obj->Processor.PblkAddress;
}
out:
if (buf.Pointer != NULL)
ACPI_FREE(buf.Pointer);
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
return rv;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
}
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
static int
acpicpu_find(struct cpu_info *ci, struct acpi_devnode **ptr)
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
{
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
struct acpi_softc *sc = acpi_softc;
struct acpicpu_object ao;
struct acpi_devnode *ad;
ACPI_INTEGER val;
ACPI_STATUS rv;
if (sc == NULL || acpi_active == 0)
return 0;
/*
* CPUs are declared in the ACPI namespace
* either as a Processor() or as a Device().
* In both cases the MADT entries are used
* for the match (see ACPI 4.0, section 8.4).
*/
SIMPLEQ_FOREACH(ad, &sc->ad_head, ad_list) {
if (ad->ad_type == ACPI_TYPE_PROCESSOR) {
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
rv = acpicpu_object(ad->ad_handle, &ao);
Remove the recently added ACPICPU_FLAG_INIT and instead operate with the existing ACPICPU_FLAG_C, as was intended. Set that flag only after the idle-loop has been installed, so that the notify handler errors out if an interrupt is received before the idle-loop is in place.
2010-07-23 09:32:02 +04:00
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
if (ACPI_SUCCESS(rv) && ci->ci_acpiid == ao.ao_procid)
goto out;
}
if (acpi_match_hid(ad->ad_devinfo, acpicpu_hid) != 0) {
rv = acpi_eval_integer(ad->ad_handle, "_UID", &val);
if (ACPI_SUCCESS(rv) && ci->ci_acpiid == val)
goto out;
}
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
}
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
return 0;
out:
if (ptr != NULL)
*ptr = ad;
Provide MD wrappers for match and attach.
2011-02-27 21:32:53 +03:00
return 10;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
}
static uint32_t
acpicpu_cap(struct acpicpu_softc *sc)
{
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
uint32_t flags, cap = 0;
const char *str;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
ACPI_STATUS rv;
/*
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
* Query and set machine-dependent capabilities.
* Note that the Intel-specific _PDC method was
* deprecated in the ACPI 3.0 in favor of _OSC.
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
*/
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
flags = acpicpu_md_cap();
rv = acpicpu_cap_osc(sc, flags, &cap);
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
if (ACPI_FAILURE(rv) && rv != AE_NOT_FOUND) {
str = "_OSC";
goto fail;
}
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
rv = acpicpu_cap_pdc(sc, flags);
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
if (ACPI_FAILURE(rv) && rv != AE_NOT_FOUND) {
str = "_PDC";
goto fail;
}
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
if (cap == 0)
cap = flags;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
return cap;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
fail:
aprint_error_dev(sc->sc_dev, "failed to evaluate "
"%s: %s\n", str, AcpiFormatException(rv));
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
return 0;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
}
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
static ACPI_STATUS
acpicpu_cap_pdc(struct acpicpu_softc *sc, uint32_t flags)
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
{
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
ACPI_OBJECT_LIST arg;
ACPI_OBJECT obj;
uint32_t cap[3];
arg.Count = 1;
arg.Pointer = &obj;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
cap[0] = ACPICPU_PDC_REVID;
cap[1] = 1;
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
cap[2] = flags;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
obj.Type = ACPI_TYPE_BUFFER;
obj.Buffer.Length = sizeof(cap);
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
obj.Buffer.Pointer = (void *)cap;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
return AcpiEvaluateObject(sc->sc_node->ad_handle, "_PDC", &arg, NULL);
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
}
static ACPI_STATUS
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
acpicpu_cap_osc(struct acpicpu_softc *sc, uint32_t flags, uint32_t *val)
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
{
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
ACPI_OBJECT_LIST arg;
ACPI_OBJECT obj[4];
ACPI_OBJECT *osc;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
ACPI_BUFFER buf;
ACPI_STATUS rv;
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
uint32_t cap[2];
uint32_t *ptr;
int i = 5;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
static uint8_t intel_uuid[16] = {
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47,
0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53
};
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
cap[0] = ACPI_OSC_QUERY;
cap[1] = flags;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
again:
arg.Count = 4;
arg.Pointer = obj;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
obj[0].Type = ACPI_TYPE_BUFFER;
obj[0].Buffer.Length = sizeof(intel_uuid);
obj[0].Buffer.Pointer = intel_uuid;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
obj[1].Type = ACPI_TYPE_INTEGER;
obj[1].Integer.Value = ACPICPU_PDC_REVID;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
obj[2].Type = ACPI_TYPE_INTEGER;
obj[2].Integer.Value = __arraycount(cap);
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
obj[3].Type = ACPI_TYPE_BUFFER;
obj[3].Buffer.Length = sizeof(cap);
obj[3].Buffer.Pointer = (void *)cap;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
buf.Pointer = NULL;
buf.Length = ACPI_ALLOCATE_LOCAL_BUFFER;
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
rv = AcpiEvaluateObject(sc->sc_node->ad_handle, "_OSC", &arg, &buf);
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
if (ACPI_FAILURE(rv))
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
goto out;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
osc = buf.Pointer;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
if (osc->Type != ACPI_TYPE_BUFFER) {
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
rv = AE_TYPE;
goto out;
}
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
if (osc->Buffer.Length != sizeof(cap)) {
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
rv = AE_BUFFER_OVERFLOW;
goto out;
}
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
ptr = (uint32_t *)osc->Buffer.Pointer;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
if ((ptr[0] & ACPI_OSC_ERROR) != 0) {
rv = AE_ERROR;
goto out;
}
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
if ((ptr[0] & (ACPI_OSC_ERROR_REV | ACPI_OSC_ERROR_UUID)) != 0) {
rv = AE_BAD_PARAMETER;
goto out;
}
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
/*
* "It is strongly recommended that the OS evaluate
* _OSC with the Query Support Flag set until _OSC
* returns the Capabilities Masked bit clear, to
* negotiate the set of features to be granted to
* the OS for native support (ACPI 4.0, 6.2.10)."
*/
if ((ptr[0] & ACPI_OSC_ERROR_MASKED) != 0 && i >= 0) {
ACPI_FREE(buf.Pointer);
i--;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
goto again;
}
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
if ((cap[0] & ACPI_OSC_QUERY) != 0) {
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
ACPI_FREE(buf.Pointer);
cap[0] &= ~ACPI_OSC_QUERY;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
goto again;
}
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
/*
* It is permitted for _OSC to return all
* bits cleared, but this is specified to
* vary on per-device basis. Assume that
* everything rather than nothing will be
Fix a comment typo.
2010-10-28 08:28:29 +04:00
* supported in this case; we do not need
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
* the firmware to know the CPU features.
*/
*val = (ptr[1] != 0) ? ptr[1] : cap[1];
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
From jmcneill@: fix and rework the obscure _OSC evaluation.
2010-08-27 06:44:05 +04:00
out:
if (buf.Pointer != NULL)
ACPI_FREE(buf.Pointer);
return rv;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
}
static void
acpicpu_notify(ACPI_HANDLE hdl, uint32_t evt, void *aux)
{
ACPI_OSD_EXEC_CALLBACK func;
struct acpicpu_softc *sc;
device_t self = aux;
sc = device_private(self);
Check the cold-flag also in the notify handler.
2010-08-14 15:16:14 +04:00
if (sc->sc_cold != false)
return;
Change the default behavior to enforce the maximum frequency when the firmware requests to do so. This cures severe overhating (> 120 C) observed on many laptops, being also on par with the specification(s). This can be reverted by using the new "hw.acpi.cpu.dynamic" sysctl variable.
2010-12-30 15:05:02 +03:00
if (acpicpu_dynamic != true)
return;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
switch (evt) {
case ACPICPU_C_NOTIFY:
if ((sc->sc_flags & ACPICPU_FLAG_C) == 0)
return;
func = acpicpu_cstate_callback;
break;
case ACPICPU_P_NOTIFY:
if ((sc->sc_flags & ACPICPU_FLAG_P) == 0)
return;
Merge P-state support for acpicpu(4). Remarks: 1. All processors (x86 or not) for which the vendor has implemented ACPI I/O access routines are supported. Native instructions are currently supported only for Intel's "Enhanced Speedstep". Code for "PowerNow!" (AMD) will be merged later. Native support for VIA's "PowerSaver" will be investigated. 2. Backwards compatibility with existing userland code is maintained. Comparable to the case with cpu_idle(9), the ACPI CPU driver installs alternative functions for the existing sysctl(8) controls. The "native" behavior (if any) is restored upon detachment. 3. The dynamic nature of ACPI-provided P-states needs more investigation. The maximum frequency induced (but not forced) by the firmware may change dynamically. Currently, the sysctl(8) controls error out with a value larger than the dynamic maximum. The code itself does not however yet react to the notifications from the firmware by changing the frequencies in-place. Presumably the system administrator should be able to choose whether to use dynamic or static frequencies.
2010-08-08 20:58:41 +04:00
func = acpicpu_pstate_callback;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
break;
case ACPICPU_T_NOTIFY:
if ((sc->sc_flags & ACPICPU_FLAG_T) == 0)
return;
Merge T-state a.k.a. throttling support for acpicpu(4). Remarks: 1. Native instructions are supported only on Intel. Native support for other x86 vendors will be investigated. By assumption, AMD and others use the I/O based approach. 2. The existing code, INTEL_ONDEMAND_CLOCKMOD, must be disabled in order to use acpicpu(4). Otherwise fatal MSR races may occur. Unlike with P-states, no attempt is done to disable the existing implementation. 3. There is no rationale to export controls to user land. 4. Throttling is an artefact from the past. T-states will not be used for power management per se. For CPU frequency management, P-states are preferred in all circumstances. No noticeable additional power savings were observed in various experiments. When the system has been scaled to the highest (i.e. lowest power) P-state, it is preferable to move from C0 to deeper C-states than it is to actively throttle the CPU. 5. But T-states need to be implemented for passive cooling via acpitz(4). As specified by ACPI and Intel documents, these can be used as the last line of defence against critical thermal conditions. Support for this will be added later.
2010-08-13 20:21:50 +04:00
func = acpicpu_tstate_callback;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
break;
default:
aprint_error_dev(sc->sc_dev, "unknown notify: 0x%02X\n", evt);
return;
}
(void)AcpiOsExecute(OSL_NOTIFY_HANDLER, func, sc->sc_dev);
}
static bool
acpicpu_suspend(device_t self, const pmf_qual_t *qual)
{
struct acpicpu_softc *sc = device_private(self);
if ((sc->sc_flags & ACPICPU_FLAG_C) != 0)
(void)acpicpu_cstate_suspend(self);
Merge P-state support for acpicpu(4). Remarks: 1. All processors (x86 or not) for which the vendor has implemented ACPI I/O access routines are supported. Native instructions are currently supported only for Intel's "Enhanced Speedstep". Code for "PowerNow!" (AMD) will be merged later. Native support for VIA's "PowerSaver" will be investigated. 2. Backwards compatibility with existing userland code is maintained. Comparable to the case with cpu_idle(9), the ACPI CPU driver installs alternative functions for the existing sysctl(8) controls. The "native" behavior (if any) is restored upon detachment. 3. The dynamic nature of ACPI-provided P-states needs more investigation. The maximum frequency induced (but not forced) by the firmware may change dynamically. Currently, the sysctl(8) controls error out with a value larger than the dynamic maximum. The code itself does not however yet react to the notifications from the firmware by changing the frequencies in-place. Presumably the system administrator should be able to choose whether to use dynamic or static frequencies.
2010-08-08 20:58:41 +04:00
if ((sc->sc_flags & ACPICPU_FLAG_P) != 0)
(void)acpicpu_pstate_suspend(self);
Merge T-state a.k.a. throttling support for acpicpu(4). Remarks: 1. Native instructions are supported only on Intel. Native support for other x86 vendors will be investigated. By assumption, AMD and others use the I/O based approach. 2. The existing code, INTEL_ONDEMAND_CLOCKMOD, must be disabled in order to use acpicpu(4). Otherwise fatal MSR races may occur. Unlike with P-states, no attempt is done to disable the existing implementation. 3. There is no rationale to export controls to user land. 4. Throttling is an artefact from the past. T-states will not be used for power management per se. For CPU frequency management, P-states are preferred in all circumstances. No noticeable additional power savings were observed in various experiments. When the system has been scaled to the highest (i.e. lowest power) P-state, it is preferable to move from C0 to deeper C-states than it is to actively throttle the CPU. 5. But T-states need to be implemented for passive cooling via acpitz(4). As specified by ACPI and Intel documents, these can be used as the last line of defence against critical thermal conditions. Support for this will be added later.
2010-08-13 20:21:50 +04:00
if ((sc->sc_flags & ACPICPU_FLAG_T) != 0)
(void)acpicpu_tstate_suspend(self);
Two changes: 1. Initialize P-states properly to P0. It is processor-specific what value we might get without initialization. (Some AMD CPUs have even specific registers for the state after cold reset.) 2. Following design notes for Windows, set the lowest-power P-state upon suspend and restore the saved state after resume.
2010-08-17 00:07:57 +04:00
sc->sc_cold = true;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
return true;
}
static bool
acpicpu_resume(device_t self, const pmf_qual_t *qual)
{
struct acpicpu_softc *sc = device_private(self);
Two changes: 1. Initialize P-states properly to P0. It is processor-specific what value we might get without initialization. (Some AMD CPUs have even specific registers for the state after cold reset.) 2. Following design notes for Windows, set the lowest-power P-state upon suspend and restore the saved state after resume.
2010-08-17 00:07:57 +04:00
sc->sc_cold = false;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
if ((sc->sc_flags & ACPICPU_FLAG_C) != 0)
(void)acpicpu_cstate_resume(self);
Merge P-state support for acpicpu(4). Remarks: 1. All processors (x86 or not) for which the vendor has implemented ACPI I/O access routines are supported. Native instructions are currently supported only for Intel's "Enhanced Speedstep". Code for "PowerNow!" (AMD) will be merged later. Native support for VIA's "PowerSaver" will be investigated. 2. Backwards compatibility with existing userland code is maintained. Comparable to the case with cpu_idle(9), the ACPI CPU driver installs alternative functions for the existing sysctl(8) controls. The "native" behavior (if any) is restored upon detachment. 3. The dynamic nature of ACPI-provided P-states needs more investigation. The maximum frequency induced (but not forced) by the firmware may change dynamically. Currently, the sysctl(8) controls error out with a value larger than the dynamic maximum. The code itself does not however yet react to the notifications from the firmware by changing the frequencies in-place. Presumably the system administrator should be able to choose whether to use dynamic or static frequencies.
2010-08-08 20:58:41 +04:00
if ((sc->sc_flags & ACPICPU_FLAG_P) != 0)
(void)acpicpu_pstate_resume(self);
Merge T-state a.k.a. throttling support for acpicpu(4). Remarks: 1. Native instructions are supported only on Intel. Native support for other x86 vendors will be investigated. By assumption, AMD and others use the I/O based approach. 2. The existing code, INTEL_ONDEMAND_CLOCKMOD, must be disabled in order to use acpicpu(4). Otherwise fatal MSR races may occur. Unlike with P-states, no attempt is done to disable the existing implementation. 3. There is no rationale to export controls to user land. 4. Throttling is an artefact from the past. T-states will not be used for power management per se. For CPU frequency management, P-states are preferred in all circumstances. No noticeable additional power savings were observed in various experiments. When the system has been scaled to the highest (i.e. lowest power) P-state, it is preferable to move from C0 to deeper C-states than it is to actively throttle the CPU. 5. But T-states need to be implemented for passive cooling via acpitz(4). As specified by ACPI and Intel documents, these can be used as the last line of defence against critical thermal conditions. Support for this will be added later.
2010-08-13 20:21:50 +04:00
if ((sc->sc_flags & ACPICPU_FLAG_T) != 0)
(void)acpicpu_tstate_resume(self);
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
return true;
}
Start to derive the percpu(9) (or per-domain) state coordination mechanisms by parsing the _CSD, _PSD, and _TSD objects by default.
2011-02-25 22:55:06 +03:00
static void
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
acpicpu_debug_print(device_t self)
Start to derive the percpu(9) (or per-domain) state coordination mechanisms by parsing the _CSD, _PSD, and _TSD objects by default.
2011-02-25 22:55:06 +03:00
{
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
struct acpicpu_softc *sc = device_private(self);
struct cpu_info *ci = sc->sc_ci;
Simplify by moving the debug printfs to one place. No functional change.
2011-03-01 08:32:03 +03:00
struct acpicpu_cstate *cs;
struct acpicpu_pstate *ps;
struct acpicpu_tstate *ts;
static bool once = false;
Start to derive the percpu(9) (or per-domain) state coordination mechanisms by parsing the _CSD, _PSD, and _TSD objects by default.
2011-02-25 22:55:06 +03:00
struct acpicpu_dep *dep;
Simplify by moving the debug printfs to one place. No functional change.
2011-03-01 08:32:03 +03:00
uint32_t i, method;
if (once != true) {
for (i = 0; i < __arraycount(sc->sc_cstate); i++) {
cs = &sc->sc_cstate[i];
if (cs->cs_method == 0)
continue;
aprint_verbose_dev(sc->sc_dev, "C%d: %3s, "
"lat %3u us, pow %5u mW, %s\n", i,
acpicpu_debug_print_method(cs->cs_method),
cs->cs_latency, cs->cs_power,
(cs->cs_flags != 0) ? "bus master check" : "");
}
method = sc->sc_pstate_control.reg_spaceid;
for (i = 0; i < sc->sc_pstate_count; i++) {
ps = &sc->sc_pstate[i];
if (ps->ps_freq == 0)
continue;
aprint_verbose_dev(sc->sc_dev, "P%d: %3s, "
"lat %3u us, pow %5u mW, %4u MHz\n", i,
acpicpu_debug_print_method(method),
ps->ps_latency, ps->ps_power, ps->ps_freq);
}
method = sc->sc_tstate_control.reg_spaceid;
for (i = 0; i < sc->sc_tstate_count; i++) {
ts = &sc->sc_tstate[i];
if (ts->ts_percent == 0)
continue;
aprint_verbose_dev(sc->sc_dev, "T%u: %3s, "
"lat %3u us, pow %5u mW, %3u %%\n", i,
acpicpu_debug_print_method(method),
ts->ts_latency, ts->ts_power, ts->ts_percent);
}
once = true;
}
Start to derive the percpu(9) (or per-domain) state coordination mechanisms by parsing the _CSD, _PSD, and _TSD objects by default.
2011-02-25 22:55:06 +03:00
Move acpicpu(4) from "acpinodebus" to "cpufeaturebus".
2011-02-27 20:10:33 +03:00
aprint_debug_dev(sc->sc_dev, "id %u, lapic id %u, "
"cap 0x%04x, flags 0x%08x\n", ci->ci_acpiid,
(uint32_t)ci->ci_cpuid, sc->sc_cap, sc->sc_flags);
Start to derive the percpu(9) (or per-domain) state coordination mechanisms by parsing the _CSD, _PSD, and _TSD objects by default.
2011-02-25 22:55:06 +03:00
if ((sc->sc_flags & ACPICPU_FLAG_C_DEP) != 0) {
dep = &sc->sc_cstate_dep;
aprint_debug_dev(sc->sc_dev, "C-state coordination: "
"%u CPUs, domain %u, type %s\n", dep->dep_ncpus,
dep->dep_domain, acpicpu_debug_print_dep(dep->dep_type));
}
if ((sc->sc_flags & ACPICPU_FLAG_P_DEP) != 0) {
dep = &sc->sc_pstate_dep;
aprint_debug_dev(sc->sc_dev, "P-state coordination: "
"%u CPUs, domain %u, type %s\n", dep->dep_ncpus,
dep->dep_domain, acpicpu_debug_print_dep(dep->dep_type));
}
if ((sc->sc_flags & ACPICPU_FLAG_T_DEP) != 0) {
dep = &sc->sc_tstate_dep;
aprint_debug_dev(sc->sc_dev, "T-state coordination: "
"%u CPUs, domain %u, type %s\n", dep->dep_ncpus,
dep->dep_domain, acpicpu_debug_print_dep(dep->dep_type));
}
}
Simplify by moving the debug printfs to one place. No functional change.
2011-03-01 08:32:03 +03:00
static const char *
acpicpu_debug_print_method(uint8_t val)
{
switch (val) {
case ACPICPU_C_STATE_HALT:
return "HLT";
case ACPICPU_C_STATE_FFH:
case ACPI_ADR_SPACE_FIXED_HARDWARE:
return "FFH";
case ACPICPU_C_STATE_SYSIO: /* ACPI_ADR_SPACE_SYSTEM_IO */
return "I/O";
default:
return "???";
}
}
Start to derive the percpu(9) (or per-domain) state coordination mechanisms by parsing the _CSD, _PSD, and _TSD objects by default.
2011-02-25 22:55:06 +03:00
static const char *
acpicpu_debug_print_dep(uint32_t val)
{
switch (val) {
case ACPICPU_DEP_SW_ALL:
return "SW_ALL";
case ACPICPU_DEP_SW_ANY:
return "SW_ANY";
case ACPICPU_DEP_HW_ALL:
return "HW_ALL";
default:
return "unknown";
}
}
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
MODULE(MODULE_CLASS_DRIVER, acpicpu, NULL);
Use ioconf for the module declarations.
2011-02-16 11:35:51 +03:00
#ifdef _MODULE
#include "ioconf.c"
#endif
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
static int
Use ioconf for the module declarations.
2011-02-16 11:35:51 +03:00
acpicpu_modcmd(modcmd_t cmd, void *aux)
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
{
Use ioconf for the module declarations.
2011-02-16 11:35:51 +03:00
int rv = 0;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
switch (cmd) {
case MODULE_CMD_INIT:
Use ioconf for the module declarations.
2011-02-16 11:35:51 +03:00
#ifdef _MODULE
rv = config_init_component(cfdriver_ioconf_acpicpu,
cfattach_ioconf_acpicpu, cfdata_ioconf_acpicpu);
#endif
break;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
case MODULE_CMD_FINI:
Use ioconf for the module declarations.
2011-02-16 11:35:51 +03:00
#ifdef _MODULE
rv = config_fini_component(cfdriver_ioconf_acpicpu,
cfattach_ioconf_acpicpu, cfdata_ioconf_acpicpu);
#endif
break;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
default:
Use ioconf for the module declarations.
2011-02-16 11:35:51 +03:00
rv = ENOTTY;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
}
Use ioconf for the module declarations.
2011-02-16 11:35:51 +03:00
return rv;
}
Reference in New Issue Copy Permalink