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

234 lines
7.6 KiB
C
Raw Normal View History

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
/* $NetBSD: acpi_cpu.h,v 1.14 2010/08/13 16:21:50 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
/*-
* Copyright (c) 2010 Jukka Ruohonen <jruohonen@iki.fi>
* 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.
*/
#ifndef _SYS_DEV_ACPI_ACPI_CPU_H
#define _SYS_DEV_ACPI_ACPI_CPU_H
/*
* The following _PDC values are based on:
*
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
* Intel Corporation: Intel Processor-Specific ACPI
* Interface Specification, September 2006, Revision 005.
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
*/
#define ACPICPU_PDC_REVID 0x1
#define ACPICPU_PDC_SMP 0xA
#define ACPICPU_PDC_MSR 0x1
#define ACPICPU_PDC_P_FFH __BIT(0) /* SpeedStep MSRs */
#define ACPICPU_PDC_C_C1_HALT __BIT(1) /* C1 "I/O then halt" */
#define ACPICPU_PDC_T_FFH __BIT(2) /* OnDemand throttling MSRs */
#define ACPICPU_PDC_C_C1PT __BIT(3) /* SMP C1, Px, and Tx (same) */
#define ACPICPU_PDC_C_C2C3 __BIT(4) /* SMP C2 and C3 (same) */
#define ACPICPU_PDC_P_SW __BIT(5) /* SMP Px (different) */
#define ACPICPU_PDC_C_SW __BIT(6) /* SMP Cx (different) */
#define ACPICPU_PDC_T_SW __BIT(7) /* SMP Tx (different) */
#define ACPICPU_PDC_C_C1_FFH __BIT(8) /* SMP C1 native beyond halt */
#define ACPICPU_PDC_C_C2C3_FFH __BIT(9) /* SMP C2 and C2 native */
#define ACPICPU_PDC_P_HW __BIT(11) /* Px hardware coordination */
Move the GAS definition to the header so it can be shared. Make a basic sanity check before casting to the GAS. Rename the _CSD structure; the optional "cross logical processor dependency information" is almost identical in C, P, and T states. Add some comments to the header.
2010-07-27 09:11:32 +04:00
#define ACPICPU_PDC_GAS_HW __BIT(0) /* HW-coordinated state */
#define ACPICPU_PDC_GAS_BM __BIT(1) /* Bus master check required */
Add a new flag that determines whether we should check for bus master activity (BM_STS) by reading from the PM1 register. According to the Intel processor specification for ACPI, the FFH GAS encoding may provide a hint that the check is not required. This may help some systems to enter C2/C3 even when e.g. usb(4) keeps the BM_STS bit always enabled.
2010-07-23 12:11:49 +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
/*
* Notify values.
*/
#define ACPICPU_P_NOTIFY 0x80 /* _PPC */
#define ACPICPU_C_NOTIFY 0x81 /* _CST */
#define ACPICPU_T_NOTIFY 0x82 /* _TPC */
/*
* C-states.
*/
#define ACPICPU_C_C2_LATENCY_MAX 100 /* us */
#define ACPICPU_C_C3_LATENCY_MAX 1000 /* us */
#define ACPICPU_C_STATE_HALT 0x01
#define ACPICPU_C_STATE_FFH 0x02
#define ACPICPU_C_STATE_SYSIO 0x03
Move the GAS definition to the header so it can be shared. Make a basic sanity check before casting to the GAS. Rename the _CSD structure; the optional "cross logical processor dependency information" is almost identical in C, P, and T states. Add some comments to the header.
2010-07-27 09:11:32 +04:00
/*
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
* P-states.
Move the GAS definition to the header so it can be shared. Make a basic sanity check before casting to the GAS. Rename the _CSD structure; the optional "cross logical processor dependency information" is almost identical in C, P, and T states. Add some comments to the header.
2010-07-27 09:11:32 +04:00
*/
Use a define instead of a magic constant for the arbitrary P-state limit.
2010-08-11 15:48:21 +04:00
#define ACPICPU_P_STATE_MAX 255 /* Arbitrary upper limit */
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
#define ACPICPU_P_STATE_RETRY 100
#define ACPICPU_P_STATE_UNKNOWN 0x0
Move the GAS definition to the header so it can be shared. Make a basic sanity check before casting to the GAS. Rename the _CSD structure; the optional "cross logical processor dependency information" is almost identical in C, P, and T states. Add some comments to the header.
2010-07-27 09:11:32 +04:00
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
/*
* T-states.
*/
#define ACPICPU_T_STATE_MAX 0x8
#define ACPICPU_T_STATE_RETRY 0xA
#define ACPICPU_T_STATE_UNKNOWN 255
Move the GAS definition to the header so it can be shared. Make a basic sanity check before casting to the GAS. Rename the _CSD structure; the optional "cross logical processor dependency information" is almost identical in C, P, and T states. Add some comments to the header.
2010-07-27 09:11:32 +04:00
/*
* Flags.
*/
#define ACPICPU_FLAG_C __BIT(0) /* C-states supported */
#define ACPICPU_FLAG_P __BIT(1) /* P-states supported */
#define ACPICPU_FLAG_T __BIT(2) /* T-states supported */
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
#define ACPICPU_FLAG_C_FFH __BIT(3) /* Native C-states */
Move the GAS definition to the header so it can be shared. Make a basic sanity check before casting to the GAS. Rename the _CSD structure; the optional "cross logical processor dependency information" is almost identical in C, P, and T states. Add some comments to the header.
2010-07-27 09:11:32 +04:00
#define ACPICPU_FLAG_C_FADT __BIT(4) /* C-states with FADT */
#define ACPICPU_FLAG_C_BM __BIT(5) /* Bus master control */
#define ACPICPU_FLAG_C_BM_STS __BIT(6) /* Bus master check required */
#define ACPICPU_FLAG_C_ARB __BIT(7) /* Bus master arbitration */
#define ACPICPU_FLAG_C_NOC3 __BIT(8) /* C3 disabled (quirk) */
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
#define ACPICPU_FLAG_C_C1E __BIT(9) /* AMD C1E detected */
#define ACPICPU_FLAG_P_FFH __BIT(10) /* Native P-states */
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
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
#define ACPICPU_FLAG_T_FFH __BIT(11) /* Native throttling */
#define ACPICPU_FLAG_T_FADT __BIT(12) /* Throttling with FADT */
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
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
/*
* This is AML_RESOURCE_GENERIC_REGISTER,
* included here separately for convenience.
*/
struct acpicpu_reg {
uint8_t reg_desc;
uint16_t reg_reslen;
uint8_t reg_spaceid;
uint8_t reg_bitwidth;
uint8_t reg_bitoffset;
uint8_t reg_accesssize;
uint64_t reg_addr;
} __packed;
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_cstate {
Use evcnt(9) for the counters.
2010-08-10 06:42:05 +04:00
struct evcnt cs_evcnt;
char cs_name[EVCNT_STRING_MAX];
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
uint64_t cs_addr;
uint32_t cs_power; /* mW */
uint32_t cs_latency; /* us */
int cs_method;
Add a new flag that determines whether we should check for bus master activity (BM_STS) by reading from the PM1 register. According to the Intel processor specification for ACPI, the FFH GAS encoding may provide a hint that the check is not required. This may help some systems to enter C2/C3 even when e.g. usb(4) keeps the BM_STS bit always enabled.
2010-07-23 12:11:49 +04:00
int cs_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
};
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
struct acpicpu_pstate {
Use evcnt(9) for the counters.
2010-08-10 06:42:05 +04:00
struct evcnt ps_evcnt;
char ps_name[EVCNT_STRING_MAX];
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
uint32_t ps_freq; /* MHz */
uint32_t ps_power; /* mW */
uint32_t ps_latency; /* us */
uint32_t ps_latency_bm; /* us */
uint32_t ps_control;
uint32_t ps_status;
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
};
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
struct acpicpu_tstate {
struct evcnt ts_evcnt;
char ts_name[EVCNT_STRING_MAX];
uint32_t ts_percent; /* % */
uint32_t ts_power; /* mW */
uint32_t ts_latency; /* us */
uint32_t ts_control;
uint32_t ts_status;
};
Merge a driver for ACPI CPUs with basic support for processor power states, also known as C-states. The code is modular and provides an easy way to add the remaining functionality later (namely throttling and P-states). Remarks: 1. Commented out in the GENERICs; more testing exposure is needed. 2. The C3-state is disabled for the time being because it turns off timers, among them the local APIC timer. This may not be universally true on all x86 processors; define ACPICPU_ENABLE_C3 to test. 3. The algorithm used to choose a power state may need tuning. When evaluating the appropriate state, the implementation uses the previous sleep time as an indicator. Additional hints would include for example the system load. Also bus master activity is evaluated when choosing a state. The usb(4) stack is notorious for such activity even when unused. Typically it must be disabled in order to reach the C3-state, but it may also prevent the use of C2. 4. While no extensive empirical measurements have been carried out, the power savings are somewhere between 1-2 W with C1 and C2, depending on the processor, firmware, and load. With C3 even up to 4 W can be saved. The less something ticks, the more power is saved. ok jmcneill@, joerg@, and discussed with various people.
2010-07-18 13:29:11 +04:00
struct acpicpu_object {
uint32_t ao_procid;
uint32_t ao_pblklen;
uint32_t ao_pblkaddr;
};
struct acpicpu_softc {
device_t sc_dev;
struct acpi_devnode *sc_node;
struct acpicpu_object sc_object;
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
Add a per ACPI CPU mutex for C-states. Protect the _CST update with this: when the idle-information is being updated (e.g. due acpiacad(4) events), we can not enter the idle-loop. The lock must run at the same priority (IPL_NONE) as ACPICA's mutexes obtained via AcpiOsCreateMutex() a.k.a. AcpiOsCreateSemaphore(). Also check want_resched as the first thing and clarify the suspend/resume path. There is still one race condition identified: when the driver is loaded as a module, we must gracefully kick all CPUs out from the ACPI idle-loop upon detachment.
2010-07-30 02:42:58 +04:00
struct acpicpu_cstate sc_cstate[ACPI_C_STATE_COUNT];
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
uint32_t sc_cstate_sleep;
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
struct acpicpu_pstate *sc_pstate;
struct acpicpu_reg sc_pstate_control;
struct acpicpu_reg sc_pstate_status;
uint32_t sc_pstate_current;
uint32_t sc_pstate_count;
uint32_t sc_pstate_max;
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
struct acpicpu_tstate *sc_tstate;
struct acpicpu_reg sc_tstate_control;
struct acpicpu_reg sc_tstate_status;
uint32_t sc_tstate_current;
uint32_t sc_tstate_count;
uint32_t sc_tstate_max;
uint32_t sc_tstate_min;
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
kmutex_t sc_mtx;
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
bus_space_tag_t sc_iot;
bus_space_handle_t sc_ioh;
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
uint32_t sc_cap;
uint32_t sc_flags;
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
cpuid_t sc_cpuid;
Add a per ACPI CPU mutex for C-states. Protect the _CST update with this: when the idle-information is being updated (e.g. due acpiacad(4) events), we can not enter the idle-loop. The lock must run at the same priority (IPL_NONE) as ACPICA's mutexes obtained via AcpiOsCreateMutex() a.k.a. AcpiOsCreateSemaphore(). Also check want_resched as the first thing and clarify the suspend/resume path. There is still one race condition identified: when the driver is loaded as a module, we must gracefully kick all CPUs out from the ACPI idle-loop upon detachment.
2010-07-30 02:42:58 +04:00
bool sc_cold;
jmcneill@: do not touch the bus_space(9) handle.
2010-08-08 22:47:54 +04:00
bool sc_mapped;
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 acpicpu_cstate_attach(device_t);
int acpicpu_cstate_detach(device_t);
int acpicpu_cstate_start(device_t);
bool acpicpu_cstate_suspend(device_t);
bool acpicpu_cstate_resume(device_t);
void acpicpu_cstate_callback(void *);
void acpicpu_cstate_idle(void);
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 acpicpu_pstate_attach(device_t);
int acpicpu_pstate_detach(device_t);
int acpicpu_pstate_start(device_t);
bool acpicpu_pstate_suspend(device_t);
bool acpicpu_pstate_resume(device_t);
void acpicpu_pstate_callback(void *);
int acpicpu_pstate_get(struct acpicpu_softc *, uint32_t *);
int acpicpu_pstate_set(struct acpicpu_softc *, uint32_t);
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
void acpicpu_tstate_attach(device_t);
int acpicpu_tstate_detach(device_t);
int acpicpu_tstate_start(device_t);
bool acpicpu_tstate_suspend(device_t);
bool acpicpu_tstate_resume(device_t);
void acpicpu_tstate_callback(void *);
int acpicpu_tstate_get(struct acpicpu_softc *, uint32_t *);
int acpicpu_tstate_set(struct acpicpu_softc *, 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
uint32_t acpicpu_md_cap(void);
uint32_t acpicpu_md_quirks(void);
uint32_t acpicpu_md_cpus_running(void);
int acpicpu_md_idle_start(void);
int acpicpu_md_idle_stop(void);
void acpicpu_md_idle_enter(int, int);
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
int acpicpu_md_pstate_start(void);
int acpicpu_md_pstate_stop(void);
int acpicpu_md_pstate_get(struct acpicpu_softc *, uint32_t *);
int acpicpu_md_pstate_set(struct acpicpu_pstate *);
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
int acpicpu_md_tstate_get(struct acpicpu_softc *, uint32_t *);
int acpicpu_md_tstate_set(struct acpicpu_tstate *);
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
#endif /* !_SYS_DEV_ACPI_ACPI_CPU_H */
Reference in New Issue Copy Permalink