United States Patent 5
`5,590,342
`{11} Patent Number:
`Marisetty
`[45] Date of Patent:
`Dec. 31, 1996
`
`
`QAIACA
`
`US005590342A
`
`[54] METHOD AND APPARATUS FOR
`REDUCING POWER CONSUMPTION INA
`COMPUTER SYSTEM USING VIRTUAL
`DEVICE DRIVERS
`.
`.
`Inventor: Suresh K. Marisetty, San Jose, Calif.
`[75]
`[73] Assignee:
`Intel Corporation, Santa Clara, Calif.
`
`[21] Appl. No.: 346,040
`[22]
`Filed:
`Nov. 29, 1994
`
`P
`[51] Tt, Ceeecceeestsceseessessesssecsssscseesserseeese GO6F 13/00
`[52] US. Cdr oceesssseessssececssseeeeennseernsees 395/750; 395/280
`{58} Field of Searchsess 395/750, 280;
`364/707
`
`{56}
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`1/1994 Kardach et al. oes eseceeseeee 395/725
`5,276,888
`4/1995 Mattox...
`. 364/709.01
`5,404,321
`
`
`....uccsssscscrssersessenescens 395/750
`4/1995 Stewart
`5,404,546
`Primary Examiner—Ayaz R. Sheikh
`Assistant Examiner—John Travis
`Attorney, Agent, or Firm—Blakely, Sokoloff, Taylor & Zaf-
`man
`[57]
`ABSTRACT
`A power management mechanism for use in a computer
`system having a bus, a memory for storing data and instruc-
`tions, and a central processing unit (CPU). The CPU runs an
`operating system having a power management virtual device
`driver (PMVxD) responsible for performing idle detection
`for devices. The PMVxD performs idle detection using
`event timers that provide an indicator as to the activity level.
`The PMVxD places idle local devices in a reduced power
`consumption state when no activity has occurred for a
`predetermined period of time.
`
`5,167,024 11/1992 Smith et al. vssesssesesesseseeee 395/375
`
`35 Claims, 7 Drawing Sheets
`
`APPLICATION
`
`POWER-AWARE
`
`APPLICATION
`
`102
`
`POWER-AWARE
`
`DEVICE DRIVER
`
`106
`
`POWER-UNAWARE
`APPLICATION
`
`POWER-UNAWARE
`APPLICATION
`
`4110
`
`\
`
`SOFTWARE CONTROLLED POWER MANAGEMENT
`iti
`
`
`
`
`POWER-UNAWARE
`
`
`APPLICATION
`
`P-N-P
`
`
`CONFIG
`
`APM & PMC
` PMVxD POWER
`MANAGER 444
`
`DEVICE DRIVER
`MANAGEMENT
`103 =
`a 13
`
` POWER-AWARE
`
`
`
`
`
`
`
`
`
`
`APM BIOS
`CONTROLLED
`
`
`
`HARDWARE 405
`
`os
`SOFTWARE
`LAYERS
`
`HARDWARE
`LAYERS
`
`APM BIOS
`
`104
`
`POWER
`MANAGEMENT
`HARDWARE,14
`
`VxD CONTROLLED
`YO HARDWARE
`RAE]
`
`VxD CONTROLLED
`'fQ HARDWARE
`116
`
`Google Exhibit 1025
`Google Exhibit 1025
`Google v. Valtrus
`Googlev. Valtrus
`
`

`

`U.S. Patent
`
`Dec. 31, 1996
`
`Sheet 1 of 7
`
`5,590,342
`
`SYVMLIOS
`
`
`LNAWSDVNVWHAMOdCATIOULNOO
`
`OTTait
`
`HLSuYMGHVH
`
`LNAWS9DNV
`
`LL
`
`AYVMYNN-HAMOd
`
`
`
`NOILWONIdd
`
`SAYVMYNN-YaMOd
`SYVMYNN-YSAMOd
`
`NOLLVOFdd¥
`
`NOILWONdd¥
`
`
`
`YAMOdAXAWd
`
`LINAWSSVNVA
`
`
`
`PITUapyNWN
`
`Ned
`
`BIINOD
`
`CSaTIOULNODGXA
`
`SYVMGHYVHO/1
`
`SYVMCHVHO/|
`
`Q3STIOULNODOXAWIMOd
`
`SYUVMV-YSMOd
`
`
`
`HAAGSOIASd
`
`SYVMY-YaMOd
`SYVMY-HaMOd
`
`NOLLWONdd¥
`NOILVOIIdd¥
`
`
`
`SOFsuyMCHWH
`
`SoldWa
`
`GSTIOWINOD
`
`
`
`WaAl3OIAaG
`
`
`
`OWd8WVSUAAY)
`
`S/O
`
`JUVMLIOS
`
`I
`
`
`
`SoldWavSUIAVT
`
`auVMCHVH
`
`tT“Dia
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Dec. 31, 1996
`
`Sheet 2 of 7
`
`5,590,342
`
`ACTIVE
`
`SYSTEM
`SYSTEM
`ACTIVITY
`IDLE
`DETECTED
`DETECTED
`
`
`
`
`
`
` DEVICE ACTIVITY
`
`
`LOCAL DEVICE
`
`SYSTEM FULLY
`
`POWERED OFF
`
`
`POWERED ON
`
`(LOCAL STANDBY)
`STATE O
`
`
` IDLE
`STATE1
`
`
`
`
`
`
`
` PUT SYSTEM
`
`IN SLEEP MODE
`(GLOBAL STANDBY)
`STATE 2
`
`FIG. 2
`
`

`

`U.S. Patent
`
`Dec. 31, 1996
`
`Sheet 3 of 7
`
`5,590,342
`
`WALSAS
`
`CALVNYAgIH
`
`AYVMLIOS
`
`Ot
`
`NOLLVNHASIH
`
`YAWIL
`
`AYVMCYVH
`
`aHVMLAOS
`
`TWEOTD
`
`AGONVLS
`
`W001
`
`AGONVLS
`
`W901
`
`AGGNV.LS
`
`WALSAS
`
`S.LNAAS
`
`
`
`Vi0EeHNLWd01
`
`WaEOTd
`
`SLNSAJ
`
`OVSINI
`
`AddO1d
`
`SLNAAA
`
`10
`
`SOUIHdVHD
`
`SLNAAA
`
`SLNAAI
`
`AOVAYSLNI
`
`WOO!
`
`SLNAAI
`
`OVSLNI
`
`LNSAA‘9
`
`LNSAa7]
`
`LNSAA1
`
`W901
`
`AGaNv_Ls
`
`
`
`ChOeaw
`
`SDIARGOf
`
`SLNSAS
`
`ALOE
`
`YSOVNVAWd
`
`WO01
`
`SiLNAAS
`
`FOVIYSLNI
`
`LNSAZ“1
`
`
`
`(SWgg=OOH!)-MOLLHAWILWSLSAS
`
`
`
`
`
`<
`
`“DE
`
`
`
`
`
`
`
`
`
`
`
`

`

`SPEED-UP
`
`SLOW CLOCK
`
`TIMERS 401|| TIMER 402
`
`
`
`
` SOFTWARE
`
`
`LAYER
`
`USS. Patent
`
`Dec. 31, 1996
`
`Sheet 4 of 7
`
`5,590,342
`
`WINDOWS3.1 O/S
`
`400
`
`LAYER
`
`SLOW CLOCK
`EVENT
`
`SYSTEM
`EVENT
`
`
`SYSTEM
`EVENTS
`
`CPU
`
`HARDWARE
`
`TIMERO
`
`405
`
`FIG. 4
`
`

`

`U.S. Patent
`
`Dec. 31, 1996
`
`Sheet 5 of 7
`
`5,590,342
`
`JAIL
`
`iTPITdf|a———NO
`
`
`440NO
`
`
`4d0
`
`< “
`
`Ora
`
`Ado
`
`WO0TO
`
`Ndo
`
`LWH
`
`NdO
`
`¥O019
`
`

`

`U.S. Patent
`
`Dec. 31, 1996
`
`Sheet 6 of 7
`
`
`
`
`
`NOILVOIddv$00NOLLVOMdd¥SOGST1dSMOGNIM
`
`WASOGWAWALSAS
`
`
`
`SNOLLVOIdd¥SMOGNIM
`
`e-0SONIY
`
`
`
`AMOWGWSCOWv3GaYVHS
`
`i5.x|
`
`
`
`ISHOIAWASWALSAS
`
`
`
`5,590,342
`
`3HYMGHVH
`
`9“Sia
`
`
`
`

`

`U.S. Patent
`
`Dec. 31, 1996
`
`Sheet 7 of 7
`
`5,590,342
`
`DISPLAY
`
`
`fai
`
`MAIN
`MEMORY
`
`READ ONLY
`MEMORY
`
`
`MASS STORAGE
`DEVICE
`
`707
`
`
`
`
`
`
`KEYBOARD
`
`722
`
`
`CURSOR
`CONTROL
`
`
`723
`
`
`
` HARD COPY
`PROCESSOR
`DEVICE
`702
`
`
`724
`
`
`FiG. 7
`
`

`

`5,590,342
`
`1
`METHOD AND APPARATUS FOR
`REDUCING POWER CONSUMPTION INA
`COMPUTER SYSTEM USING VIRTUAL
`DEVICE DRIVERS
`
`FIELD OF THE INVENTION
`
`The present invention relates to the field of computer
`systems; more particularly, the present invention relates to
`reducing power consumption in a computer system using
`device drivers,
`
`BACKGROUND OF THE INVENTION
`
`Typically, a computer system contains a processor, a bus,
`and other peripheral devices. The processor is responsible
`for executing instructions using data in the computer system.
`The bus is used by the processor and the peripheral devices
`for transferring information between one another. The infor-
`mation on the bus usually includes data, address and control
`signals. The peripheral devices comprise storage devices,
`input/output (I/O) devices, etc. Generally, all operations
`being performed in the computer system occur at the same
`frequency.
`Many of today’s computer systems include power man-
`agement capabilities. Power managementis used to reduce
`the dynamic and static power consumption of a system to
`increase the battery life of a mobile personal computer (PC)
`or to reduce the energy costs associated with a desktop PC.
`Dynamic poweris consumedbyall componentsduring state
`switching of internal electronic circuits, while static power
`is consumed due to the leakage currents of electronic
`devices.
`
`The existing power-management techniques in a typical
`notebook and desktop PC use specific hardware mechanisms
`to provide maximum power savings. These hardware
`mechanisms use processor specific interrupts (e.g., System
`Management Interrupt (SMI)) and other system activity
`monitoring hardware (e.g., idle timers and hardware trap-
`ping mechanisms)to provide a reasonable amount of power
`conservation.
`
`Alternatively, some software mechanismsexist, which are
`used today to detect CPU idle conditionsin order to put the
`system in an optimum power conservation mode (e.g.,
`Windows APM driver, DOS POWER.EXE,etc.). Although
`the available software techniques provide for about seventy
`to eighty percent of power conservation, they do not power
`manage a system beyond CPUidleness. That is, they do not
`detect idleness of I/O devices nor turn off idle I/O devices
`during system operation or slow the CPU clockrate, etc.
`In existing power management architecture’s, there are
`several dynamic and static power conservation statcs. One of
`these states is referred to as a fully on or full poweron state,
`in which all the componentsof a typical system are powered.
`In this state, all the clocks in the system will be runningat
`full speed. This state offers no power savings. Anotherstate
`is referred to as a local stand-by, or partially powered-on,
`state, in which certain temporarily idle local devices in the
`system, such as a floppy device, graphics devices (e.g.,
`LCD, CRT), hard disk device, etc. are powered down. The
`power to these tured off devices is restored when an
`internal or external system event requires the services of
`these resources. The system maintainsidle timers for each of
`these power-manageable devices. The idle timers enter an
`expired time-out state when they detect idleness of these
`devices after a pre-defined period of inactivity, and notifies
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`the power management software. This state offers the mini-
`mal amount of power savings in a system. Anotherstate is
`referred to as a global stand-by state, in which most of the
`system devices are powered down with the exception of the
`CPU and the system DRAM memory. Theclock to the CPU
`is
`stopped with the DRAM memory operating in an
`extended power conservation mode, sometimes referred to
`as stand-by modewith self refresh. At this pointin time, the
`CPU and DRAM areready to be activated when a system
`event occurs. An example of such a system event is a
`keyboard/mouse click or other system interrupts (€.g.,
`TRQO-IRQ15, NMI, SMI,etc.). The last power management
`state is referred to as hibernation, where the system is put in
`the power-off state. When a system detects an idle condition,
`after a predetermined period of time in the global stand-by
`mode, it can initiate a transfer to the hibernation state. In
`such a state, complete system state is saved to the hard disk.
`When the system is turned back on, the hibernation state
`restores the system back to exactly the samestate as it was
`before.
`
`Dynamic clock throttling is the state where the dynamic
`power consumed by a CPU is reduced by slowingits clock
`rate. A slow clock to the CPU is emulated by periodic
`assertion and de-assertion of a stpclk (stop clock) signal.
`This slow clock emulation leads to less power consumption
`by the overall system. This modeis activated during normal
`operation of a system andit is overlapped with a fully-on
`State to offer additional power savings during the fully-on
`state.
`
`As shownabove,the prior art system of power manage-
`ment requires the detection of local and global system
`events. This is typically handled by special hardware or
`power-aware applications and device drivers. The detection
`of system idleness for global stand-by is accomplished by
`monitoring their interrupt activity in software or hardware
`using existing methods. If none of the system interrupts are
`activated in a predeterminedoftime,a global stand-by event
`is generated by the chosen hardware or software mechanism.
`Local activity of individual I/O devices is detected mostly
`by dedicated power management hardware. The hardware
`snoops on I/O device resources (e.g., VO addresses and
`TRQx, etc.). The mapping of the resources is static and
`deterministic and knownat system boot-up time. These I/O
`resource mappings do not change overthe lifetime of the
`current system boot. In certain power management imple-
`mentations, the snoop I/O addresses are programmable in
`the I/O hardware, while they are fixed in other systems. The
`deterministic nature of the mappings of these I/O resources
`of the local devices (as per PC-AT/DOSstandards) makesit
`easy to design standard hardware which is consistent across
`all PC DOS platforms.
`inherent
`These described methodologies have several
`problems. For instance, each of the I/O devices needsan idle
`timer to monitor the activity. This imposesa restriction on a
`number of hardware timers that can be designed into the
`system. Also, most implementations hardcode the V/O trap-
`ping addressof the I/O devices to save “gates”. This makes
`a system more sensitive to remapping of the I/O resources.
`Furthermore, the existing mechanisms assume that all I/O
`devices use standard I/O resource mappings over the life-
`time of the system,i.e., static I/O and IRQx mapping. This,
`in fact, places a severe restriction on the usage of the system
`resources and demands perfect hardware compatibility
`across all platforms.
`Power management software in the traditional system is
`completely decoupled from the operating system and appli-
`cation. This makes the system proneto the operating system
`
`

`

`5,590,342
`
`3
`and power managementsoftware performingactivities, with
`neither of them being aware of the activities being per-
`formedby the other. This may lead to system crashes where
`a power management interrupt, such as SMI, takes control
`away from the operating system while it is executing in the
`middle of a critical section of code.
`
`The current generation of device drivers in operating
`systems virtualize I/O ports. When the I/O ports are virtu-
`alized, it becomes difficult, and in some cases impossible,
`for the power managementsoftware and hardware to detect
`any possible remappings. This leads the power management
`hardware to monitor and trap on invalid YO device
`addresses, thereby generating improper events in the system.
`In a plug-and-play environment,it is assumed that the I/O
`device resource mappings (//O and IRQx) are no longer
`deterministic or visible to the power management software
`at system boot-up time. Current and future generations of
`operating systems will be based on plug-and-play architec-
`tures, where the I/O resource mapping can and will change
`dynamically during the lifetime of the current system boot.
`Whenthese dynamic remappings of I/O devices do occur,
`there is currently no easy way to communicate to the power
`management hardware and software.
`tech-
`Also, -the existing software power-management
`niques assumethat the applications of the associated device
`drivers in the system are APM and PMC aware. This makes
`it difficult to manage a system with applications and drivers
`which are not power aware.
`
`SUMMARYOF THE INVENTION
`
`A power management mechanism for use in a computer
`system is described. The computer system comprisesa bus,
`a memory for storing data and instructions, and a central
`processing unit (CPU). The CPU runs an operating system
`having a power management virtual. device driver
`(PMVxD)responsible for performing idle detection for
`devices. The PMVxD performsidle detection using event
`timers that provide an indicatoras to the activity level. The
`PMYVxD places idle local devices in a reduced power
`consumption state when no activity has occurred for a
`predetermined period of time.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`Thepresent invention will be understood more fully from
`the detailed description given below and from the accom-
`panying drawings of various embodiments of the invention,
`which, however, should not be taken to limit the invention
`to the specific embodiments, but are for explanation and
`understanding only.
`FIG.1 illustrates one embodiment of the power manage-
`ment architecture of the present invention.
`FIG. 2 illustrates one embodiment of the power manage-
`ment states of the present invention.
`FIG.3 illustrates an embodiment of the power manage-
`ment control of the present invention.
`FIG.4 illustrates one embodiment of the dynamic clock
`throttling mechanism of the present invention.
`FIG. 5 illustrates a timing diagram of the CPU clock
`throttling.
`FIG. 6 a conceptual diagram of the Windowsoperating
`system in enhanced mode.
`FIG. 7 is a block diagram of one embodiment of the
`computer system of the present invention.
`
`10
`
`30
`
`45
`
`50
`
`35
`
`60
`
`65
`
`4
`DETAILED DESCRIPTION OF THE PRESENT
`INVENTION
`
`A method and apparatus for reducing power consumption
`in a computer system is described. In the following detailed
`description of the present
`invention numerous specific
`deiails are set forth, such as types of I/O devices, idle time
`periods,interrupt types, power managementstates, etc., in
`order to provide a thorough understanding of the present
`invention. However, it will be appreciated by one skilled in
`the art that the present invention may be practiced without
`these specific details. In other instances, well-knownstruc-
`tures and devices are shown in block diagram form,rather
`than in detail,
`in order to avoid obscuring the present
`invention.
`
`Someportions of the detailed descriptions which follow
`are presented in terms of algorithms and symbolic repre-
`sentations of operations on data bits within a computer
`memory. These algorithmic descriptions and representations
`are the means used by those skilled in the data processing
`arts to most effectively convey the substance of their work
`to others skilled in the art. An algorithm is here, and
`generally, conceived to be a self-consistent sequence ofsteps
`leading to a desired result. The steps are those requiring
`physical manipulations of physical. quantities. Usually,
`though not necessarily, these quantities take the form of
`electrical or magnetic signals capable of being stored, trans-
`ferred, combined, compared, and otherwise manipulated. It
`has proven convenient at times, principally for reasons of
`common usage, to refer to these signals as bits, values,
`elements, symbols, characters, terms, numbers, or the like.
`It should be borne in mind, however,that all of these and
`similar terms are to be associated with the appropriate
`physical quantities and are merely convenient labels applied
`to these quantities. Unless specifically stated otherwise as
`apparent from the following discussions, it is appreciated
`that throughout the present invention, discussionsutilizing
`terms suchas “processing” or “computing” or“calculating”
`or “determining” or “displaying” or the like, refer to the
`action and processes of a computer system, or similar
`electronic computing device, that manipulates and trans-
`forms data represented as physical (electronic) quantities
`within the computer system’s registers and memories into
`other data similarly represented as physical quantities within
`the computer system memories or registers or other such
`information storage, transmission or display devices.
`The present invention also relates to apparatus for per-
`forming the operations herein. This apparatus may be spe-
`cially constructed for the required purposes, or it may
`comprise a general purpose computer selectively activated
`or reconfigured by a computer program stored in the com-
`puter. The algorithms and displays presented herein are not
`inherently related to any particular computer or other appa-
`ratus. Various general purpose machines may be used with
`programsin accordance with the teachings herein, or it may
`prove convenient to construct more specialized apparatus to
`perform the required method steps. The required structure
`for a variety of these machines will appear from the descrip-
`tion below.
`In addition,
`the present
`invention is not
`described with reference to any particular programming
`language.It will be appreciated that a variety of program-
`ming languages may be used to implementthe teachings of
`the invention as described herein.
`Overview of the Present Invention
`The present invention provides for power managementin
`a computer system using virtual device drivers (VxDs). In
`one embodiment, the VxDs of the present invention are
`
`

`

`5,590,342
`
`20
`
`25
`
`35
`
`6
`5
`system hardware is represented as a level. The Ring0level
`provided in the Windows™operating system manufactured
`with the Kernel and virtual device drivers (VxDs) is also
`by Microsoft® Corporation of Redmond, Wash. The present
`shown, along with the system virtual machine and the
`invention provides a power management VxD that controls
`various DOS virtual machines. Windows creates DOS vir-
`at least a portion of the power managementin the computer
`tual machines by mapping DOS, device drivers, and TSR
`system. Power management
`in the present invention is
`programsin the system VM into the DOS VMs. Therefore,
`facilitated by the I/O/interrupt/VxD trapping capabilities of
`all the virtual machines share a region of memory called the
`the VxDs running in the protected mode of the CPU atthe
`shared real mode memory.
`highest privileged level of the operating system in an
`The Virtual device drivers (VxDs) at ring 0 are a special
`operating system co-operative manner. The VxD operates at
`feature of Microsoft® Windows enhanced mode. A virtual
`the CPU’s highest privileged level (ring 0). Therefore, the
`device driver is actually a routine which manages a system
`VxD of the present invention has access and control over
`resource such that more than one application can use the
`system hardware and software components. This enables it
`system resource at a time. Virtual device drivers therefore
`to operate and respond to power management events much
`support Windows’ ability to act as a multitasking operating
`faster, with low task switching overheads. In one embodi-
`system. The virtual device drivers, including the VxD of the
`ment, not only does the VxD interface to other software
`present invention, have access to a wide range of kernel
`(e.g., applications), but it also provides an API interface to
`services,
`including those
`for hardware management,
`both real/protected mode programs.
`memory management, task scheduling, and communicaling
`The present invention allows software to power-manage a
`with other virtual devices.
`system with applications and device drivers which are not
`Asillustrated in FIG. 6, all the Windowsapplications run
`power-aware. In addition, software operates cooperatively
`within the system virtual machine which operates in pro-
`with the existing power-management software infrastructure
`tected mode. The Windows Dynamic Link Libraries (DLLs)
`such as, for instance, Advanced Power Managementspeci-
`which support Windows applications also run within the
`fication (APM 1.1), Power Management Coordinator
`(PMC), etc.
`system virtual machine.
`The Windows Environment
`Each DOSapplication in FIG.6 runs within its own DOS
`virtual machine. Since the DOS virtual machines usually
`The Microsoft® Windows operating environment pro-
`operate in the Virtual 8086 mode of the microprocessor,the
`vides a graphical user interface (GUI) which makes Win-
`DOSapplications generally only address the 1 Megabyte of
`dowsapplication programs easier to use. Microsoft® Win-
`memory in the DOS virtual machine.
`dows environment runs Windowsapplications located in the
`Power Management Architecture
`extended area of memory above the 1 megabyte boundary
`The power managementarchitecture of the present inven-
`using the protected mode of a processor, such as an Intel
`tion is shown in FIG. 1. Referring to FIG. 1, various
`Architecture Microprocessor, manufactured by Intel Corpo-
`power-aware applications (101, 102) shown make use of an
`ration of Santa Clara, Calif., the corporate assignee of the
`APM/PMCdevice driver 103 at the operating system soft-
`present invention.
`ware layer. A power-aware device driver 106 also makes use
`The Microsoft® Windows 3.1 system can operate in one
`of two modes: “standard” mode and “enhanced” mode. The
`of APM/PMC device driver 103 atl the operating system
`software layer. The APM BIOS(Basic Input/Output System)
`standard mode exists so that personal computers equipped
`hardware 104 controls the APM/PMC device driver 103.
`with older 80286 processors can use the Windowsenviron-
`ment. The enhanced mode of Microsoft® Windowsis used
`The APM BIOS 104 also controls hardware 105.
`Also shown in FIG. 1, power-unaware applications
`when Microsoft® Windows is run on a computer system
`110-112 communicate with PMVxD power management
`which uses an 80386 microprocessor or more recently
`software 113. The PMVxD power management software 113
`available microprocessors such as, for instance, the i486™
`processor.
`communicates with a Plug-n-Play (P-n-P) configuration
`manager 114 and the APM/PMCdevice driver 103 in the
`The enhanced mode of Microsoft® Windowsoperates in
`operating system software layer. The PMVxD power man-
`the protected mode of the Intel Architecture Microproces-
`agement software 113 controls hardware. The PMVxD
`sors (e.g., 1386™ processor, i486™ processor, etc.). In this
`manner, the enhanced mode of Microsoft® Windowstakes
`power management software 113 controls the VxD con-
`trolled hardware 115 and 116 as well as the power manage-
`advantage of features in the Intel Architecture Microproces-
`ment hardware 117 at the hardware layer. In one embodi-
`sors to offer virtual memory and multitasking operation. The
`ment,
`the VxD controlled hardware 115 and 116 have
`processor hardware supports execution of several Windows
`built-in power management capabilities in the form of a
`applications in protected mode.
`switch and only needs some type of signal to enable them.
`The enhanced mode of Microsoft® Windows supports
`In one embodiment, the power management hardware 117
`DOSapplications using “DOS virtual machines. ” In a DOS
`may include hardware necessary for placing certain [/O
`Virtual Machine,
`the Intel Architecture Microprocessor
`devices in a reduced power consumptionstate.
`operates in Virtual 8086 mode anduses the virtual memory
`feature to provide DOS, device drivers, and Terminate and
`The present invention provides for placing a computer
`system in various power management states, or modes of
`Stay Resident (TSR) programsoriginally loaded into the
`operation, using a virtual device driver (VxD)that has I/O,
`computer to a DOS virtual machine in extended memory.
`device driver and interrupt trapping capabilities. In one
`Windows uses the virtual memory system to make the
`application area and the DOS, device drivers, and TSR
`embodiment, the VxD provides support for four power
`management modes: fully-on, local standby, global standby
`programs appear to be a single contiguous block of real
`and hibernation. The PMVxDofthe present invention also
`mode memory. When the microprocessor is operating in
`Virtual 8086 mode within the address area of DOS virtual
`provides support for clock throttling. The present invention
`may support, only one or more of these modes. Furthermore,
`machine, the Virtual 8086 mode microprocessor in unaware
`the use of the clock throttling mode depends on whetherthe
`of any memory outside of the DOS virtual machine.
`processor in a computer system includes the required func-
`FIG. 6 provides a conceptual diagram of the Windows
`tionality to provide such a feature (i-e., repeatedly issuing a
`system in enhanced mode. Referringto FIG. 6, the computer
`
`40
`
`45
`
`50
`
`55
`
`65
`
`

`

`5,590,342
`
`7
`HALT command to the CPU). One embodiment of the
`power managementstates of the present invention areillus-
`trated in the state diagram in FIG.2.
`Referring to FIG. 2, state 1 is the fully powered-on state.
`While the system is active, the computer system remains in
`the fully powered-on state. Whether the system is active is
`based on device activity of local devices as well as system
`activity (e.g., keyboard stroke, mouse movement, etc.) Once
`one or more local devices are determined to be idle, the
`computer system transitions to state 2 where each idle local
`device is powered off, such that the computer system enters
`the local standby state with respect to those powered down
`devices. The computer system remains in local standby
`while a local device is idle. As soon as the local device is no
`longeridle, the computer system transitions back to the fully
`powered on state. When the computer system determines
`that the entire system is idle (e.g., all the local devices are
`idle), the computer system transitions to state 2 to enter
`global standby. In global standby, the system is placed in
`sleep mode, where it remains until system activity is
`detected. At that time, the computer system returns to the
`fully powered on state (0).
`In another embodiment, the system transitions from the
`local standby state directly to the global standby state. That
`is, the computer system does not reenter the fully powered
`on state before entering global standby.
`The Power ManagementVirtual Device Driver PMVxD)
`The present invention comprises a power management
`virtual device driver (PMVxD) and a set of data structures.
`The data structures are initialized at system boot-up time to
`provide command/status information to the PMVxD. The
`PMVxDcontrols power management and comprises several
`software idle timers, one for each enabled I/O device. The
`idleness of a particular device is detected by monitoring the
`activity of each of the enabled I/O devices. The monitoring
`of the enabled I/O devices may be performed by one of the
`following: I/O port address trapping, chaining into I/O
`device interrupt handlers, trapping on J/O devices driver
`(VxD) accesses, and chaining into I/O protection fault
`handler, each of which is well-knownin theart.
`Mostofthese capabilities are provided to the VxD asa set
`of VMM and VxD service calls, which are standard Win-
`dows™ device driver support.
`The PMVxDis chained into the system timer interrupt,
`which provides the time base for all PMVxD counters. In
`one embodiment, the PMVxD uses the occurrence of the
`IRQO to indicate when to monitor the activity of each YO
`device and also the overall system activity for local and
`global standby modes. In one embodiment, the IRQO occurs
`every 55 ms. Thus, in this embodiment, a power manage-
`ment manager of the PMVxD checks every 55 ms to
`determine whetherthe local devices have been orareactive
`and whether the system as a whole has been oris active. If
`a device has been inactive for a predetermined period of
`time, the power management manager of the PMVxDcon-
`trols the powering downof the device. The predetermined
`period of time maybe of variable length and is set based on
`the desired power savings. Different periods of time may be
`associated with different devices.
`The PMVxDinstalls handlers for I/O trapping to the I/O
`port of each device. Anytime an I/O port access is trapped,
`a corresponding counter is updated (increment/decrement)
`to reflect the activity status. For I/O devices whose I/O
`addresses are virtualized, PMVxD interrupt handler stubs
`(e.g., small pieces of code stored in memory atall times) can
`be chained into the original interrupt handlers for each
`specific I/O device. This PMVxDstub handler maintains the
`
`20
`
`25
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`idlenessof an I/O device, for example, Floppy Disk interrupt
`OEh.The use and operation of a stub handler is well-known
`in the art.
`FIG.3 illustrates the power management control over-
`view. Referring to FIG. 3,
`the PMVxD 301 is shown
`controlling hardware 302. Software 303 also controls hard-
`ware 302 and places hardware 302 in hibernation mode in
`cooperation with hibernation timer 304. The PMVxD 301
`comprises software timers, including a system events timer
`301A and multipie local events timers, such as a floppy
`events timer 301B, graphics events timer 301C and I/O
`device timer 301D. Each of the local events timers (e.g.,
`301B-D) monitor local events via an I/O trap handler, a
`device driver hook handler or a chained-interrupt trap han-
`dier as an interface. This interface increments and decre-
`ments the software timers. The system events timer 301A
`monitors global events via an interface, which may also be
`either an I/O trap handler, a device driver hook handler or a
`chained-interrupt trap handler. Note that in one embodiment
`only one of these is employed for each global or local events
`timer.
`At a regular interval, such as at every 55 ms correspond-
`ing to the occurrence of the IRQO, the power management
`(PM) manager 301E checksthe status of each of the events
`timers (e.g., 301A-D). When an events timer times-out, the
`PMVxD mayturn off the powerto the I/O device. Thatis,
`PM manager 301E causes a handler for that event timer to
`be called. This handler controls the dedicated hardware in
`hardware 302 for removing powerto the I/O device. When
`activity is detected, PM manager 301E calls the handler
`again to powerup the device. Similarly if the system events
`timer times out, PM manager 103E calls the global standby
`handler associated with the system events timer, which when
`tun causes the clock to the CPU to be stopped in a manner
`well-knownin the art, such that the CPU is halted.
`When the CPU hasbeenhalted, the hibernation timer 304
`is started. If the hibernation timer times out, an interrupt
`occurs, such as a system managementinterrupt (SMI) in one
`embodiment. Software 303 for the interrupt places the
`system in a hibernated state. In response to a system event
`such as, for instance, a keyboard input or cursor control
`device movement, the computer system exits the hibernation
`state and the global standby state.
`PMVxD301 also includes a slow clock timer 310 for use
`with the clock throttling mode. The slow clock timer 310is
`described below.
`With respect to Plug-and-Play Compliance, the PMVxD
`is part of the O/S and appears as a device driver in the
`system. In a Plug-and-play environment, when the system
`resources afte remappedto the I/O devices, the PMVxD is
`informed of the changes by the O/S specific configuration
`manager or resource manager. This well-defined interface
`mechanism between the O/S and PMVxD allows it to
`dynamically adapt itself to the changes gracefully. The
`present invention provides such capability by having the
`PMVxD register with the configuration manager (CM) and
`instructs the configuration manager to notify it when there
`has been a configuration change. The PMVxD responds to
`the notification in the same manner as when examining the
`data structures at system boot-up time.
`DynamicClock Throttling
`FIG.4 illustrates the dynamic clock throttling mechanism
`of the present invention. Referring to FIG. 4, dynamic clock
`throttling is accomplished by the PMVxDoperating in the
`Windows 3.1 O/S 400 with support from the standard PC
`hardware. Periodic assertion of CPU HALT to CPU 404 by
`the slow clock timer 402 emulates a slower clock timer
`
`

`