OSDev.wiki

UACPI: Difference between revisions

Page Discussion

UACPI (view source)

Revision as of 05:41, 9 June 2024

605 bytes added ,  29 days ago
m
Bot: Replace deprecated source tag with syntaxhighlight
[unchecked revision][unchecked revision]
VisualWikitext
m (Bot: Replace deprecated source tag with syntaxhighlight)
 
(16 intermediate revisions by 2 users not shown)
Line 35:
Below is an example of basic uACPI initialization sequence that enters ACPI mode, parses tables, brings the event system online, and finally loads & initializes the namespace.
 
<sourcesyntaxhighlight lang="c">
#include <uacpi/uacpi.h>
#include <uacpi/event.h>
Line 53:
 
/*
* Set up the runtimelog level to parametersTRACE, suchthis asis loga levelbit orverbose behaviorbut flags.perhaps
* okay for now since we're just getting started. We can change this▼
* to INFO later on, which is the recommended level for release▼
* builds. There's also the loudest UACPI_LOG_DEBUG log level, which▼
* is recommended to pin down lockups or hangs.▼
*/
.rt_paramslog_level = {UACPI_LOG_TRACE,
/*
* Set the log level to TRACE, this is a bit verbose but perhaps
▲ * okay for now since we're just getting started. We can change this
▲ * to INFO later on, which is the recommended level for release
▲ * builds. There's also the loudest UACPI_LOG_DEBUG log level, which
▲ * is recommended to pin down lockups or hangs.
*/
.log_level = UACPI_LOG_TRACE,
 
/*
* Don't set any behavior flags, the defaults should work on most
* hardware.
*/
.flags = 0,
},
};
 
Line 123 ⟶ 118:
return 0;
}
</syntaxhighlight>
</source>
 
== Code examples ==
=== Namespace Enumeration & Finding Devices ===
 
There's are multiple ways to implement device discovery for an ACPI namespace, below we will discuss the most common ways and their pros and cons.
 
==== Let Devices Discover Themselves ====
Line 135 ⟶ 130:
so that it's called by kernel code during initialization.
 
<sourcesyntaxhighlight lang="c">
// ps2k.c
#include <uacpi/utilities.h>
Line 149 ⟶ 144:
uacpi_status ret = uacpi_get_current_resources(node, &kb_res);
if (uacpi_unlikely_error(ret)) {
log_error("unable to getretrieve PS2K resources: %s", uacpi_status_to_string(ret));
return UACPI_NS_ITERATION_DECISION_NEXT_PEER;
}
Line 167 ⟶ 162:
uacpi_find_devices(PS2K_PNP_ID, match_ps2k, NULL);
}
</syntaxhighlight>
</source>
 
<sourcesyntaxhighlight lang="c">
// acpi_init.c
 
void find_acpi_devices(void) {
find_ps2_keyboard();
Line 179 ⟶ 173:
// ...and more
}
</syntaxhighlight>
</source>
 
As you can see it's a very simple approach, but it has lots of drawbacks:
Line 190 ⟶ 184:
In this approach, we treat the ACPI namespace as a bus in our kernel, and let devices provide a way to identify them.
 
<sourcesyntaxhighlight lang="c">
// acpi_bus.h
#include <uacpi/uacpi.h>
#include <uacpi/namespace.h>
#include <uacpi/utilities.h>▼
#include <uacpi/resources.h>▼
 
struct acpi_driver {
const char *device_name;
const char *const *pnp_ids;
int (*device_probe)(uacpi_namespace_node *node, uacpi_namespace_node_info *info);
 
struct acpi_driver *next;
Line 204 ⟶ 200:
 
void acpi_register_driver(struct acpi_driver *driver);
</syntaxhighlight>
 
<syntaxhighlight lang="c">
extern struct acpi_driver *acpi_drivers_head;▼
 
// ps2k.c
#include <acpi_bus.h>
▲#include <uacpi/resources.h>
 
#define PS2K_PNP_ID "PNP0303"
Line 218 ⟶ 213:
};
 
static int ps2k_probe(uacpi_namespace_node_infouacpi_namespace_node *infonode, uacpi_namespace_nodeuacpi_namespace_node_info *nodeinfo)
{
uacpi_resources *kb_res;
Line 228 ⟶ 223:
* well!
*/
uacpi_status retst = uacpi_get_current_resources(node, &kb_res);
if (uacpi_unlikely_error(retst)) {
log_error("unable to getretrieve PS2K resources: %s", uacpi_status_to_string(retst));
return -ENODEV;
}
Line 247 ⟶ 242:
};
 
/*
* This is called either manually by the kernel, or put in the linker script
* in some known section, and executed by the kernel as part of driver initcalls.
* If it's a dynamically loadable module, then this is called on module load.
*/
int ps2k_init(void)
{
acpi_register_driver(&ps2k_driver);
return 0;
}
</syntaxhighlight>
 
<syntaxhighlight lang="c">
// acpi_bus.c
#include <acpi_bus.h>
 
▲#include <uacpi/utilities.h>
▲externstatic struct acpi_driver *acpi_drivers_head;
#include <uacpi/resources.h>
 
void acpi_register_driver(struct acpi_driver *driver)
{
struct acpi_driver *next = acpi_drivers_head;
acpi_drivers_head = driver;
driver->next = next;
}
 
static uacpi_ns_iteration_decision acpi_init_one_device(void *ctx, uacpi_namespace_node *node)
Line 263 ⟶ 273:
uacpi_status ret = uacpi_get_namespace_node_info(node, &info);
if (uacpi_unlikely_error(ret)) {
const char *path = uacpi_namespace_node_generate_absolute_path(node);
log_error("unable to retrieve node %.4ss information: %s",
uacpi_namespace_node_name(node).textpath, uacpi_status_to_string(ret));
uacpi_free_absolute_path(path);
return UACPI_NS_ITERATION_DECISION_CONTINUE;
}
Line 276 ⟶ 288:
struct acpi_driver *drv = NULL;
 
if (info->has_hidflags & UACPI_NS_NODE_INFO_HAS_HID) {
// Match the HID against every existing acpi_driver pnp id list
}
 
if (drv == NULL && (info->has_cidflags & UACPI_NS_NODE_INFO_HAS_CID)) {
// Match the CID list against every existing acpi_driver pnp id list
}
Line 286 ⟶ 298:
if (drv != NULL) {
// Probe the driver and do something with the error code if desired
drv->probedevice_probe(node, info);
}
 
Line 296 ⟶ 308:
{
uacpi_namespace_for_each_node_depth_first(
uacpi_namespace_root(), acpi_init_one_device, UACPI_NULL
);
}
</syntaxhighlight>
 
</source>
 
As you can see above, this approach is more scalable, faster, and involves way less code duplication.
Line 306 ⟶ 317:
 
=== Shutting Down the System ===
<sourcesyntaxhighlight lang="c">
#include <uacpi/sleep.h>
 
Line 346 ⟶ 357:
return 0;
}
</syntaxhighlight>
</source>
 
=== Hooking Up the Power Button ===
Line 352 ⟶ 363:
The example below hooks up the power button press using a fixed event callback.
 
<sourcesyntaxhighlight lang="c">
#include <uacpi/event.h>
 
Line 385 ⟶ 396:
return 0;
}
</syntaxhighlight>
</source>
 
Note that some of the more modern hardware routes the power button in a more complicated way, via an embedded controller.
Retrieved from "https://osdev.wiki/wiki/Special:MobileDiff/20731...26568"