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

670 lines
14 KiB
C
Raw Normal View History

Rename couple of badly named functions for consistency. No functional change.
2011-02-25 15:08:35 +03:00
/* $NetBSD: acpi_cpu.c,v 1.28 2011/02/25 12:08:35 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>
Rename couple of badly named functions for consistency. No functional change.
2011-02-25 15:08:35 +03:00
__KERNEL_RCSID(0, "$NetBSD: acpi_cpu.c,v 1.28 2011/02/25 12:08:35 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>
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/once.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>
#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);
Deal with autoconfiguration madness by using config_defer(9) to defer config_interrupts(9) to be executed. This is necessary because: (a) the initialization routines must be run only once after interrupts are enabled and (b) all ACPI CPUs have attached.
2010-08-19 09:09:53 +04:00
static void acpicpu_prestart(device_t);
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);
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
static int acpicpu_object(ACPI_HANDLE, struct acpicpu_object *);
Store a pointer to cpu_info rather than cpu_info::ci_acpiid alone.
2011-02-25 09:18:02 +03:00
static struct cpu_info *acpicpu_ci(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 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 *);
Do not try to attach more ACPI CPUs than the amount of "real" CPUs.
2011-01-13 07:18:19 +03:00
extern uint32_t acpi_cpus;
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)
{
struct acpi_attach_args *aa = aux;
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
struct acpicpu_object 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
int 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
if (aa->aa_node->ad_type != ACPI_TYPE_PROCESSOR)
return 0;
if (acpi_match_hid(aa->aa_node->ad_devinfo, acpicpu_hid) != 0)
return 1;
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
rv = acpicpu_object(aa->aa_node->ad_handle, &ao);
Store a pointer to cpu_info rather than cpu_info::ci_acpiid alone.
2011-02-25 09:18:02 +03:00
if (rv != 0 || acpicpu_ci(ao.ao_procid) == 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
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 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
}
static void
acpicpu_attach(device_t parent, device_t self, void *aux)
{
struct acpicpu_softc *sc = device_private(self);
struct acpi_attach_args *aa = aux;
static ONCE_DECL(once_attach);
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;
rv = acpicpu_object(aa->aa_node->ad_handle, &sc->sc_object);
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
if (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
return;
rv = RUN_ONCE(&once_attach, acpicpu_once_attach);
if (rv != 0)
return;
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;
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_node = aa->aa_node;
Store a pointer to cpu_info rather than cpu_info::ci_acpiid alone.
2011-02-25 09:18:02 +03:00
sc->sc_ci = acpicpu_ci(sc->sc_object.ao_procid);
if (sc->sc_ci == NULL) {
aprint_error(": invalid CPU\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;
}
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) {
Remove the currently unnecessary mutex.
2010-07-25 02:44:00 +04:00
aprint_error(": 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");
Do not try to attach more ACPI CPUs than the amount of "real" CPUs.
2011-01-13 07:18:19 +03:00
acpi_cpus++;
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);
Rename couple of badly named functions for consistency. No functional change.
2011-02-25 15:08:35 +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
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
Deal with autoconfiguration madness by using config_defer(9) to defer config_interrupts(9) to be executed. This is necessary because: (a) the initialization routines must be run only once after interrupts are enabled and (b) all ACPI CPUs have attached.
2010-08-19 09:09:53 +04:00
(void)config_defer(self, acpicpu_prestart);
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);
static ONCE_DECL(once_detach);
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);
if (rv != 0)
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
rv = RUN_ONCE(&once_detach, acpicpu_once_detach);
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);
Do not try to attach more ACPI CPUs than the amount of "real" CPUs.
2011-01-13 07:18:19 +03:00
acpi_cpus--;
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;
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;
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 (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
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);
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
Deal with autoconfiguration madness by using config_defer(9) to defer config_interrupts(9) to be executed. This is necessary because: (a) the initialization routines must be run only once after interrupts are enabled and (b) all ACPI CPUs have attached.
2010-08-19 09:09:53 +04:00
acpicpu_prestart(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);
static bool once = false;
if (once != false) {
sc->sc_cold = false;
return;
}
Deal with autoconfiguration madness by using config_defer(9) to defer config_interrupts(9) to be executed. This is necessary because: (a) the initialization routines must be run only once after interrupts are enabled and (b) all ACPI CPUs have attached.
2010-08-19 09:09:53 +04:00
once = true;
(void)config_interrupts(self, acpicpu_start);
}
static void
acpicpu_start(device_t self)
{
struct acpicpu_softc *sc = device_private(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
/*
* Run the state-specific initialization
* routines. These should be called only
Deal with autoconfiguration madness by using config_defer(9) to defer config_interrupts(9) to be executed. This is necessary because: (a) the initialization routines must be run only once after interrupts are enabled and (b) all ACPI CPUs have attached.
2010-08-19 09:09:53 +04:00
* once, after interrupts are enabled and
* all ACPI CPUs have attached.
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);
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);
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
aprint_debug_dev(sc->sc_dev, "ACPI CPUs started (cap "
"0x%02x, flags 0x%06x)\n", sc->sc_cap, sc->sc_flags);
sc->sc_cold = false;
}
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;
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);
}
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
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))
Fix wrong return value.
2010-07-26 19:14:33 +04:00
return 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
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);
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
return ACPI_FAILURE(rv) ? 1 : 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
}
Store a pointer to cpu_info rather than cpu_info::ci_acpiid alone.
2011-02-25 09:18:02 +03:00
static struct cpu_info *
acpicpu_ci(uint32_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
{
CPU_INFO_ITERATOR cii;
struct cpu_info *ci;
for (CPU_INFO_FOREACH(cii, ci)) {
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
Store the MADT-derived CPU ID to <x86/cpu.h>. This is required to properly match the ACPI processor object ID with the ID available in the APIC table.
2010-08-04 14:02:11 +04:00
if (id == ci->ci_acpiid)
Store a pointer to cpu_info rather than cpu_info::ci_acpiid alone.
2011-02-25 09:18:02 +03:00
return 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
}
Store a pointer to cpu_info rather than cpu_info::ci_acpiid alone.
2011-02-25 09:18:02 +03:00
return 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 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;
}
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