Using uACPI in Haiku operating system

[pulkomandy]

Here is my attept to use uACPI in Haiku so far: https://review.haiku-os.org/c/haiku/+/8937

Questions:

• I didn't find an equivalent to AcpiFindRootPointer from ACPICA (this searches the ACPI entry point in low memory when booting from BIOS). Does uACPI takes care of this on its own or do I have to provide it? In osdev examples, there is no way to tell uACPI where the tables are. In our case, this initialization is done in multiple steps, with the bootloader getting the info from the firmware, and then passing it down to the kernel where ACPI is finally initialized (the kernel doesn't communicate directly with the EFI firmware for example). See src/add-ons/kernel/bus_managers/acpi/arch/x86/arch_init.cpp:150 and maybe src/system/kernel/arch/generic/acpi_irq_routing_table.cpp:797
• I don't find an equivalent to AcpiUpdateAllGpes and AcpiSetGpe. The interface for events seems to be a bit different. See src/add-ons/kernel/bus_managers/acpi/BusManager.cpp:338 and :366.
• I didn't find an API similar to AcpiGetNextObject. The only way to iterate objects is having uACPI call a callback for each object (producer-driven). I may be able to change our code to work this way, but I think a consumer-driven API (similar to a iterator) would be easier for us.
• Our current ACPI module exposes directly to other kernel modules the ability to read and write kernel registers (src/add-ons/kernel/bus_managers/acpi/BusManager.cpp:818 and :825). This is a private API in uACPI, am I safe to use it anyways? This is then used by our cpuidl driver (src/add-ons/kernel/drivers/power/x86_cpuidle/acpi_cpuidle.cpp) to tweak some bus master and bus arbitration registers during suspend and resume (ACPI_BITREG_BUS_MASTER_STATUS, ACPI_BITREG_BUS_MASTER_RLD and ACPI_BITREG_ARB_DISABLE) apparently to avoid issues with interrupted DMA transfers on some old machines.

[d-tatianin]

I didn't find an equivalent to AcpiFindRootPointer from ACPICA (this searches the ACPI entry point in low memory when booting from BIOS). Does uACPI takes care of this on its own or do I have to provide it? In osdev examples, there is no way to tell uACPI where the tables are. In our case, this initialization is done in multiple steps, with the bootloader getting the info from the firmware, and then passing it down to the kernel where ACPI is finally initialized (the kernel doesn't communicate directly with the EFI firmware for example). See src/add-ons/kernel/bus_managers/acpi/arch/x86/arch_init.cpp:150 and maybe src/system/kernel/arch/generic/acpi_irq_routing_table.cpp:79

uACPI uses the uacpi_kernel_get_rsdp helper in order to retrieve the RSDP, which is implemented by the host using uACPI. Since RSDP is usually provided by the bootloader, uACPI does not offer any helpers to scan for it in the low memory.

I don't find an equivalent to AcpiUpdateAllGpes and AcpiSetGpe. The interface for events seems to be a bit different. See src/add-ons/kernel/bus_managers/acpi/BusManager.cpp:338 and :366.

AcpiUpdateAllGpes -> uacpi_finalize_gpe_initialization AcpiSetGpe -> uacpi_suspend_gpe/uacpi_resume_gpe

I didn't find an API similar to AcpiGetNextObject. The only way to iterate objects is having uACPI call a callback for each object (producer-driven). I may be able to change our code to work this way, but I think a consumer-driven API (similar to a iterator) would be easier for us.

That's true, there is no such API as of right now. I'd be curious to see some examples of how and why it's used in Haiku. I'm open to adding it though.

Our current ACPI module exposes directly to other kernel modules the ability to read and write kernel registers (src/add-ons/kernel/bus_managers/acpi/BusManager.cpp:818 and :825). This is a private API in uACPI, am I safe to use it anyways? This is then used by our cpuidl driver (src/add-ons/kernel/drivers/power/x86_cpuidle/acpi_cpuidle.cpp) to tweak some bus master and bus arbitration registers during suspend and resume (ACPI_BITREG_BUS_MASTER_STATUS, ACPI_BITREG_BUS_MASTER_RLD and ACPI_BITREG_ARB_DISABLE) apparently to avoid issues with interrupted DMA transfers on some old machines.

This is interesting, I was not aware of such a use case. You are free to use the private API for this right now, I might consider exposing this as public API anyway then.