Difference between revisions of "ACPI/Board-EC interaction"

From coreboot
Jump to: navigation, search
(Hotkey and event methods)
 
(14 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
This page details the required interface and implementation details for connecting embedded controller ASL files to mainboard ASL files. Implementing this specification is mandatory for every new mainboard/EC added to the tree.
 
This page details the required interface and implementation details for connecting embedded controller ASL files to mainboard ASL files. Implementing this specification is mandatory for every new mainboard/EC added to the tree.
  
<span style="background:red">WARNING! The rules presented here are still a work-in-progress and should not yet be taken as as mandatory.</span> However, if you are implementing a new EC, mainboard, or are interested in refactoring existing ASL files, you should join in the conversation and get this specification finalized.
+
EC ASL files should be self-contained, and not depend on the specific chipset or mainboard. As a result all variables and methods which are used must be standardized to foster interoperability and modularity. This specification details how to achieve those points.
  
EC ASL files should be self-contained, and not depend on the specific chipset or mainboard. As a result all variables and methods which are used must be standardized to foster interoperability and modularity. This specification details how to achieve those points.
+
== System Resources ==
 +
 
 +
All ECs are assumed to use IO ports '''0x62''' and '''0x66''' for data/commands. If the EC also serves as a keyboard controller, it is assumed to use ports '''0x60''' and '''0x64'''. I/O port accesses to these ports must be directed to the bus to which the EC is connected. These need not be individually documented.
  
== Hotkey event methods ==
+
If the EC uses different ports, or needs other system resources, those must be documented in '''src/ec/vendor/model/documentation.txt'''
  
Two proposals exist:
+
== Defined constants ==
  
=== The hammer method ===
+
* EC_SCI_GPE
 +
** The general purpose event (GPE) corresponding to the EC SCI line.
  
Define a set of common ACPI method names which the mainboard code should define, and the EC code can always use.
+
== Hotkey and event methods ==
  
The mainboard must #define these to an existing method. The actual ASL methods must not use these long names in ASL. The "MB_" prefix indicates that the mainboard is providing these methods.
+
Provide a generic mainboard device in the '''\_SB''' scope with a set of pre-defined methods. This way, the EC can pass events to the mainboard for handling.
  
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.
+
The mainboard is not required to implement all methods, however, it must provide all such methods for the EC. The EC can call any of these methods. If the EC requires a method which is not part of the standard set, the this fact must be documented '''src/ec/vendor/model/documentation.txt'''.
  
* MB_TOGGLE_WLAN() or MB_TOGGLE_WIRELESS() (TODO: only one method should be defined!!!)
+
Device (MB) {
** Toggle wireless LAN on and off, or wireless LAN and bluetooth (respectively). EC calls this on hotkey events.
+
/* Lid open */
 +
Method (LIDO) { /* Stub */ }
 +
/* Lid closed */
 +
Method (LIDC) { /* Stub */}
 +
/* Increase brightness */
 +
Method (BRTU) { /* Stub */ }
 +
/* Decrease brightness */
 +
Method (BRTD) { /* Stub */ }
 +
  /* Switch display */
 +
Method (DSPS) { /* Stub */ }
 +
/* Toggle wireless */
 +
Method (WLTG) { /* Stub */ }
 +
/* Decrease brightness */
 +
Method (LIDS) { /* Stub */ }
 +
}
  
* MB_INCREASE_BRIGHTNESS() and MB_DECREASE_BRIGHTNESS()
+
These methods should be called by the EC using the '''\_SB.MB''' scope:
** Increase or decrease screen brightness. EC calls this on hotkey events.
 
  
* MB_SWITCH_DISPLAY()
+
/* Decrease brightness hotkey */
** Switch the active display. EC calls this on hotkey events.
+
Method (_Q11, 0, NotSerialized)
 +
{
 +
\_SB.MB.BRTD()
 +
}
  
* MB_NOTIFY_POWER_EVENT()
+
== EC-specific extensions ==
** Handle power state notifications and notify CPU device objects to re-evaluate their _PPC and _CST tables.
 
  
=== The mainboard handler method ===
+
The EC may provide specific extensions to this specifications. However, any such extension must be fully documented in '''src/ec/vendor/model/documentation.txt'''. The EC must be able to function properly even if the mainboard does not define or use such extensions.

Latest revision as of 03:37, 19 April 2014

This page details the required interface and implementation details for connecting embedded controller ASL files to mainboard ASL files. Implementing this specification is mandatory for every new mainboard/EC added to the tree.

EC ASL files should be self-contained, and not depend on the specific chipset or mainboard. As a result all variables and methods which are used must be standardized to foster interoperability and modularity. This specification details how to achieve those points.

System Resources

All ECs are assumed to use IO ports 0x62 and 0x66 for data/commands. If the EC also serves as a keyboard controller, it is assumed to use ports 0x60 and 0x64. I/O port accesses to these ports must be directed to the bus to which the EC is connected. These need not be individually documented.

If the EC uses different ports, or needs other system resources, those must be documented in src/ec/vendor/model/documentation.txt

Defined constants

  • EC_SCI_GPE
    • The general purpose event (GPE) corresponding to the EC SCI line.

Hotkey and event methods

Provide a generic mainboard device in the \_SB scope with a set of pre-defined methods. This way, the EC can pass events to the mainboard for handling.

The mainboard is not required to implement all methods, however, it must provide all such methods for the EC. The EC can call any of these methods. If the EC requires a method which is not part of the standard set, the this fact must be documented src/ec/vendor/model/documentation.txt.

Device (MB) {
	/* Lid open */
	Method (LIDO) { /* Stub */ }
	/* Lid closed */
	Method (LIDC) { /* Stub */}
	/* Increase brightness */
	Method (BRTU) { /* Stub */ }
	/* Decrease brightness */
	Method (BRTD) { /* Stub */ }
 	/* Switch display */
	Method (DSPS) { /* Stub */ }
	/* Toggle wireless */
	Method (WLTG) { /* Stub */ }
	/* Decrease brightness */
	Method (LIDS) { /* Stub */ }
}

These methods should be called by the EC using the \_SB.MB scope:

/* Decrease brightness hotkey */
Method (_Q11, 0, NotSerialized)
{
	\_SB.MB.BRTD()
}

EC-specific extensions

The EC may provide specific extensions to this specifications. However, any such extension must be fully documented in src/ec/vendor/model/documentation.txt. The EC must be able to function properly even if the mainboard does not define or use such extensions.