Professional Documents
Culture Documents
ThischapterprovidesahighleveloverviewoftheAdvancedConfigurationandPower
Interface
(ACPI).TomakeiteasiertounderstandACPI,thissectionfocusesonbroadand
generalstatementsaboutACPIanddoesnotdiscusseverypossibleexceptionordetail
aboutACPI.TherestofthetheACPIspecificationprovidesmuchgreaterdetailaboutthe
innerworkingsofACPIthanisdiscussedhere,andisrecommendedreadingfordevelopers
usingACPI.
History of ACPI
ACPIwasdevelopedthroughcollaborationbetweenIntel,Microsoft*,Toshiba*,HP*,and
Phoenix*inthemid1990s.BeforethedevelopmentofACPI, operatingsystems (OS)
primarilyused BIOS(BasicInput/OutputSystem)interfacesforpowermanagementand
devicediscoveryandconfiguration.ThispowermanagementapproachusedtheOSsability
tocallthesystemBIOSnativelyforpowermanagement.TheBIOSwasalsousedtodiscover
systemdevicesandloaddriversbasedonprobing input/output
(I/O)andattemptingtomatch
thecorrectdrivertothecorrectdevice(plugandplay).Thelocationofdevicescouldalsobe
hardcodedwithintheBIOSbecausetheplatformitselfwasnonenumerable.
Thesesolutionswereproblematicinthreekeyways.First,thebehaviorofOSapplications
couldbenegativelyaffectedbytheBIOSconfiguredpowermanagementsettings,causing
systemstogotosleepduringpresentationsorotherinconvenienttimes.Second,thepower
managementinterfacewasproprietaryoneachsystem.Thisrequireddeveloperstolearn
howtoconfigurepowermanagementforeachindividualsystem.Finally,thedefaultsettings
forvariousdevicescouldalsoconflictwitheachother,causingdevicestocrash,behave
erratically,orbecomeundiscoverable.
ACPIwasdevelopedtosolvetheseproblemsandothers.
What is ACPI?
ACPIcanfirstbeunderstoodasanarchitectureindependentpowermanagementand
configurationframeworkthatformsasubsystemwithinthehostOS.Thisframework
establishesahardwareregistersettodefinepowerstates(sleep,hibernate,wake,etc).The
hardwareregistersetcanaccommodateoperationsondedicatedhardwareandgeneral
purposehardware.
TheprimaryintentionofthestandardACPIframeworkandthehardwareregistersetisto
enablepowermanagementandsystemconfigurationwithoutdirectlycallingfirmwarenatively
fromtheOS.ACPIservesasaninterfacelayerbetweenthesystemfirmware(BIOS)andthe
OS,asshowninFigure1andFigure2,withcertainrestrictionsandrules.
Figure1:ACPIoverview
Fundamentally,ACPIdefinestwotypesofdatastructureswhicharesharedbetweenthe
systemfirmwareandtheOS: datatables definitionblocks.
and Thesedatastructuresarethe
primarycommunicationmechanismbetweenthefirmwareandtheOS.Datatablesstoreraw
dataandareconsumedbydevicedrivers.Definitionblocksconsistofbytecodethatis
executablebyaninterpreter.
Figure2:ACPIstructure
ACPISourceLanguage
Thisdefinitionblockbytecodeiscompiledfromthe (ASL)code.ASL
isthelanguageusedtodefineACPIobjectsandtowritecontrolmethods.AnASLcompiler
translatesASLintoACPIMachineLanguage (AML)bytecode.AMListhelanguage
processedbytheACPIAMLinterpreter,asshowninFigure3.
Figure3:ASLandAML
TheAMLinterpreterexecutesbytecodeandevaluatesobjectsinthedefinitionblocksto
allowthebytecodetoperformloopconstructs,conditionalevaluations,accessdefined
addressspaces,andperformotheroperationsthatapplicationsrequire.TheAMLinterpreter
hasread/writeaccesstodefinedaddressspaces,includingsystemmemory,I/O,PCI
configuration,andmore.Itaccessestheseaddressspacesbydefiningentrypointscalled
objects.Objectscaneitherhaveadirectlydefinedvalueorelsemustbeevaluatedand
interpretedbytheAMLinterpreter.
ThiscollectionofenumerableobjectsisanOSconstructcalledtheACPInamespace.The
namespaceisahierarchicalrepresentationoftheACPIdevicesonasystem.Thesystem
busistherootofenumerationfortheseACPIdevices.Devicesthatareenumerableonother
buses,likePCIorUSBdevices,areusuallynotenumeratedinthenamespace.Instead,their
ownbusesenumeratethedevicesandloadtheirdrivers.However,allenumerablebuses
haveanencodingtechniquethatallowsACPItoencodethebusspecificaddressesofthe
devicessotheycanbefoundinACPI,eventhoughACPIusuallydoesnotloaddriversfor
thesedevices.
hardwareidentification
Generally,devicesthathavea_HIDobject( object)areenumerated
andhavetheirdriversloadedbyACPI.Devicesthathavean_ADRobject( physicaladdress
object)areusuallynotenumeratedbyACPIandgenerallydonothavetheirdriversloadedby
ACPI._ADRdevicesusuallycanperformallnecessaryfunctionswithoutinvolvingACPI,but
incaseswherethedevicedrivercannotperformafunction,orifthedriverneedsto
communicatetosystemfirmware,ACPIcanevaluateobjectstoperformtheneededfunction.
Asanexampleofthis,PCIdoesnotsupportnativehotplug.However,PCIcanuseACPIto
evaluateobjectsanddefinemethodsthatallowACPItofillinthefunctionsnecessaryto
performhotplugonPCI.
AnadditionalaspectofACPIisaruntimemodelthathandlesanyACPIinterrupteventsthat
occurduringsystemoperation.ACPIcontinuestoevaluateobjectsasnecessarytohandle
theseevents.Thisinterruptbasedruntimemodelisdiscussedingreaterdetailinthe
Runtimemodel sectionbelow.
ACPI initialization
ThebestwaytounderstandhowACPIworksischronologically.Themomenttheuser
powersupthesystem,thesystemfirmwarecompletesitssetup,initialization,andselftests.
Figure4:ACPIinitialization
Thesystemfirmwarethenusesinformationobtainedduringfirmwareinitializationtoupdate
theACPItablesasnecessarywithvariousplatformconfigurationsandpowerinterfacedata,
beforepassingcontroltothebootstraploader.The extendedrootsystemdescriptiontable
(XSDT)isthefirsttableusedbytheACPIsubsystemandcontainstheaddressesofmostof
theotherACPItablesonthesystem.TheXSDTpointstothe fixedACPIdescriptiontable
(FADT)aswellasothermajortablesthattheOSprocessesduringinitialization.AftertheOS
initializes,theFADTdirectstheACPIsubsystemtothe differentiatedsystemdescriptiontable
(DSDT),whichisthebeginningofthenamespacebecauseitisthefirsttablethatcontainsa
definitionblock.
TheACPIsubsystemthenprocessestheDSDTandbeginsbuildingthenamespacefromthe
ACPIdefinitionblocks.TheXSDTalsopointstothe secondarysystemdescriptiontables
(SSDTs)andaddsthemtothenamespace.TheACPIdatatablesgivetheOSrawdata
aboutthesystemhardware.
AftertheOShasbuiltthenamespacefromtheACPItables,itbeginstraversingthe
namespaceandloadingdevicedriversforallthe _HID devicesitencountersinthe
namespace.
Runtime model
Afterthesystemisupandrunning,ACPIworkswiththeOStohandleanyACPIinterrupt
eventsthatoccurviatheACPI systemcontrolinterrupt(SCI)handler.Thisinterruptinvokes
ACPIeventsinoneoftwogeneralways:fixedeventsand generalpurposeevents (GPEs).
TheSCIismultiplexedthroughoutthesystemtomanageACPIinterruptevents.
FixedeventsareACPIeventsthathaveapredefinedmeaningintheACPIspecification.
ThesefixedeventsincludeactionslikepressingthepowerbuttonorACPItimeroverflows.
TheseeventsarehandleddirectlybytheOShandlers.
GPEsareACPIeventsthatarenotpredefinedbytheACPIspecification.Theseeventsare
usuallyhandledbyevaluatingcontrolmethods,whichareobjectsinthenamespaceandcan
accesssystemhardware.WhentheACPIsubsystemevaluatesthecontrolmethodwiththe
AMLinterpreter,theGPEobjecthandlestheeventsaccordingtotheOSsimplementation.
Typicallythismightinvolveissuinganotificationtoadevicetoinvokethedevicedriverto
performafunction.
Wediscussagenericexampleofthisruntimemodelinthenextsection.
Figure5:Runtimethermalevent
TheACPIthermalzoneincludescontrolmethodstoreadthecurrentsystemtemperatureand
trippoints.
1. WhentheOSinitiallyfindsathermalzoneinthenamespace,itloadsthethermal
zonedriver,whichevaluatesthethermalzonetoobtainthecurrenttemperatureand
trippoints.
2. Whenasystemcomponentheatsupenoughtotriggeratrippoint,athermalzone
GPEoccurs.
3. TheGPEcausesaninterruptviatheSCItooccur.WhentheACPIsubsystem
receivestheinterrupt,itfirstcheckswhetheranyfixedeventshaveoccurred.Inthis
example,thethermalzoneeventisaGPE,sonofixedeventhasoccurred.
4. TheACPIsubsystemthensearchesthenamespaceforthecontrolmethodthat
matchestheGPEnumberoftheinterrupt.Uponfindingit,theACPIsubsystem
evaluatesthecontrolmethod,whichmightthenaccesshardwareand/ornotifythe
thermalzonehandler.
5. Theoperatingsystemsthermalzonehandlerthentakeswhateveractionsare
necessarytohandletheevent,includingpossiblyaccessinghardware.
ACPIisaveryrobustinterfaceimplementation.Thethermalzonetrippointcouldnotifythe
systemtoturnonafan,reduceadevicesperformance,readthetemperature,shutdownthe
system,oranycombinationoftheseandotheractionsdependingontheneed.
ThisruntimemodelisusedthroughoutthesystemtomanagealloftheACPIeventsthat
occurduringsystemoperation.
Summary
ACPIcanbestbedescribedasaframeworkofconceptsandinterfacesthatareimplemented
toformasubsystemwithinthehostOS.TheACPItables,handlers,interpreter,namespace,
events,andinterruptmodeltogetherformthisimplementationofACPI,creatingtheACPI
subsystemwithinthehostOS.Inthissense,ACPIistheinterfacebetweenthesystem
hardware/firmwareandtheOSandOSapplicationsforconfigurationandpower
management.ThisgivesvariousOSastandardizedwaytosupportpowermanagementand
configurationviatheACPInamespace.
TheACPInamespaceistheenumerable,hierarchicalrepresentationofallACPIdeviceson
thesystemandisusedtobothfindandloaddriversforACPIdevicesonthesystem.The
namespacecanbedynamicbyevaluatingobjectsandsendinginterruptsinrealtime,all
whilerestrictingtheOSfromcallingnativesystemfirmwarecode.Thisenablesdevice
manufacturerstocodetheirowninstructionsandeventsintodevices.Italsoreduces
incompatibilityandinstabilitybyimplementingastandardizedpowermanagementinterface.