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

From coreboot
Jump to: navigation, search
(The hammer method)
(The mainboard handler method)
Line 19: Line 19:
  
 
Two proposals exist:
 
Two proposals exist:
 
=== The mainboard handler method ===
 
 
Provide a generic mainboard "EC event" method that any EC _Qxx could call and pass the event ID to. The event ID is a standard defined event ID , greater than 255 so as not to conflict with possible Qxx IDs.  This limits the permutations of mainboard EC event handlers and gives the flexibility to pass all the various EC events to the mainboard for handling.
 
 
For example:
 
 
#define EC_EVENT_LID_CLOSED 0x100
 
 
In the EC ASL:
 
 
/* lid closed */
 
Method (_Q01) {               
 
        \_SB.MBEC (EC_EVENT_LID_CLOSED)
 
}
 
 
And the mainboard handler could look like:
 
 
Scope (\_SB)
 
{
 
        /* mainboard event handler */
 
        Method (MBEC, 1, Serialized) {
 
        Switch (ToInteger (Arg0)) {
 
                Case (EC_EVENT_LID_CLOSED) { ... }
 
                Case (EC_EVENT_...) { ... }
 
        }
 
}
 
  
 
=== The mainboard namespace method ===
 
=== The mainboard namespace method ===

Revision as of 23:52, 16 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.

WARNING! The rules presented here are still a work-in-progress and should not yet be taken as as mandatory. 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.

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 event methods

Two proposals exist:

The mainboard namespace method

Similar to the mainboard handler method, but handlers are placed in a special namespace, and the names of the methods are standardized.

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 */ }
}

But even in this form there needs to be a generic method for all the special cases...

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.