Add host event for PD up to AP. The PD toggles a gpio line to
EC causing an interrupt on EC. The EC then sends host command
down to PD MCU to get its status. There is a new status bit for
PD host event, so when EC see's the PD host event status bit,
it sends a PD host event to the AP.
There is currently only one host event for PD to AP.
BUG=chrome-os-partner:31361
BRANCH=none
TEST=added PD console command pdevent, which initiates the host
event. when sent, verified on EC that it sets the correct host
event bit using hostevent console command
Change-Id: If1a59a3232e2f9a49f272c6dee5319254d87b9a9
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213371
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds a new host commmand for sending RW updates to PD devices.
The host command has a variety of sub-commands for performing the
update, including: erase RW, reboot, write new hash, write flash.
To program zinger RW, you should send host commands in this order:
write new hash to all 0's
reboot (zinger boots into RO since RW hash doesn't match)
erase RW
write flash
write new hash to match contents of RW
reboot
This also adds an ectool command to write a new RW. Just pass it
the RW .flat or .bin file.
BUG=chrome-os-partner:31361
BRANCH=none
TEST=ectool --dev=1 --interface=lpc flashpd 0 0 zinger.RW.flat
Change-Id: Ia81615001b83ad7ee69b1af2bf1d7059177cde04
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213239
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously our accel / gyro drivers assumed that we had exactly two of
each identical part in the system. Some systems may have different
configurations, so allow this to be specified at the board-level.
Note that our motion_sense algorithm currently assumes that we have one
accelerometer in the lid and one in the base -- we'll need to fix that
in another CL.
BUG=chrome-os-partner:27320
TEST=Compile-only. Tested in future Samus commit.
BRANCH=None.
Change-Id: I1fae1f6c578fedebe78b473a5d66a5794ccaae00
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212321
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Set input current limit based on the max current from the
PD negotiation. For samus, this information is passed to
the EC as a host command. For ryu, the max current is set
directly following a negotiation.
CONFIG_CHARGER_INPUT_CURRENT is now just the default limit,
but after a successful PD negotiation, the limit can be
raised.
Note, for now the input current limit for samus is set to
2/3 of the value negotiated for. This is due to hardware
problems measuring input current on p2b boards.
BUG=chrome-os-partner:28532, chrome-os-partner:24461
BRANCH=none
TEST=tested on a samus. Verified input current limit using
"charger" console command from EC. Input current limit
after a reboot is 512. When zinger is plugged in, it jumps
to the appropriate value (currently 1280mA), and when
the negotiation is changed using the "pd 0 dev 5" command
on the PD console, the input current limit is adjusted to
match (2000mA).
Change-Id: Iab9186a0f9814655e3240217a9baf4a38f15f84d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211023
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Host commands in the range 0x4000-0x7fff will be passed thru the EC to
the PD MCU as 0x0000-0x3fff.
BUG=chrome-os-partner:30079
BRANCH=samus
TEST=manual. On PD console:
hcdebug params
On EC console:
hostcmd 2 0 -> hex string of EC version
hostcmd 0x4002 0 -> hex string of PD version, and PD console shows host
command 2 was received. The hex response shown on the PD console
matches the one printed by the EC
Change-Id: Icc2d97c5977145a0c3ad2630d2b5a19e876a36d0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207821
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Revert
- https://chromium-review.googlesource.com/#/c/205145/2
- https://chromium-review.googlesource.com/#/c/205147/4
Now using the real AC_PRESENT gpio signal instead of whether or
not the PD MCU negotiated for 20V.
BUG=chrome-os-partner:29841, chrome-os-partner:29842
BRANCH=none
TEST=tested on a board with reworked AC_PRESENT signal. Verified
that gpio is correctly reporting state of AC and is charging when
AC is plugged in. Tested the no battery case to make sure
board powers on and stays on with just a charger. Also tested the
dead battery case by plugging in a dead battery, then plugging in
a charger and making sure system powers on and starts charging.
Change-Id: I4424771c91c8a2aa19eda68a8b5194e9265d529c
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206598
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The ACOK input to the EC is not connected to the charger so
that signal cannot be relied on for AC presence. Instead
have the PD report when it negotiates to 20V and when it
disconnects and have the EC use that for AC presence.
BUG=chrome-os-partner:29841
BRANCH=none
TEST=test charging with zinger on samus system.
Change-Id: Ia9096a24ab05d110e31910218dc8c214a846a9a4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205145
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
ectool must support all prior versions of commands that shipped
EC binaries use.
BUG=chrome-os-partner:29830
BRANCH=None
TEST=Manual
With an EC that only supports version 0:
- Run 'ectool batterycutoff' -> success
- Run 'ectool batterycutoff at-shutdown' -> error with explicit
message about at-shutdown not being supported
- Run 'ectool batterycutoff foo' -> error, bad parameter
With an EC that support version 0 or 1:
- Run 'ectool batterycutoff' -> success
- Run 'ectool batterycutoff at-shutdown' -> success
- Run 'ectool batterycutoff foo' -> error, bad parameter
Change-Id: Ia88cfc5fa7c5125828ec0595f0b6a505916c97ea
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205155
Reviewed-by: Vic Yang <victoryang@chromium.org>
We never implemented this. We have no devices which support it. And
we used bit #17 in a 16-bit field to flag it, so it wouldn't have
worked even if we did. So, remove this (dead) code.
BUG=chromium:382944
BRANCH=none
TEST=make -j buildall
Change-Id: Id3a4a93612d1078a3239d85921a05cfd7362b84c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204162
Reviewed-by: Doug Anderson <dianders@chromium.org>
If at-shutdown is specified, the battery is cut off
1 seconds after the host has shutdown.
BUG=chrome-os-partner:29292,chrome-os-partner:28887
BRANCH=tot,nyan
TEST=Run batterycutoff ectool command and cutoff console
command with and without 'at-shutdown' option. Verify
the battery is cut off immediately without the option
specified and 1 seconds after shutdown with. View the
console log to see the deferred cutoff occur.
The following tests are verified on big.
console:
cutoff, AC on: system is off after removing AC.
cutoff, AC off: system is off immediately.
at-shutdown, AC on: system is off after "power off" and removing AC.
at-shutdown, AC off: system is off after "power off".
ectool:
batterycutoff, AC on: system is off after removing AC.
batterycutoff, AC off: system is off immediately.
at-shutdown, AC on: battery is cut off after 1s of shutdown.
system is off right after removing AC power.
at-shutdown, AC off: system is off after 1s of shutdown.
[84.058416 power state 3 = S0, in 0x0000]
[84.058803 power lost input; wanted 0x0001, got 0x0000]
[84.059120 power off 3]
[84.072148 Cutting off battery in 1 second(s)]
[84.123896 power shutdown complete]
[84.128790 power state 7 = S0->S3, in 0x0002]
[84.139694 power state 2 = S3, in 0x0002]
[84.150857 power state 8 = S3->S5, in 0x0002]
[84.166975 power state 1 = S5, in 0x0002]
[84.177972 power state 1 = S5, in 0x0002]
[85.080012 Battery cut off succeeded.]
Change-Id: Id4bacf79ad3add885260655f80cb8127bafe1ad6
Signed-off-by: Dave Parker <dparker@google.com>
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203694
Reviewed-by: Vic Yang <victoryang@chromium.org>
Use a EC to PD host command to notify the PD MCU when a battery
is present and charged enough that it is ok to negotiate for a
higher power. The PD MCU will not negotiate until the host command
is received, which allows the system to be powered without a
battery or with a dead battery with 5V.
BUG=chrome-os-partner:28611
BRANCH=none
TEST=Tested on a samus:
1) Tested the normal case of battery charged and plugged in. When
charger is plugged in, the device immediately starts negotiating
for 20V and starts charging.
2) Tested with no battery. Plug in a charger, samus boots and stays
alive. VBUS measured at 5V. When a battery is plugged in, device
negotiates for 20V and starts charging.
3) Tested dead battery by taking a battery with no charge, and
plugging in zinger. Everything boots, but PD does not negotiate
for power. Then when battery reaches 1%, PD negotiates and zinger
switches to 20V without causing a reboot.
Change-Id: Iaa451403674e86cddbd3fe80e9503584910be576
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201958
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This adds a new lightbar sequence (TAP), which temporarily displays the
battery level. It pulses if the system is charging.
BUG=chrome-os-partner:29041
BRANCH=ToT
TEST=manual
From the EC console, run
lightbar seq tap
The lightbar should change temporarily.
Then run
lightbar demo on
and press the Up, Down, Left, and Right keys to fake the battery charge
level (up & down) and the AC present state (left & right). Run the
lightbar seq tap
command periodically to watch it change.
Change-Id: I84ff928d93060f7ef7d46d608732d37cf5185aff
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202964
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds three new lightbar subcommands to the EC_CMD_LIGHTBAR_CMD host
command, allowing the AP to read the current brightness level, the
current lightbar LED values, and the state of demo mode.
Because this is new, also update LIGHTBAR_IMPLEMENTATION_VERSION. All the
previous commands are unchanged, though.
BUG=chrome-os-partner:28596
BRANCH=ToT
TEST=manual
From the AP, run these commands to see the changes:
ectool version
ectool lightbar brightness
ectool lightbar 0
ectool lightbar 1
ectool lightbar 2
ectool lightbar 3
ectool lightbar demo
The version output is different, the other commands used to just emit
errors.
Change-Id: If32a5d2388217edc3ae7b9b091d66e9d2cf753be
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199881
Reviewed-by: Randall Spangler <rspangler@chromium.org>
While debugging reboot issue, it was difficult to get POST code from failing
boards. Currently POST code is only accessible from EC console. Not all boards
are fitted with servo board.
This patch adds Port 80 history access from ectool. Reuse command code 0x48,
EC_CMD_PORT80_LAST_BOOT with version 1.
Signed-off-by: Wenkai Du <wenkai.du@intel.com>
BUG=chrome-os-partner:28514
BRANCH=rambi
TEST=manually test on rambi to confirm port 80 history match EC console
Change-Id: If204d8fb457d8d8d18055f8282a406a35c03305e
Reviewed-on: https://chromium-review.googlesource.com/198012
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Wenkai Du <wenkai.du@intel.com>
Commit-Queue: Wenkai Du <wenkai.du@intel.com>
Tested-by: Wenkai Du <wenkai.du@intel.com>
ectool gpioget - returns all GPIOs (with flag info)
ectool gpioget <GPIO_NAME> - get value of <GPIO_NAME>
ectool gpioget count - returns number of GPIOs
ectool gpioget all - returns all GPIOs (with flag info)
BUG=chromium:344969
TEST="ectool gpioget [<subcmd> <GPIO_NAME>]" returns correct information
on squawks
BRANCH=none
Change-Id: Ib6f0d8135a76501f08b084bfd7eb1f2689d5d6e0
Signed-off-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196680
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Also adds 'battparam' console command.
BUG=chrome-os-partner:25145
BRANCH=ToT
TEST=Run 'ectool batteryparam set 0 0x1234'
'ectool batteryparam get 0'
and on the console:
'battparam 0'
'battparam 0 0x1234'
on a board that implements parameter 0.
Change-Id: I9cc54d001631f53dd39ae64cfdeececaa1747181
Original-Change-Id: Ib2812f57f2484309d613b23dab12ad43e0417bd2
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195824
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197162
Added a sub-command to the motionsense host command (0x2b) for getting/setting
the lid angle at which the keyboard is disabled as a wake source in S3. The
value can be anywhere from 0 to 360 degrees, default set to 180. Note, this
only takes affect for boards that have CONFIG_LID_ANGLE_KEY_SCAN defined.
Modified ectool motionsense command to use new host sub-command.
Also modified the lid angle measurement in the EC to be in the range [0, 360],
instead of [-180, 180], and changed casting of lid angle as an int to round
to nearest.
BUG=none
BRANCH=rambi
TEST=Tested on a glimmer:
Using default keyboard disable lid angle of 180, made sure that when lid
angle is past 180, key presses do not wake system, and when lid angle is
less than 180, key presses do wake up system.
Used ectool motionsense kb_wake to set the keyboard disable lid angle to 0.
Made sure that keyboard never wakes up the system. Set keyboard disable lid
angle to 360 and made sure that the keyboard always wakes up the system.
Change-Id: I437164c6e38c29169ef6e20e86c9cf2a1c78f86e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193663
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194172
Added enum for motion sensor ID's into ec_commands.h so that the host
can easily send host commands targeting the desired accelerometer.
Changed sensor present flag to just senosr flags, currently with only a
single mask defined for sensor present. This allows for easier future
expansion of various flags.
Also, added a motion sense module flags to the dump sub-command for flags
that represent all sensors, such as is the motion sense task active.
BUG=chrome-os-partner:27321
BRANCH=rambi
TEST=Manual test on a glimmer by testing ectool motionsense command
Change-Id: Iac052269a60db9ff4506f0490c3a0c6daad5b626
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193122
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193309
Created a host command to set/get various motion sensor parameters and
added an ectool command to use that host command.
The host command is created such that the first argument is a
sub-command. Sub-commands created include:
dump: dumps all current motion sensor data
info: returns general information about each motion sensor
ec_rate: set/get the EC sampling rate of sensors
sensor_range: set/get the sensor range (ie +/- 2G,4G,8G)
sensor_odr: set/get the sensor output data rate (ie 50Hz, 100Hz, ...)
For sensor_range and sensor_odr parameters, since the host doesn't know
what are valid values for the parameter, the host can specify to round
up or down to the nearest valid value. For example, the host can specify
to set the output data rate to at least 100Hz, and the EC will return
the closest valid output data rate that is at least 100Hz.
BUG=chrome-os-partner:27321
BRANCH=rambi
TEST=Test on a glimmer using ectool from vt-2 prompt:
> ectool motionsense help
Usage:
motionsense - dump all motion data
motionsense info NUM - print sensor info
motionsense ec_rate [RATE_MS] - set/get sample rate
motionsense odr NUM [ODR [ROUNDUP]] - set/get sensor ODR
motionsense range NUM [RANGE [ROUNDUP]]- set/get sensor range
>
> ectool motionsense
Sensor 0: 0, 0, 1024
Sensor 1: 1024, 0, 0
Sensor 2: None
> ectool motionsense info 0
Type: accel
Location: base
Chip: kxcj9
> ectool motionsense ec_rate
10
> ectool motionsense ec_rate 1000
1000
> ectool motionsense odr 0
100000
> ectool motionsense odr 0 40000 1
50000
> ectool motionsense range 0 8
8
After running this I verified on the EC console that all the parameters
were set appropriately. I tested the EC sampling rate was 1000ms by
running lidangle on and making sure samples were displayed roughly every
second. I verified the sensor odr and range by defining
CONFIG_CMD_ACCELS and typing:
> accelrange 0
8
> accelrate 0
50000
Change-Id: I444e2f0eafabd607f1c7aa78b5c4e91f6cb06387
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192064
Reviewed-on: https://chromium-review.googlesource.com/193307
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This replaces the obsolete and temporary (ha!) EC_CMD_CHARGE_DUMP host
command with EC_CMD_CHARGE_STATE. This is used to monitor and adjust the new
charge state implementation, including any board-specific customizations.
This command is a single catch-all command with multiple subcommands
(similar to EC_CMD_LIGHTBAR_CMD) so that we don't have to keep adding new
top-level host commands just to support incremental changes.
BUG=chrome-os-partner:23776
BRANCH=ToT
TEST=manual
From the AP, try these commands:
ectool chargestate show
ectool chargestate param
ectool chargestate param <NUM>
ectool chargestate param <NUM> <VALUE>
Watch the EC console and use its "chg" command to verify the effects of
setting various params.
Note: the Samus-specific fast-charging profile override is param 0x10000.
You can check it with the EC console "fastcharge" command.
Change-Id: Iad2f773a085bc25c05073b3eed9866f122ae9d78
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193305
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This clarifies the use of the EC's memory-mapped interface to the AP. We
always end up reverse-engineering this, so I'm just documenting what bytes
are actually used.
BUG=none
BRANCH=ToT
TEST=make buildall
No code changes, only comments.
Change-Id: Icfaa794626d2f656ab5d8a8d067b3e2663cc8882
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193052
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is needed to calibrate the tmp006 remote sensor values.
BUG=chrome-os-partner:26581
BRANCH=none
TEST='ectool tmp006raw N' works for N=0,1,2,3
And fails with invalid param for N=4.
Data matches result of tmp006 ec console command.
Change-Id: I04ec093c7727b55caca7d02baaf373d1ff234731
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189207
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Changed speed of accelerometer i2c bus to 400kHz.
Added an accelerometers present bit to the status byte for host shared
memory so that the host knows whether this system has accelerometers or
not.
BUG=chrome-os-partner:25599
BRANCH=rambi
TEST=manual test with a glimmer.
To test speed, just ran for a while at 400kHz and made sure there were
no i2c errors and the data looked accurate using the lidangle on command.
To test the accelerometers present bit, I used the kernel patch for the
cros_ec_accel driver. First, I verified that without this patch, the kernel
driver throws an error when loading the module. Second, I verified that
with this patch the module was loaded successfully.
Change-Id: I19b8e800748b0d45dc1da6c59118e92b4908ee2f
Original-Change-Id: If931b37bf057df96659852ef9699b3e6029275c7
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187732
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188386
Previously, the AP could only set the current wireless power state.
It couldn't determine what the EC would do in S3, nor could it get the
current wireless power state. Extend the wireless command to do so,
and add an EC console command to aid in debugging.
BUG=chrome-os-partner:25655
BRANCH=rambi
TEST=manual; expected numbers are from EC 'wireless' command
AP off -> 0x0, 0x9
AP on -> 0xd 0x9
AP suspended -> 0x9 0x9
AP on -> 0xd 0x9
ectool wireless 0x1 -> 0x1 0x9
ectool wireless 0xd -> 0xd 0x9
ectool wireless 0 0 0 0 -> 0xd 0x9 (and prints 0xd 0x9 to root shell)
ectool wireless 5 -1 -1 0 -> 0x5 0x9
AP suspended -> 0x1 0x9 (doesn't turn on 0x8, just turns off 0x4)
AP on -> 0xd 0x9
ectool wireless 0 0 0 -1 -> 0xd 0x0
AP suspended -> 0x0 0x0
AP on -> 0xd 0x9
Change-Id: I8ead2d4a4423b51ec4f638bf94c62de98726b25c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187273
After each read of the accelerometers, add accelerometer
data to LPC shared memory.
BUG=none
Original-BUG=chrome-os-partner:25599
BRANCH=rambi
TEST=Manual test by reading the LPC shared memory through cros_ec
in the kernel.
Original-Change-Id: If66df3fcb32b5423f4fa7dd471c219a1c4df7095
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186456
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 919ea7fe1f830235ae56829a8ee4435679dec124)
Change-Id: I10525c45e868d0b04aa84c27cab3b6baeda2b0d5
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187435
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The spec does not mandate any way to read back the threshold settings
themselves, but when a threshold is crossed the AP needs a way to determine
which sensor(s) are responsible. Each reading of the EC_ACPI_MEM_TEMP_ID
register clears and returns one sensor ID that has crossed one of its
thresholds (in either direction) since the last read. A value of 0xFF means
"no new thresholds have tripped". Changing or enabling the thresholds for
any sensor will clear the unread event count for that sensor.
BUG=chrome-os-partner:23970
BRANCH=none
TEST=manual
On the host, set a couple of thresholds to low values so they trip
immediately (I'm testing on Link):
# dptf() {
[ "$#" -eq "2" ] || return;
iotools io_write8 0x66 0x81
iotools io_write8 0x62 $1
iotools io_write8 0x62 $2
}
#
# dptf 5 0
# dptf 6 10
# dptf 7 3
# dptf 5 2
# dptf 6 10
# dptf 7 2
On the EC console, see that two thresholds have triggered, and that there
are two bits set in the AP seen mask:
[45.755365 DPTF sensor 0, threshold -63 C, index 1, enabled]
[45.768940 DPTF sensor 2, threshold -63 C, index 0, enabled]
[46.169490 DPTF over threshold [0][1]
[46.169820 DPTF over threshold [2][0]
> dptftemp
sensor thresh0 thresh1
0 --- 210* I2C-USB C-Die
1 --- --- I2C-USB C-Object
2 210* --- I2C-PCH D-Die
3 --- --- I2C-PCH D-Object
4 --- --- I2C-Hinge C-Die
5 --- --- I2C-Hinge C-Object
6 --- --- I2C-Charger D-Die
7 --- --- I2C-Charger D-Object
8 --- --- ECInternal
9 --- --- PECI
AP seen mask: 0x00000005
>
Read the EC_ACPI_MEM_TEMP_ID register from the host, to get the two active
sensor IDs (0 and 2), then 0xff when those are seen.
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 5; iotools io_read8 0x62
0x00
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 5; iotools io_read8 0x62
0x02
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 5; iotools io_read8 0x62
0xff
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 5; iotools io_read8 0x62
0xff
#
Change-Id: I8f047a517357617f18ad59d21fa13409bc81821b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180224
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds three new registers to the ACPI->EC interface, which will allow
the AP to set/clear two DPTF thermal threshold points for each temp sensor.
The registers are
EC_ACPI_MEM_TEMP_ID 0x05
EC_ACPI_MEM_TEMP_THRESHOLD 0x06
EC_ACPI_MEM_TEMP_COMMIT 0x07
It doesn't actually do anything yet, but the AP can now write those values.
BUG=chrome-os-partner:23970
BRANCH=none
TEST=manual
On the host:
dptf() {
[ "$#" -eq "2" ] || return;
iotools io_write8 0x66 0x81
iotools io_write8 0x62 $1
iotools io_write8 0x62 $2
}
Now watch the EC console while running on the host:
dptf 5 1
dptf 6 80
dptf 7 2
dptf 7 3
The EC should say
DPTF sensor 1, threshold 7 C, index 0, enabled
DPTF sensor 1, threshold 7 C, index 1, enabled
Change-Id: I71fa57e3ca7c7b5bb8892e63212bf294b44dece5
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179778
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds include/dptf.h to define the DPTF interface functions.
As the first DPTF feature, it also adds a register to the EC's ACPI
interface block. Register 0x04 is used to get and set the fan's target duty
cycle, as a percentage value. Writing a 0 to this register will set the
target duty cycle to 0, writing a 100 (0x64) will set it to 100%. Writing
any other value will return the fan control to the EC, rather than driving
it manually from the host.
Likewise, reading from this register returns the current fan target duty
cycle, as a percentage. If the EC is controlling the fan automatically, the
returned value will be 0xFF.
BUG=chrome-os-partner:23972
BRANCH=none
TEST=manual
You can monitor the fan state from the EC console with the "faninfo"
command. From the host side, test this interface from a root shell.
Read fan duty:
iotools io_write8 0x66 0x80
iotools io_write8 0x62 4
iotools io_read8 0x62
Set fan duty to 100%:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 100
Set fan duty to 50%:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 50
Set fan duty to 0%:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 0
Set fan control back to automatic:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 -1
Change-Id: I91ec463095cfd17adf452f0967da3944b254d558
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177423
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The struct lightbar_params used to communicate lightbar settings between the
AP and the EC uses just "int" for some of its fields. The AP currently uses
32-bit values for "int" in both 64-bit and 32-bit mode, but that's just luck
since C only requires that "int" be at least 16 bits.
This change makes the size explicit.
BUG=none
BRANCH=none
TEST=manual
There should be no visible change.
ectool lightbar params > /tmp/foo
ectool lightbar params /tmp/foo
Change-Id: I4d77c16b3c68e179292b824938d2d012e917ad13
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176364
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
This adds space for up to two ALS lux readings to be available to the AP
through the memory-mapped LPC region. If enabled, the values are updated
once a second.
The ALS will be reinitialized at every AP resume, since it's typically
unpowered otherwise. The reported value will be zero when the ALS is off.
BUG=chrome-os-partner:23380
BRANCH=samus
TEST=manual
Boot the AP, then from the EC console run "als" or just monitor the
memory-mapped region directly ("rw 0x40080780" on Samus), while pointing the
sensor at bright and dim areas. The value should change.
Change-Id: I705371fcd57345dc9adae1231ea30c7ff024aaf8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176142
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Device-specific headers belong in driver/ or chip/. The include/
directory should be for common interfaces.
Code should not normally need to include driver-specific headers. If
it does, it should use the full relative path from the EC project root
(for example, drivers/charger/bq24715.h).
Change-Id: Id23db37a431e2d802a74ec601db6f69b613352ba
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173746
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Some of the comments no longer apply. Others needed more info.
No code changes; just comment changes.
BUG=none
BRANCH=none
TEST=build all platforms
Change-Id: I1d52aa9a98427a78c9d9a8cf44934fb04c3c00c8
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174084
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The fixme was just a feature request. I've moved it to a new bug.
Comment change only; no code changes.
BUG=chrome-os-partner:23457
BRANCH=none
TEST=build rambi
Change-Id: Ie3fc0482b6697c12040b868ba837073929cf5b82
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173921
Reviewed-by: Vic Yang <victoryang@chromium.org>
We've removed a few constants from the exported header file since the last
big sync. Just in case some of them are still in use (coredump, flashrom),
let's make it easy to redistribute the header unchanged. We can remove them
for real next time.
BUG=chromium:251441
BRANCH=none
TEST=manual
Compile, test, run, etc. This CL just adds back some unused (by the EC)
constants that were previously removed, so nothing should change.
Change-Id: Ia9889db89a90d56c8154fea1e8c8a483fdcae805
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170522
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Having a per-device enum list for use by the EC_CMD_GET_SET_VALUE command
won't work when the one-and-only ectool tries to talk to different devices.
Any particular enum may be missing or have a completely different meaning.
Instead, we can do the same thing that EC_CMD_HOST_EVENT_* does - use the
same structs for a bunch of different commands.
If/when we run out of command numbers (it's currently only 8 bits), we'll
just switch to using EC protocol v3 (see crosbug.com/p/20820), which
provides 16 bits for the command.
This CL renames EC_CMD_GET_SET_VALUE to EC_CMD_GSV_PAUSE_IN_S5 (since that's
the one-and-only use of it at present), and renames the params/response
structs as well. Since only the names are changing, the implementation
remains backwards-compatible (assuming the flags value usage is preserved by
ectool for the EC_CMD_GSV_PAUSE_IN_S5 command, which it is).
If I can cherry-pick this change into the one place where it's being used, I
will.
BUG=chromium:287969
BRANCH=ToT
TEST=manual
Although this is primarily an internal name change, it also means that the
commands to invoke the previous usage of this feature have changed. To test:
On Haswell systems only.
To enable the pause in S5 at shutdown, do either of these:
EC console: pause_in_s5 on
root shell: ectool pause_in_s5 on
Shut the AP down politely, and it should pause in S5 for 10 seconds before
continuing to G3. You can see this by watching the EC console.
To disable the pause in S5 at shutdown, do any of these:
EC console: pause_in_s5 off
root shell: ectool pause_in_s5 off
or
press Refresh + POWER
Boot the system, then politely shut down. This time it should go directly to
G3 without pausing in S5.
Change-Id: Ic614fed37ad89db794c2bbcca2b83d1603030ab2
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168816
This adds EC_CMD_GET_SET_VALUE to the list of host commands. We have a bunch
of single-value getter/setter commands, which is wasteful. This is a start
towards unifying them into a simpler command.
BUG=chromium:285358
BRANCH=ToT,falco
TEST=none
There's nothing to test just yet. This just adds the command and some basic
interfaces. A future commit will make use of it.
Change-Id: Iee986b9d273b422bb06f3a0c9b7af50617f03d7f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168083
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Most systems don't have a lightbar. Those that do need a way to detect that
one exists. That's easily done by just sending a EC_CMD_LIGHTBAR_CMD command
to the EC and checking the result. If the response is
EC_RES_INVALID_COMMAND, there isn't a lightbar.
But what .cmd value should we use in struct ec_params_lightbar? Future
lightbar implementations (if any), could remove existing functions or add
new ones, so there isn't a safe choice.
This change adds a LIGHTBAR_CMD_VERSION operation to determine if any new
implementation exists. Future systems should return some useful information
in response to this command. Existing systems will return
EC_RES_INVALID_PARAM, which is enough to distinguish them.
BUG=chromium:239205
BRANCH=none
TEST=manual
make BOARD=link
make BOARD=link runtests
There are no user-visible changes in functionality to anything.
Change-Id: Ibe37f74a4dcbf68dd6bfd1963530aec907e67534
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167549
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Problems with existing thermal control loop:
* Not multi-board friendly. thermal.c only supports Link and needs
refactoring. Temp thresholds and fan speeds are hard-coded.
* Only the PECI temp is used to determine the fan speed. Other temp sensors
are ignored.
* Has confusing data structures. Values in the CPU temp thresholds array mix
ACPI thresholds with fan step values.
With this change, the thermal task monitors all temp sensors in order to
perform two completely independent functions:
Function one: Determine if the host needs to be throttled by or informed of
any thermal events.
For thermal events, each temp sensor will have three threshold levels.
TEMP_HOST_WARN
* When any sensor goes above this level, host_throttle_cpu(1) will be called
to ask the CPU to slow itself down.
* When all sensors drop below this level, host_throttle_cpu(0) will be called.
* Exactly AT this level, nothing happens (this provides hysteresis).
TEMP_HOST_HIGH
* When any sensor goes above this level, chipset_throttle_cpu(1) will be
called to slow the CPU down whether it wants to or not.
* When all sensors drop below this level, chipset_throttle_cpu(0) will be
called.
* Exactly AT this level, nothing happens (this provides hysteresis).
TEMP_HOST_SHUTDOWN
* When any sensor is above this level, chipset_force_shutdown() will be
called to halt the CPU.
* Nothing turns the CPU back on again - the user just has to wait for things
to cool off. Pressing the power button too soon will just trigger shutdown
again as soon as the EC can read the host temp.
Function two: Determine the amount of fan cooling needed
For fan cooling, each temp sensor will have two levels.
TEMP_FAN_OFF
* At or below this temperature, no active cooling is needed.
TEMP_FAN_MAX
* At or above this temperature, active cooling should be running at maximum.
The highest level of all temp sensors will be used to request the amount of
active cooling needed. The function pwm_fan_percent_to_rpm() is invoked to
convert the amount of cooling to the target fan RPM.
The default pwm_fan_percent_to_rpm() function converts smoothly between the
configured CONFIG_PWM_FAN_RPM_MIN and CONFIG_PWM_FAN_RPM_MAX for percentages
between 1 and 100. 0% means "off".
The default function probably provide the smoothest and quietest behavior,
but individual boards can provide their own pwm_fan_percent_to_rpm() to
implement whatever curves, hysteresis, feedback, or other hackery they wish.
BUG=chrome-os-partner:20805
BRANCH=none
TEST=manual
Compile-time test with
make BOARD=falco runtests
On the EC console, the existing fan commands should work correctly:
faninfo - display the fan state
fanduty NUM - force the fan PWM to the specified percentage (0-100)
fanset RPM - force the fan to the specified RPM
fanset NUM% - force the fan to the specified percentage (0-100) between
its configured minimum and maximum speeds from board.h
(CONFIG_PWM_FAN_RPM_MIN and CONFIG_PWM_FAN_RPM_MAX)
fanauto - let the EC control the fan automatically
You can test the default pwm_fan_percent_to_rpm() with
fanset 1%
faninfo
The fan should be turning at CONFIG_PWM_FAN_RPM_MIN. Let the EC control it
automatically again with
fanauto
Also on the EC console, the thermal settings can be examined or changed:
> temps
PECI : 327 K = 54 C
ECInternal : 320 K = 47 C
G781Internal : 319 K = 46 C
G781External : 318 K = 45 C
>
> thermalget
sensor warn high shutdown fan_off fan_max name
0 373 387 383 333 363 PECI
1 0 0 0 0 0 ECInternal
2 0 0 0 0 0 G781Internal
3 0 0 0 0 0 G781External
>
> help thermalset
Usage: thermalset sensor warn [high [shutdown [fan_off [fan_max]]]]
set thermal parameters (-1 to skip)
>
> thermalset 2 -1 -1 999
sensor warn high shutdown fan_off fan_max name
0 373 387 383 333 363 PECI
1 0 0 0 0 0 ECInternal
2 0 0 999 0 0 G781Internal
3 0 0 0 0 0 G781External
>
From the host, ectool can be used to get and set these parameters with
nearly identical commands:
ectool thermalget
ectool thermalset 2 -1 -1 999
Change-Id: Idb27977278f766826045fb7d41929953ec6b1cca
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66688
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Glue between the existing ectool led command and the
led control logic.
BUG=chrome-os-partner:20776
BRANCH=peppy
TEST=Manual. Run "ectool led" commands:
Should pass:
ectool led power blue|yellow|off|auto|blue=1 yellow=1
ectool led battery blue|yellow|off|auto|blue=1 yellow=1
Should fail:
ectool led adapter <color>
ectool led power|battery red|green|white
Signed-off-by: Dave Parker <dparker@chromium.org>
Change-Id: I2540940baa553866760dd9ae62278b6b845793ef
Reviewed-on: https://gerrit.chromium.org/gerrit/64627
The old low-level SPI protocol provided no useful information to the
host about whether it was ready to receive or not. It also could get
stuck waiting to receive data without setting up receive DMA, if the
host did two transactions back-to-back.
Add a real state machine to the SPI module.
Add a range of byte codes the EC can return outside of a response
frame, to indicate its current state. If the AP receives one of these
codes, it can abort the transaction since it now knows the EC is
unable to determine when it can send a response frame.
This change is backwards-compatible with current AP firmware and
kernel drivers, since those only look for the framing byte and don't
care what other bytes are received in the meantime.
BUG=chrome-os-partner:20257
BRANCH=none
TEST=crosec test; passes at 70us.
Change-Id: Ia06109ead3fbc421848e01050f7baf753cbeb16c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64254
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Occasionally the EC wants to ask the AP to throttle itself. Currently, the
only thing that the EC can do (at least on x86) is to assert the PROCHOT#
signal, which is a fairly intrusive operation and one that Intel suggests we
save for emergencies.
This CL adds a new pair of host events to ask the BIOS to throttle the AP
politely, or stop doing so. The turbo charger code will send these events to
the AP if they become necessary.
BUG=chrome-os-partner:20739
BRANCH=falco,peppy
TEST=manual
Tests should still pass, everything else is unchanged.
make BOARD=${BOARD} runtests
Currently, there's nothing on the BIOS/OS side that would respond to these
events, so they're just ignored. You can test that, even without this CL, by
running
hostevent set 0x40000
hostevent set 0x80000
Change-Id: I4a7a1b6eb87e42df94ddd09f4c6abee6ebcbd485
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63379
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add an enum for the number of flash regions so we can keep track of all
the possible regions.
(This is used in U-Boot which wants to declare an array of all possible
regions.)
BUG=chromium:244019
BRANCH=none
TEST=manual
Build EC for pit.
Change-Id: I494d857f1388dcc5c64b1cd580cf0084bdef0212
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62701
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Expands and renames ectool 'chargeforceidle' command to
'chargecontrol'. Board-specific calls are needed to enable and
disable the discharge while on AC power state.
BUG=chrome-os-partner:20506
BRANCH=falco,peppy
TEST=Run ectool chargecontrol command with each option (normal,
idle, discharge) on Falco and Peppy. Verifiy battery is discharging
in discharge mode via EC console 'battery' command.
Change-Id: I7ac2b18b4f143bf6abc1e0bb878ad21a99f52100
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60689
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds two new fields: the ideal write size for best EC flashing
performance (e.g., page mode instead of word mode), and a flags field
with a flag to indicate whether the EC erases its bits to 0 or 1.
The EC still supports the old version 0 command, since u-boot and
flashrom expect that to work.
BUG=chrome-os-partner:20973
BRANCH=(all haswell); this will speed up flashing and software sync
TEST=ectool flashinfo
1. old EC, new ectool -> only reports version 0 info
2. new EC, old ectool -> only reports version 0 info
3. new EC, new ectool -> reports new fields
Change-Id: I484327fe22a58d2b69d7f6ac767b2d3e81b3e0b7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62378
Reviewed-by: David Hendricks <dhendrix@chromium.org>
