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