cpudrv.h revision fcddbe1ff917b2a8770cd3575f46e72601a06df6
1137N/A * The contents of this file are subject to the terms of the 1137N/A * Common Development and Distribution License (the "License"). 1137N/A * You may not use this file except in compliance with the License. 1137N/A * See the License for the specific language governing permissions 1137N/A * and limitations under the License. 1137N/A * When distributing Covered Code, include this CDDL HEADER in each 1137N/A * If applicable, add the following below this CDDL HEADER, with the 1137N/A * fields enclosed by brackets "[]" replaced with your own identifying 1137N/A * information: Portions Copyright [yyyy] [name of copyright owner] 1137N/A * Copyright 2009 Sun Microsystems, Inc. All rights reserved. 1137N/A * Use is subject to license terms. 1137N/A * CPU power management data 1137N/A * Data related to a particular speed. * All per speed data nodes for a CPU are linked together using down_spd. * The link list is ordered with first node containing data for * normal (maximum) speed. up_spd points to the next speed up. Currently * all up_spd's point to the normal speed but this can be changed in future. * quant_cnt is the number of ticks when monitoring system will be called * next. There are different quant_cnt for different speeds. * Note that 'speed' has different meaning depending upon the platform. * On SPARC, the speed is really a divisor of the maximum speed (e.g., a speed * of 2 means that it's 1/2 the maximum speed). On x86, speed is a processor int user_lwm;
/* down if user thread <= lwm */ int pm_level;
/* power level for framework */ taskq_t *
tq;
/* taskq handler for CPU monitor */ * Idle & user threads water marks in percentage * Maximums for creating 'pm-components' property * Component number for calls to PM framework * Quantum counts for normal and other clock speeds in terms of ticks. * In determining the quantum count, we need to balance two opposing factors: * 1) Minimal delay when user start using the CPU that is in low * power mode -- requires that we monitor more frequently, * 2) Extra code executed because of frequent monitoring -- requires * that we monitor less frequently. * We reach a tradeoff between these two requirements by monitoring * more frequently when we are in low speed mode (CPUDRV_PM_QUANT_CNT_OTHR) * so we can bring the CPU up without user noticing it. Moreover, at low * speed we are not using CPU much so extra code execution should be fine. * Since we are in no hurry to bring CPU down and at normal speed and we * might really be using the CPU fully, we monitor less frequently * (CPUDRV_PM_QUANT_CNT_NORMAL). * Device driver state structure #
endif /* _SYS_CPUDRV_H */