Jump to content
Sign in to follow this  
Followers 0
irrational John

Acronyms. Yep, ACPI's got 'em!

1 post in this topic

Recommended Posts

I've debated whether or not to bother about this, and finally decided to also just give it a try.


This is a "place-holder" entry. The plan is I'll update as I go with various ACPI related acronyms I run into. Not sure how much or even if any description I'll provide. Whatever seems to be worth the trouble at the time, I expect.


ACPI related (pretty much) acronyms

  1. ACPI Advanced Configuration and Power Interface
  2. OSPM Operating System-directed configuration and Power Management
  3. AML ACPI Machine Language (a compact, tokenized, abstract type of interpreted machine language)
  4. ASL ACPI Source Language (what we're sorta all trying to figure out :dev: )
  5. DSDT Differentiated System Description Table
  6. PIC Programmable Interrupt Controller (right?)
  7. APIC Advanced Programmable Interrupt Controller
    • I/O APIC An Input/Output Advanced Programmable Interrupt Controller routes interrupts from devices to the processor’s local APIC.

[*]SAPIC Streamlined Advanced Programmable Interrupt Controller (An advanced APIC commonly found on Intel Itanium Processor Family-based 64-bit systems)

  • I/O SAPIC An Input/Output Streamlined Advanced Programmable Interrupt Controller routes interrupts from devices to the processor’s local APIC.

[*]UEFI Unified Extensible Firmware Interface

[*]System Control Interrupt (SCI)

[*]System Management Interrupt (SMI)




ACPI System Description Tables (Section 5.2)

In addition to the above these are a large number of acronyms used to refer to specific ACPI Tables. Decided in would be clearer to separate those into a separate list.

  1. Root System Description Pointer (RSDP)
  2. System Description Table Header
  3. Root System Description Table (RSDT) Hewlett-Packard/Intel/Microsoft/Phoenix/Toshiba
  4. Fixed ACPI Description Table (FADT)
  5. Firmware ACPI Control Structure (FACS)
  6. Differentiated System Description Table (DSDT)
  7. Secondary System Description Table (SSDT)
  8. Multiple APIC Description Table (MADT)
  9. Smart Battery Table (SBST)
  10. Extended System Description Table (XSDT)
  11. Embedded Controller Boot Resources Table
  12. System Resource Affinity Table (SRAT)
  13. System Locality Information Table (SLIT)


Special Purpose Identifiers in the ACPI namespace

(Note: the "(?)" indicates the definition was given anecdotally as opposed to taking it from a (ACPI) spec.)

  1. LDRC ==> LPC Device Resource Consumption (?)
    LPC is the Low Pin Count controller. this is where all older ISA devices are located. LPT, COM, thermal ASIC (application specific integrated circuits) for thermal monitoring, etc. LPC lowers the pin count of the integral devices and allows them to be able to use PCI tranfers and sometimes ISA for compatiblity.
    Intel "Low Pin Count Interface"
    Intel Low Pin Count (LPC) Interface Specification PDF (54 pages)
  2. PDRC ==> PCI Device Resource Consumption (?)

Share this post

Link to post
Share on other sites
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By irrational John
      I'm having trouble making headway in the forums. While the ACPI spec is a pain, it at least tries to make a coherent (in its way) presentation of the info. Not so the forums. I'm afraid it is just not in their nature to be easy to follow and/or accurate and/or comprehensive. It's more like a bunch of overlapping conversations at a geek cocktail party.
      Since I easily loose track of where I've been or what I intended to follow up on later, this entry is an attempt to stash links to some "posts of possible interest" (to me) in the insanelymac forum.
      Note Bene: Anything in this entry could change without notice at any time. It's not meant to guide others so much as to jog my memory when needed.
      Last update: Thursday, 10 December 2009
      A link back to the "hacking required" Lifehacker article.
      Entire threads which looked interesting (and which I also will probably never get around to completely reading )
      the vanilla OS X install guide I used (post-LifeHacker ) (new posts)
      DSDT - Vanilla Speedstep - Generic Scope (_PR) (new posts)
      Getting Snow Leopard to recognize your CPU, No more "Unknown", No About This Mac/System Profiler editing. (new posts)
      DSDT Patcher, a tool to fix your DSDT (new posts)
      DSDT fixes for Gigabyte boards (new posts)
      Specific "summary" posts which the owners aperiodically update

      Master Chief's big honkin' post for an ASUS P5K PRO DSDT (Snow Leopard specific)
      (the P5K Pro is an older/discontinued Intel P35/ICH9R motherboard)
      OSX Flags List for Darwin Bootloader & kernel level
      Possibily useful tools and ASL "tips 'n tricks"

      lspci updates?
      Dumping debug info via an ASL kludge??
      ASL for a DB-9 serial port (... wonder if I want this?)
      -irrational john
    • By irrational John

      I recall a silly and, in hindsight, offensively objectifying t-shirt from decades ago. It was simply the text "Watch This Space!" on the chest of the shirt. I assume it was expected to be worn by young ladies in eager anticipation of pubescence. Ah, youth.
      I've never written a blog before and frankly I don't really think I'm starting one now. My intent is more to collect some notes to help me organize my thoughts as I grapple with shoe horning OS X onto a "PC" motherboard.
      A favorite teacher of mine once quipped about taking notes with the intent of throwing them out immediately after a presentation. The idea was that the act of writing things down in and of itself causes your thoughts to be processed differently. Probably because your thinking goes through different pathways in your brain when you write as opposed to just reading about something.
      That's how I intend to try to use this space here. In other words, primarily as a potential aid for my comprehension, not communication per se.
      Not that I'm in any way opposed to communication. Hey, if communication happens, well, golly gee wilikers, that would be just swell! I'm just not expecting or advertising that anything posted here will be of use to anyone other than myself.
      My most wildly optimistic hope is that when I say something particularly stupid, someone else may notice it and point it out to me in a comment. But, seriously, given the extremely low signal:noise ratio of the blogs I've sampled here, I truly doubt anyone will ever have the time or interest to bother.
      Oh, well.
      One of the things I want to start with is to try to figure out more about what ACPI/DSDT is all about. Let's begin with just what is ACPI? One obvious starting place is the ACPI entry on wikipedia. Or you could go with my preferred short answer at this time: ACPI is one big honkin' confusin' mess!
      Or as Linus Torvalds apparently once jibed,

      "ACPI is a complete design disaster in every way. But we're kind of stuck with it.
      If any Intel people are listening to this and you had anything to do with ACPI, shoot yourself now, before you reproduce."
      (Linus & the Lunatics, Part II, November 25th, 2003)

      Here's my impression at the beginning based only on briefly skimming parts of the 727 page June 16, 2009 4'th revision of the Advanced Configuration and Power Interface Specification. ACPI is an attempt to solve the complicated and (thus) difficult problem of describing specific platform dependent hardware interfaces in a generic way that is both portable and platform independent. As an unintended (I assume) consequence, ACPI has become an even more complicated and difficult system than the original problem it was trying to "solve". (Don't ya just hate it when that happens!?)
      Someone I worked for ages and ages ago once very perceptively boiled program design down for me this way. "When you make it easy to do something complicated, you often can also make it hard to do something simple."
      Yep. I'd say that's captures my impression of ACPI in a nutshell. But Linus' observation is also very true. We are indeed kind of stuck with it. What'cha gonna do?
      -irrational john
    • By irrational John
      I've always wondered how to find out what those “UUUNNNN” strings inside the EISAID macro mean. For example, in the excerpt below what does "PNP0303" or "PNP030B" refer to?
      Device (XYZ) {
      Name (_HID, EISAID ("PNP0303")) // PC Keyboard Controller
      Name (_CID, EISAID ("PNP030B"))
      A step towards possibly more info. First I stumbled across this post which contains a list of Device IDs.
      But the post also (thankfully ) links back to where the OP found that list. That would be here: PnP Device IDs
      That site in turn refers back to The Linux pcmcia-cs Package as the source for its info.
      Finally, while googling around I also stumbled across this DriverGuide site which may be useful. I say "may" because it looks to be yet another one of those subscription sites which appear (to me) to want to milk money out of people rather than truly assist them. I'll have to investigate further to see if it is really providing any useful info.
      (FWIW, here's the original link google turned up to that site. However it is now annoyingly enough nagging me to "sign in". <sigh>)
      Also worth noting is the rev 4 ACPI spec excerpt below which clarifies that these are EISA ID strings. (So ISA still lives on? Who knew?? Wikipeida entry for EISA)
      18.5.34 EISAID (EISA ID String To Integer Conversion Macro)
      EISAID (EisaIdString) => DWordConst
      The EisaIdString must be a String object of the form “UUUNNNN”, where “U” is an uppercase letter and “N” is a hexadecimal digit. No asterisks or other characters are allowed in the string.
      Converts EisaIdString, a 7-character text string argument, into its corresponding 4-byte numeric EISA ID encoding. It can be used when declaring IDs for devices that have EISA IDs.
      EISAID (“PNP0C09”) // This is a valid invocation of the macro.
      -irrational john