This is an ugly one, and we keep having to find different workarounds to make this happen. We have the preprocessor, so why not use it?
Define a set of common ACPI method names which the mainboard code should define, and the EC code can always use.
* MB_TOGGLE_WLAN() or MB_TOGGLE_WIRELESS() Toggle wireless LAN on and off, or wireless LAN and bluetooth (respectively). EC calls this on hotkey events.
* MB_INCREASE_BRIGHTNESS() and MB_DECREASE_BRIGHTNESS() Increase or decrease screen brightness. EC calls this on hotkey events.
* MB_SWITCH_DISPLAY() Switch the active display. EC calls this on hotkey events.
* MB_NOTIFY_POWER_EVENT() Handle power state notifications and notify CPU device objects to re- evaluate their _PPC and _CST tables.
Of course, we would have the mainboard #define these to an existing method, we wouldn't really use these long method names in ASL. Another idea would be to standardize on four letter names, but those are not as clear, and hide the "MB_" which is there to indicate that the mainboard should provide those.
Notice that these methods are only called on hotkey events. As such, unless the user has really fast fingers, there isn't a huge ACPI overhead as opposed to setting/clearing the needed bits directly in the caller.
We then extend this to also include ACPI objects for different purposes.
* MB_LID_STATE Register/GPIO bit which reads the state of the lid
And we can also define a set of ACPI variables which should always be present, for the purpose of ACPI housekeeping.
* LIDS Stores the lid state, so that we don't have to read it every time. (remember, reading may involve several port IO operations) * PWRS AC adapter present/not present.
It seems a little convoluted, so if you didn't ACPI before, you'll WTF on this one. The end result is that it unifies the interface rather than letting each EC define its own interface. It also (hopefully) makes ACPI just a little more readable by having a standardized set of pork.
If there aren't any major objections, I'll write this up on the wiki, and we'll open the gates to refactoring. I'm interested if there are cases where this *cough* API *cough* is not appropriate. It seems to be universally efficient.
Alex