Does current ACPI support ACPI Embedded Controller?

Ask your support questions in here

Moderator: Moderator Team

Post Reply
CircularTriangle06
Posts: 32
Joined: Sat May 23, 2015 5:54 pm

Does current ACPI support ACPI Embedded Controller?

Post by CircularTriangle06 »

As an experiment, tried to load drivers mentioned in acpi.inf of W2K3, acpiec.sys, oprghdlr.sys, with same parameters as acpi.sys in ReactOS's acpi.inf. It returns unsuccessful on load. It's mentioned in log that it tries to check something with ACPICA, but AcpiEvaluateMethod returns unsuccessful. Is it possible that the driver needs to be loaded earlier, or some other (OEM) driver needs to be also loaded, or it's just not supported?
debug log: https://yadi.sk/i/znXFPxxjqhECe
modified acpi.inf used: https://yadi.sk/i/2NdPI7FeqhEFF

edit: it was the second; after installing OEM driver in addition to this, log has changed together with driver status. Driver status is now Not working properly instead of Not loaded. https://yadi.sk/i/NKbkkIeuqhP6y; ...but after another restart, it doesn't load again;
CircularTriangle06
Posts: 32
Joined: Sat May 23, 2015 5:54 pm

Re: Does current ACPI support ACPI Embedded Controller?

Post by CircularTriangle06 »

Regarding this, I've found in the logs that if used ReactOS acpi.sys, MS acpiec.sys (since, https://jira.reactos.org/browse/CORE-6336, there is no such driver in ROS) and ASUS atkacpi.sys, these two latter don't load after correspondingly calling AcpiInterfaceConnectVector, and AcpiInterfaceNotificationsRegister.
So I tried to implement the code there (rather horribly, maybe) to understand that ( https://yadi.sk/d/lM12mtuCteTiE ) and it shows that ACPIEC driver calls AcpiInterfaceConnectVector with Shareable==FALSE, InterruptMode==Latched and GpeNumber==27. So strange, what does it want ACPI to do, give it some kind of interrupt (suggested by arguments, they hint at getting an interrupt) that belongs only to it, and not do anything concerning ACPI's IRQ at all? Then why does it need ACPI's interface to do it?

Still, making ATKACPI's call to AcpiInterfaceNotificationsRegister return success makes its status change to loaded, and ACPIEC's from "device is not working properly because FIXME is not working properly" to "device doesn't work properly or doesn't have all drivers installed" which hints that it depends on ATKACPI as well*. Although nothing else changes, and other drivers that depend on them, are still reporting that "ATKACPI is missing".
*edit: or not. Those two status codes are alternating again...
edit: patch updated. Now it seems clear how to send those notifications (can't check if it's right though, as it doesn't seem to make difference - nor assess any side effects of using ACPI_ROOT_OBJECT as there was nothing else ACPI_HANDLE to use)
edit: another approach. I can do even less with trying to get the GPE handler functions, which supposedly needs something real, not NULL or ACPI_OBJECT_ROOT, to succeed. Nor use the PGPE_SERVICE_ROUTINE, whose arguments are unknown PVOIDs. Well, why not force success there, just to get the next debug message. Which is
(../../drivers/bus/acpi/main.c:313) Unsupported IOCTL: 32c008
exactly the only one of possible functions (acpiioctl.h) that isn't defined. Guess that means ATK hotkeys can't be made to work.
edit: https://yadi.sk/d/1AzPfougtsqdA Interrupt works now. ACPIEC's AddDevice fails though.
Post Reply

Who is online

Users browsing this forum: No registered users and 20 guests