[coreboot] [proposal] EC-mainboard interaction at ASL level

[mrnuke]

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