blob: 9e5ca8bd4e3082b29e91badc1e958b5f7b2c3c44 [file] [log] [blame]
Chrome OS Embedded Controller
=============================
The Chrome OS Embedded Controller (EC) provides certain features to Chrome
OS devices. These include battery charging and keyboard scanning.
The Chrome OS EC code base is available on gitweb here:
https://chromium.googlesource.com/chromiumos/platform/ec.git
The messaging interface between the AP and the EC is defined by the
include/ec_commands.h file in U-Boot, which is the same as the file of the
same name in the EC code base.
At the time of writing there is no separate documentation of the EC
interface. Many messages are somewhat self-explanatory once the purpose is
understood.
The file includes information about some of the more complex messages. Note
that in the event of a conflict between this file and ec_command.h, it is
the header file which is correct.
EC I2C Pass-Through
-------------------
On snow, we use a single I2C bus and a GPIO-based arbitration scheme to
determine whether the AP or EC has control of the battery I2C bus.
There are two other devices (spring and pit) which use two I2C buses in a
pass-through arrangement, where the EC always controls the battery I2C bus,
but provides access to the AP through an AP->EC message on a separate I2C bus.
A 'pure' pass-through seems to be better than an ad-hoc device-by-device
approach, with a message for each type of device/feature since it allows
U-Boot and the kernel to use existing drivers. All of the complexity of the
pass-through can be kept inside the i2c mux driver and there is no need to
write a new driver for each chip (tps65090_regulator, tps65090_charger,
sbs_battery).
This document describes a message protocol for the AP and EC to use for this
activity.
Note that the EC may wish to filter some slave addresses for security if WP
is enabled. Attempting to read/write one of those will return
EC_RES_ACCESS_DENIED.
Message Protocol
----------------
We allow sending of multiple I2C messages in each EC pass-through message.
This better matches the kernel's requirements, while putting no additional
stress on U-Boot.
Request:
Field Size Description
Bus ID 1 Bus number to use
n 1 Number of messages within this transaction
<message> 2 * n Message details, consisting of 2 halfwords:
Address and flags:
7- or 10-bit I2C slave address
(note we don't include the RW bit in the address)
FLAG_10BIT - enable 10-bit addressing
FLAG_READ - read data (else write)
len - number of bytes to read/write
Data
m
Bytes to write (m is the sum of all message lengths where
EC_I2C_FLAG_READ is not set)
Response:
Field Size Description
Status 1 I2C status flags:
TIMEOUT - timeout during transfer
NAK - transfer was not acknowledged
n 1 Number of messages successfully sent within this
transaction
Data m Bytes read (m is the sum of all message lengths where
EC_I2C_FLAG_READ is set, unless there is an error
response, in which case it may be less)
For structures, see include/ec_commands.h (e.g. truct ec_params_i2c_passthru
for the request parameters).