Re: Help on ACPI events reported to OS
On 07/30/20 18:33, Kumar G wrote:
Thank You LaszloNotify() is "serviced" in the context of the OS.-----Original Message-----From: firstname.lastname@example.org <email@example.com> On Behalf OfLaszlo ErsekSent: Thursday, July 30, 2020 5:52 PM+Igor, some comments belowMy (rusty) understanding is that hardware signals the OS with "generalpurpose IO" and/or SCI (ACPI) interrupt. Then the OS invokes GeneralPurpose Event handlers (GPE handlers) from ACPI. In turn the GPE handlersin ACPI parse the event, and invoke the proper OS functionality viaNotify().So basically the hardware only tells the OS via SCI that "something ACPIhappened". The OS passes this to ACPI for handling (GPE handlers), whichinturn dispatch the event back to the proper OS handler, via Notify().
Correct.- Is this correct acpi tables are static piece of code, having nothread/execution context, All execution in done from OSNo, this is not correct. AML methods can run in parallel, they can (andneedto) do explicit locking (there are ASL primitives for this). AML methodshavelocal variables, but they also operate on global objects in the ACPInamespace (operation regions, device registers, ...) so serialization inACPI isimportant, if multiple hardware events can occur concurrently.
The AML interpreter / executor is a part of the OS. AML "runs" because
the OS makes it run. The Notify() operation "calls into the OS" because
the kernel component that parses the Notify opcode, in the AML,
recognizes the opcode for what it is, and passes control to another
kernel component (a callback) that handles the particular notification.
AML is not native machine code, so it cannot pass control to the OS. The
OS interprets the AML opcodes as data, and dependent upon what it sees,
it passes control to other places in the OS.