acpi: Add Darwin OSI support for Apple Mac hardware

[guest-seuros]

Summary

Apple Mac systems with dual GPUs (Intel iGPU + AMD/NVIDIA dGPU) hide the Intel integrated GPU when the ACPI firmware does not see _OSI("Darwin").

Linux handles this in drivers/acpi/osi.c by detecting Apple hardware via DMI, disabling all Windows OSI strings, and installing Darwin OSI.
Users can override with acpi_osi=!Darwin to restore Windows-like behavior.

Without this change FreeBSD always use the heavy duty GPU.
It fine in practice but impact the battery life seriously when laptop is not powered.

Apple hardware hide second GPU (Intel) from being listed.

Please note that some other laptops with dual GPU do suffer the same power consumption.

Test Plan

1. pciconf -lv | grep -A4 "class=0x0300"
2. Verify both GPUs visible
3. Check dmesg for "Apple hardware: enabled Darwin OSI" <<-- should i wrap the message in debug ?
4. Test disable: set hw.acpi.apple_darwin_osi=0 in loader.conf, reboot
5. Verify Intel GPU hidden again

vgapci1@pci0:0:2:0 │ Intel Crystal Well (Iris Pro 5200)
vgapci0@pci0:1:0:0 │ AMD Venus XT (R9 M370X)

Note (I did not try this with NVIDIA based Apple, those are older)

[jrtc27]

sys/dev/acpica/acpi.c

4846

Why's only this one guarded by bootverbose? If anything isn't the error more important to show?

[guest-seuros]

sys/dev/acpica/acpi.c

4846

The success message document an intentional ACPI policy override.

The failure path is diagnostic-only, so it is appropriately gated by bootverbose to avoid user-facing noise.

I tested this on many Apple systems ranging from 2011 to 2019.

While it behaves correctly on those platforms, older or less common models (pre 2011) may expose ACPICA edge cases, which is why the failure path is keept for debuging. (i will get few of those machines soon to test).

If this code proves to be stable across every range of Apple hardware and ACPICA versions, the failure branch itself could potentially and the logging be removed in the future.

[obiwac]

looks good!

which function are you adding this to, acpi_reset_interfaces? phab says context not available and the line numbers don't seem to match up.

sys/dev/acpica/acpi.c

4839

nit but: wouldn't you want to want to warn if removing the window vendor strings failed too, if you think adding the Darwin vendor string failing is likely enough to warrant a warning message?

[adrian]

Any other comments? I'd like to land this into -HEAD this week and see how it plays out!

[ngie]

Would this please make this into a SYSCTL+TUNABLE? It would be nice if that's at all possible, because then you could do graphics switching post-boot. I don't know if it's possible, but it would be nice. macOS supports graphics switching dynamically at runtime/based on power states.
Also, are there any caveats associated with picking one of the GPUs over the other, e.g., one supports dual displays at a higher resolution, whereas the other only supports single displays at a lower resolution?

[guest-seuros]

@ngie i prefered to keep this diff scoped to ACPI discovery only, but the switching is important too.

This change is limited to ACPI OSI behavior and device enumeration.
Runtime switching is planned as follow-up work once this has landed and been validated on more real hardware.

In practice, the immediate goal is power management rather than seamless switching.
On the affected Apple systems, both GPUs are currently powered by default. Disabling one of them is already doable and I have tested this successfully, which results in the expected power savings.

Runtime switching is technically possible, but is not fully solved yet. The current state is:
Both GPUs powered => AMD only: works
AMD only => re-enable Intel and disable AMD: works
2 GPUs powered => Intel only -> re-enable AMD: currently crashes

This makes me think that AMD reinitialisation still needs more work, and I'm investigating the correct bring-up sequence.

[guest-seuros]

sys/dev/acpica/acpi.c

4839

Adding the Darwin OSI string is a requirement for this change.
Removing the Windows vendor strings is a best-effort cleanup.

I can remove this cleanup code if needed.

[obiwac]

sys/dev/acpica/acpi.c

4839

no, that's fair. For some reason i thought https://www.kernel.org/doc/Documentation/acpi/osi.txt (last section) implied clearing the windows strings as a necessary requirement