Help on ACPI events reported to OS


Kumar G <kumarg27061979@...>
 

Hi Experts,

I am moving from device tree world to acpi. I found the event notification feature of acpi table interesting.

I have some questions over notification
-  Is some hardware can generate events and notify OS by its own ?(if yes , please help me how) , I mean without calling any method from OS

- I may be wrong, but it looks OS needs to call a method in order to execution of Notify function of acpi table

- Is this correct acpi tables are static piece of code, having no thread/execution context, All execution in done from OS 


Thanks
Kumar G


Kumar G <kumarg27061979@...>
 

Help please
Thanks


On Mon, 27 Jul 2020 at 13:45, Kumar G <kumarg27061979@...> wrote:
Hi Experts,

I am moving from device tree world to acpi. I found the event notification feature of acpi table interesting.

I have some questions over notification
-  Is some hardware can generate events and notify OS by its own ?(if yes , please help me how) , I mean without calling any method from OS

- I may be wrong, but it looks OS needs to call a method in order to execution of Notify function of acpi table

- Is this correct acpi tables are static piece of code, having no thread/execution context, All execution in done from OS 


Thanks
Kumar G


Laszlo Ersek
 

+Igor, some comments below

On 07/27/20 10:15, Kumar G wrote:
Hi Experts,

I am moving from device tree world to acpi. I found the event notification
feature of acpi table interesting.

I have some questions over notification
- Is some hardware can generate events and notify OS by its own ?(if yes ,
please help me how) , I mean without calling any method from OS

- I may be wrong, but it looks OS needs to call a method in order to
execution of Notify function of acpi table
My (rusty) understanding is that hardware signals the OS with "general
purpose IO" and/or SCI (ACPI) interrupt. Then the OS invokes General
Purpose Event handlers (GPE handlers) from ACPI. In turn the GPE
handlers in ACPI parse the event, and invoke the proper OS functionality
via Notify().

So basically the hardware only tells the OS via SCI that "something ACPI
happened". The OS passes this to ACPI for handling (GPE handlers), which
in turn dispatch the event back to the proper OS handler, via Notify().

- Is this correct acpi tables are static piece of code, having no
thread/execution context, All execution in done from OS
No, this is not correct. AML methods can run in parallel, they can (and
need to) do explicit locking (there are ASL primitives for this). AML
methods have local variables, but they also operate on global objects in
the ACPI namespace (operation regions, device registers, ...) so
serialization in ACPI is important, if multiple hardware events can
occur concurrently.

Thanks
Laszlo



Thanks
Kumar G




Laszlo Ersek
 

On 07/30/20 18:33, Kumar G wrote:
Thank You Laszlo



-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
Laszlo Ersek
Sent: Thursday, July 30, 2020 5:52 PM


+Igor, some comments below
My (rusty) understanding is that hardware signals the OS with "general
purpose IO" and/or SCI (ACPI) interrupt. Then the OS invokes General
Purpose Event handlers (GPE handlers) from ACPI. In turn the GPE handlers
in ACPI parse the event, and invoke the proper OS functionality via
Notify().

So basically the hardware only tells the OS via SCI that "something ACPI
happened". The OS passes this to ACPI for handling (GPE handlers), which
in

turn dispatch the event back to the proper OS handler, via Notify().


Okay, so my understanding seems to be ok here. Notify() is getting called
in context of OS.
Notify() is "serviced" in the context of the OS.






- Is this correct acpi tables are static piece of code, having no
thread/execution context, All execution in done from OS
No, this is not correct. AML methods can run in parallel, they can (and
need

to) do explicit locking (there are ASL primitives for this). AML methods
have

local variables, but they also operate on global objects in the ACPI
namespace (operation regions, device registers, ...) so serialization in
ACPI is

important, if multiple hardware events can occur concurrently.


Let me rephrase myself here, when BIOS provides ACPI table to OS

then OS's threads will call the AML methods, for sure many OS threads can
access AML methods at the same time.

But on its own, ACPI table has no way to call itself.

Example, in case of hardware interrupt or event, which is caught by OS and
OS calls GPE methods, which

will call Notify() of acpi table and corresponding device will be notified.

Here without involving OS, Notify can not be executed, right I am ?
Correct.

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.

Laszlo


Kumar G <kumarg27061979@...>
 

Thank You Laszlo

 

> -----Original Message-----

> From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of

> Laszlo Ersek

> Sent: Thursday, July 30, 2020 5:52 PM

 

> +Igor, some comments below

>

> My (rusty) understanding is that hardware signals the OS with "general

> purpose IO" and/or SCI (ACPI) interrupt. Then the OS invokes General

> Purpose Event handlers (GPE handlers) from ACPI. In turn the GPE handlers

> in ACPI parse the event, and invoke the proper OS functionality via Notify().

>

> So basically the hardware only tells the OS via SCI that "something ACPI

> happened". The OS passes this to ACPI for handling (GPE handlers), which in

> turn dispatch the event back to the proper OS handler, via Notify().

 

Okay, so my understanding seems to be ok here. Notify() is getting called in context of OS.

 

 

> > - Is this correct acpi tables are static piece of code, having no

> > thread/execution context, All execution in done from OS

>

> No, this is not correct. AML methods can run in parallel, they can (and need

> to) do explicit locking (there are ASL primitives for this). AML methods have

> local variables, but they also operate on global objects in the ACPI

> namespace (operation regions, device registers, ...) so serialization in ACPI is

> important, if multiple hardware events can occur concurrently.

 

Let me rephrase myself here, when BIOS provides ACPI table to OS

then  OS's threads will call the AML methods, for sure many OS threads can access AML methods at the same time.

But on its own, ACPI table has no way to call itself.

Example, in case of hardware interrupt or event, which is caught by OS and OS calls GPE methods, which

will call Notify() of acpi table and corresponding device will be notified.

Here without involving OS, Notify can not be executed, right I am ?

 

Thanks and Warm regards

Kumar G

 

> Thanks

> Laszlo


Kumar G <kumarg27061979@...>
 

Thanks  Laszlo,
clear now :)


On Fri, 31 Jul 2020 at 01:23, Laszlo Ersek <lersek@...> wrote:
On 07/30/20 18:33, Kumar G wrote:
> Thank You Laszlo
>
>
>
>> -----Original Message-----
>
>> From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
>
>> Laszlo Ersek
>
>> Sent: Thursday, July 30, 2020 5:52 PM
>
>
>
>> +Igor, some comments below
>
>>
>
>> My (rusty) understanding is that hardware signals the OS with "general
>
>> purpose IO" and/or SCI (ACPI) interrupt. Then the OS invokes General
>
>> Purpose Event handlers (GPE handlers) from ACPI. In turn the GPE handlers
>
>> in ACPI parse the event, and invoke the proper OS functionality via
> Notify().
>
>>
>
>> So basically the hardware only tells the OS via SCI that "something ACPI
>
>> happened". The OS passes this to ACPI for handling (GPE handlers), which
> in
>
>> turn dispatch the event back to the proper OS handler, via Notify().
>
>
>
> Okay, so my understanding seems to be ok here. Notify() is getting called
> in context of OS.

Notify() is "serviced" in the context of the OS.

>
>
>
>
>
>>> - Is this correct acpi tables are static piece of code, having no
>
>>> thread/execution context, All execution in done from OS
>
>>
>
>> No, this is not correct. AML methods can run in parallel, they can (and
> need
>
>> to) do explicit locking (there are ASL primitives for this). AML methods
> have
>
>> local variables, but they also operate on global objects in the ACPI
>
>> namespace (operation regions, device registers, ...) so serialization in
> ACPI is
>
>> important, if multiple hardware events can occur concurrently.
>
>
>
> Let me rephrase myself here, when BIOS provides ACPI table to OS
>
> then  OS's threads will call the AML methods, for sure many OS threads can
> access AML methods at the same time.
>
> But on its own, ACPI table has no way to call itself.
>
> Example, in case of hardware interrupt or event, which is caught by OS and
> OS calls GPE methods, which
>
> will call Notify() of acpi table and corresponding device will be notified.
>
> Here without involving OS, Notify can not be executed, right I am ?

Correct.

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.

Laszlo