You are on page 1of 7

Advanced Configuration and Power Interface

(ACPI) Introduction and Overview


Version1.4:26April2016
Copyright2016IntelCorporation.Allrightsreserved.
*Othernamesandbrandsmaybeclaimedasthepropertyofothers.

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.

Thermal event example


ACPIincludesathermalmodeltoallowsystemstocontrolthesystemtemperatureeither
actively(byperformingactionsliketurningafanon)orpassivelybyreducingtheamountof
powerthesystemuses(byperformingactionslikethrottlingtheprocessor).Wecanusean
exampleofagenericthermaleventshowninFigure5todemonstratehowtheACPIruntime
modelworks.


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.

You might also like