| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=none
Change-Id: I61b0b0106a43f723ec3bc805eb190aef00bbd05b
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3894391
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:173227629
TEST=make buildall -j
Change-Id: Iaf8028984cc58cc4108907fdba4ea4b38c43cf70
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3293250
Reviewed-by: Vadim Sukhomlinov <sukhomlinov@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the host command handler callback function returns an int, it's easy
to accidentally mix up the enum ec_error_list and enum ec_status types.
The host commands always expect an enum ec_status type, so we change the
return value to be of that explicit type. Compilation will then fail if
you accidentally try to return an enum ec_error_list value.
Ran the following commands and then manually fixed up a few remaining
instances that were not caught:
git grep --name-only 'static int .*(struct host_cmd_handler_args \*args)' |\
xargs sed -i 's#static int \(.*\)(struct host_cmd_handler_args \*args)#\
static enum ec_status \1(struct host_cmd_handler_args \*args)##'
git grep --name-only 'int .*(struct host_cmd_handler_args \*args)' |\
xargs sed -i 's#int \(.*\)(struct host_cmd_handler_args \*args)#\
enum ec_status \1(struct host_cmd_handler_args \*args)##'
BRANCH=none
BUG=chromium:1004831
TEST=make buildall -j
Cq-Depend: chrome-internal:1872675
Change-Id: Id93df9387ac53d016a1594dba86c6642babbfd1e
Signed-off-by: Tom Hughes <tomhughes@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1816865
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ran the following command:
git grep -l 'Copyright (c)' | \
xargs sed -i 's/Copyright (c)/Copyright/g'
BRANCH=none
BUG=none
TEST=make buildall -j
Change-Id: I6cc4a0f7e8b30d5b5f97d53c031c299f3e164ca7
Signed-off-by: Tom Hughes <tomhughes@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1663262
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There may be certain states when temperature sensors can't be
read. For instance a thermistor circuit could be tied to a power rail
that is only up when the AP is out of G3. In the function
thermal_control when there are no sensors read, it's calling a
function that adds a warning message to the EC log and sets a host
event. If the AP is in G3.
This CL adds a check for chipset state to guard against adding EC log
messages when it would be an expected state.
BUG=b:123297357
BRANCH=none
TEST=Forced AP into G3 with 'aps' and verified that the log message
"can't read any temp sensors!" is no longer being generated.
Change-Id: Id4d73f58e1d3a6d3c24b9888b385cc5e6f803782
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1481405
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the fan count is statically set. This patch allows it to
be set dynamically so that a single binary can support devices with
a different number of fans (including fan-less).
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=b:116588924
BRANCH=none
TEST=Boot Fizz with OEM=8. Verify fan spins with OEM=1.
Change-Id: I77fc4e07ce2a1be2e288df145857a79c0003542f
Reviewed-on: https://chromium-review.googlesource.com/1308257
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Provides a new EC host command 'uptime info' which gathers up some
information which may be useful for debugging spurious resets on the AP
(was the EC reset recently? Why was the EC reset? If the EC reset the
AP, why did it do so?, etc.). Provide ectool support for the same.
Example results of `ectool uptimeinfo`:
```
localhost ~ # ectool uptimeinfo
EC uptime: 475.368 seconds
AP resets since EC boot: 2
Most recent AP reset causes:
315.903: reset: console command
363.507: reset: keyboard warm reboot
EC reset flags at last EC boot: reset-pin | sysjump
```
BRANCH=none
TEST=Perform some `apreset` commands from the EC console and observe
their side-effects via the `ectool uptimeinfo` command on the AP side.
Test sequences include no-resets through 5 resets, observing that the
ring buffer handling was correct.
BUG=b:110788201, b:79529789
Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
Change-Id: I0bf29d69de471c64f905ee8aa070b15b4f34f2ba
Reviewed-on: https://chromium-review.googlesource.com/1139028
Commit-Ready: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
Tested-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modify thermal table for Fizz
reference patches: 627542, 288256, 329359
on off RPM
step0 0
step1 16 2 2800
step2 27 18 3200
step3 35 29 3400
step4 43 37 4200
step5 54 45 4800
step6 64 56 5200
step7 97 83 5600
Prochot degree:
active when t >= 88C
release when t <= 85C
Shutdown degree: when t >= 90C
BUG=b:67487721, b:64439568
BRANCH=master
TEST=fan target speed follows table, make -j buildall pass
Change-Id: I3378668a560b8ddc568fe9cbf2703613fad8e4b6
Signed-off-by: Ryan Zhang <ryan.zhang@quanta.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/729606
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since pretty much always, we've declared console commands to take
a "longhelp" argument with detailed explanations of what the
command does. But since almost as long, we've never actually used
that argument for anything - we just silently throw it away in
the macro. There's only one command (usbchargemode) that even
thinks it defines that argument.
We're never going to use this, let's just get rid of it.
BUG=none
BRANCH=none
CQ-DEPEND=CL:*279060
CQ-DEPEND=CL:*279158
CQ-DEPEND=CL:*279037
TEST=make buildall; tested on Cr50 hardware
Everything builds. Since we never used this arg anyway, there had
better not be any difference in the result.
Change-Id: Id3f71a53d02e3dc625cfcc12aa71ecb50e35eb9f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374163
Reviewed-by: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org>
BRANCH=none
BUG=chromium:631848
TEST=make buildall -j
Change-Id: I718a29b067d37af477306f9bebfcb8e71d84d4ee
Reviewed-on: https://chromium-review.googlesource.com/363008
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When none of temp sensors' temp/fan speed profile is not set(zero),
thermal control will set 0% duty over initial fan speed setting.
This patch allows fan under EC control at inital max speed
till host's DPTF sets proper fan speed.
BRANCH=master
BUG=none
TEST=1. check if fan is running at max speed until ChromeOS UI comes up.
2. check if fan is running when system is in recovery mode.
Change-Id: I1b3e69b003ba1045779e263b25ac35b103fe457e
Signed-off-by: Kyoung Kim <kyoung.il.kim@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/314363
Commit-Ready: Kyoung Il Kim <kyoung.il.kim@intel.com>
Tested-by: Kyoung Il Kim <kyoung.il.kim@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When displaying the temps, if the sensor has valid entries to
control the target fan speed, show them. This lets us see which
sensor is the main player in the cooling needed without doing a
bunch of math.
BUG=none
BRANCH=none
TEST=manual
On the EC console:
> thermalget
sensor warn high halt fan_off fan_max name
0 368 370 372 316 358 PECI
1 0 0 0 0 0 ECInternal
2 0 0 0 314 328 I2C-Charger-Die
3 0 0 0 0 0 I2C-Charger-Object
4 0 0 0 308 322 I2C-CPU-Die
5 0 0 0 0 0 I2C-CPU-Object
6 0 0 0 301 317 I2C-Left C-Die
7 0 0 0 0 0 I2C-Left C-Object
8 0 0 0 302 316 I2C-Right C-Die
9 0 0 0 0 0 I2C-Right C-Object
10 0 0 0 303 317 I2C-Right D-Die
11 0 0 0 0 0 I2C-Right D-Object
12 0 0 0 316 327 I2C-Left D-Die
13 0 0 0 0 0 I2C-Left D-Object
Then, before this CL:
> temps
PECI : 308 K = 35 C
ECInternal : 309 K = 36 C
I2C-Charger-Die : 307 K = 34 C
I2C-Charger-Object : Not calibrated
I2C-CPU-Die : 304 K = 31 C
I2C-CPU-Object : Not calibrated
I2C-Left C-Die : 302 K = 29 C
I2C-Left C-Object : Not calibrated
I2C-Right C-Die : 303 K = 30 C
I2C-Right C-Object : Not calibrated
I2C-Right D-Die : 303 K = 30 C
I2C-Right D-Object : Not calibrated
I2C-Left D-Die : 306 K = 33 C
I2C-Left D-Object : Not calibrated
After this CL:
> temps
PECI : 308 K = 35 C 0%
ECInternal : 309 K = 36 C
I2C-Charger-Die : 307 K = 34 C 0%
I2C-Charger-Object : Not calibrated
I2C-CPU-Die : 304 K = 31 C 0%
I2C-CPU-Object : Not calibrated
I2C-Left C-Die : 302 K = 29 C 6%
I2C-Left C-Object : Not calibrated
I2C-Right C-Die : 303 K = 30 C 7%
I2C-Right C-Object : Not calibrated
I2C-Right D-Die : 303 K = 30 C 0%
I2C-Right D-Object : Not calibrated
I2C-Left D-Die : 306 K = 33 C 0%
I2C-Left D-Object : Not calibrated
Change-Id: I12bca5826e8a5a3325710fa5d39cec88f1cc95b1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240517
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our code base contains a lot of debug messages in this pattern:
CPRINTF("[%T xxx]\n") or ccprintf("[%T xxx]\n")
The strings are taking up spaces in the EC binaries, so let's refactor
this by adding cprints() and ccprints().
cprints() is just like cprintf(), except that it adds the brackets
and the timestamp. ccprints() is equivalent to cprints(CC_CONSOLE, ...)
This saves us hundreds of bytes in EC binaries.
BUG=chromium:374575
TEST=Build and check flash size
BRANCH=None
Change-Id: Ifafe8dc1b80e698b28ed42b70518c7917b49ee51
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200490
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DPTF framework will sometimes set thresholds and not expect
to get another event if the current temperature is above both the
previous threshold and the new threshold.
When a threshold is set only initialize the over condition if the
threshold was previously disabled in order to prevent it from
firing again.
BUG=chrome-os-partner:23970
BRANCH=rambi
TEST=build and boot on rambi, start DPTF framework and observe
that when a threshold is crossed (going high) and a new threshold
is set at a lower value that it does not immediately result in a
new event.
Change-Id: I6bad956fb5a49027a5c5f9c49a6fd68a0a96d693
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182004
Reviewed-by: Aaron Durbin <adurbin@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Any of the EC's temp sensors can have up to two independent thresholds
attached to them. When the temperature crosses the threshold (rising or
falling), a EC_HOST_EVENT_THERMAL_THRESHOLD event is sent to the AP. It's up
to the AP to read the sensor values and figure out why the event was sent.
The thresholds are set and enabled with ACPI writes to three registers in
the EC interface space: EC_ACPI_MEM_TEMP_ID, EC_ACPI_MEM_TEMP_THRESHOLD, and
EC_ACPI_MEM_TEMP_COMMIT. Refer to the comments in ec_commands.h for details
on their use.
ACPI does not provide any means to read the threshold settings (the AP will
just have to remember), but there is an EC console command "dptftemp", that
can be used to examine the current settings.
BUG=chrome-os-partner:23970
BRANCH=none
TEST=manual
On the EC console, check the current threshold settings and temperatures:
> dptftemp
sensor thresh0 thresh1
0 --- --- PECI
1 --- --- ECInternal
2 --- --- I2C-Charger-Die
3 --- --- I2C-Charger-Object
4 --- --- I2C-CPU-Die
5 --- --- I2C-CPU-Object
6 --- --- I2C-Left C-Die
7 --- --- I2C-Left C-Object
8 --- --- I2C-Right C-Die
9 --- --- I2C-Right C-Object
10 --- --- I2C-Right D-Die
11 --- --- I2C-Right D-Object
12 --- --- I2C-Left D-Die
13 --- --- I2C-Left D-Object
>
> temps
PECI : 318 K = 45 C
ECInternal : 306 K = 33 C
I2C-Charger-Die : 309 K = 36 C
I2C-Charger-Object : Not calibrated
I2C-CPU-Die : 309 K = 36 C
I2C-CPU-Object : Not calibrated
I2C-Left C-Die : 306 K = 33 C
I2C-Left C-Object : Not calibrated
I2C-Right C-Die : 307 K = 34 C
I2C-Right C-Object : Not calibrated
I2C-Right D-Die : 307 K = 34 C
I2C-Right D-Object : Not calibrated
I2C-Left D-Die : 306 K = 33 C
I2C-Left D-Object : Not calibrated
>
In this case, the PECI temp is 318 K, so let's set a threshold at 322 K. On
the AP:
[ "$#" -eq "2" ] || return;
iotools io_write8 0x66 0x81
iotools io_write8 0x62 $1
iotools io_write8 0x62 $2
}
Back on the EC console, we see that the threshold has been set:
[768.176648 DPTF sensor 0, threshold 49 C, index 1, enabled]
> dptftemp
sensor thresh0 thresh1
0 --- 322 PECI
1 --- --- ECInternal
2 --- --- I2C-Charger-Die
...
Now do something on the AP to increase the temperature (webgl aquarium,
etc). When the temp goes above 322 K, the EC console reports it and sends a
host event, and the "dptftemp" command indicates the over-temp condition:
[815.367442 DPTF over threshold [0][1]
[815.367878 event set 0x00000100]
[815.368069 sci 0x00000100]
[815.368619 event clear 0x00000100]
> dptftemp
sensor thresh0 thresh1
0 --- 322* PECI
1 --- --- ECInternal
2 --- --- I2C-Charger-Die
...
Log out and wait for the temp to drop. You'll see that trigger a host event
as well:
[854.375713 DPTF under threshold [0][1]
[854.376147 event set 0x00000100]
[[854.376396 event clear 0x00000100]
> dptftemp
sensor thresh0 thresh1
0 --- 322 PECI
1 --- --- ECInternal
2 --- --- I2C-Charger-Die
...
Change-Id: I6bb34c615f37477ccf37163caaa94737baed8dae
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179962
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fan no longer needs a special priority to wait for the host memmap to
become available, since LPC inits earlier.
I2C and PECI don't need explicit ordering on freq change.
Thermal now uses the explicit prio for temp sensors done.
Commented hook test.
BUG=chromium:314768
BRANCH=none
TEST=boot link; enable/disable PLL; verify fanset and temps commands work afterwards.
Change-Id: I71766614dff2950dd307acd0635405e6b59e330a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175601
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds explicit "int fan" args to the exported functions from
common/fan.c: fan_set_percent_needed() and fan_percent_to_rpm(). Within that
file, multiple fans are handled independently.
This is not complete, though. Host commands and sysjump support still only
handle a single fan, so at the moment multiple fans are treated identically
in those cases.
BUG=chrome-os-partner:23530
BRANCH=none
TEST=manual
All boards build, "make runtests" passes.
On a multi-fan system, the EC command "faninfo" displays multiple results:
> faninfo
Fan 0 Actual: 0 rpm
Fan 0 Target: 0 rpm
Fan 0 Duty: 0%
Fan 0 Status: 0 (not spinning)
Fan 0 Mode: rpm
Fan 0 Auto: yes
Fan 0 Enable: yes
Fan 1 Actual: 0 rpm
Fan 1 Target: 0 rpm
Fan 1 Duty: 0%
Fan 1 Status: 0 (not spinning)
Fan 1 Mode: rpm
Fan 1 Auto: no
Fan 1 Enable: no
>
and the "fanduty", "fanset", and "fanauto" all require the fan number as the
first arg:
> fanduty 0 30
Setting fan 0 duty cycle to 30%
> fanset 1 2000
Setting fan 1 rpm target to 2000
> fanauto 0
> fanauto 1
On single-fan systems, there is no visible change.
Change-Id: Idb8b818122e157960d56779b2a86e5ba433bee1b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175368
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of just configuring fan support as yes/no, we'll use it to specify
the number of fans on the board. Undefined (not zero!) means no fan support
at all.
Syntax change only. No new functionality.
BUG=chrome-os-partner:23530
BRANCH=none
TEST=manual
make runtests, build all platforms, build and test on Link.
Change-Id: Iff65efa69e05f3e1a54fdc2a8da9001b4e8487ca
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175150
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This looks like a lot, but it's really just moving the non-board-specific
stuff from chip/lm4/fan.c into common/fan.c, updating the appropriate
headers, and renaming functions to better match the new location.
This is entirely code refactoring and renaming. No new functionality.
BUG=chrome-os-partner:23530
BRANCH=none
TEST=manual
make runtests, build all platforms, build and test on Link.
Change-Id: I7dc03d6732bad83cf838a86600b42a7cff5aa7aa
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175012
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No code changes, just replacing a FIXME from the comments with a more
thorough explanation.
BUG=chrome-os-partner:20805
BRANCH=none
TEST=build falco
Change-Id: Ibd98322c2b9fd6e0447771ce5fe43e0283743c60
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173930
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, it doesn't compile unless CONFIG_FAN is defined.
BUG=chrome-os-partner:22803
BRANCH=none
TEST=temporarily undefine CONFIG_FAN in board/link/board.h; code compiles
and all unit tests pass
Change-Id: I251d670ccd299f7a50b1455364a817e07fad4cb1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170106
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Depending on the system, the AP can be throttled in at least two different
ways - politely, where it's just asked to slow down a bit, and forcefully
using a hardware signal (like PROCHOT). In addition, the request for
throttling can come from multiple tasks.
This CL provides a single interface, specifying both the type of throttling
desired and the source of the throttling request.
For each type, any source can can start throttling, but all sources must
agree before it stops. The changes are protected by a mutex, so that
requests from multiple tasks don't interfere with each other.
BUG=chrome-os-partner:20739,chromium:287985,chromium:287983
BRANCH=ToT
TEST=manual
Build-time test:
cd src/platform/ec
make BOARD=falco runtests
Run-time test: Lower the temp thresholds, turn the fan off, and watch the
throttling turn off and on as things heat up. For example, on the EC
console:
> temps
PECI : 339 K = 66 C
ECInternal : 324 K = 51 C
G781Internal : 328 K = 55 C
G781External : 327 K = 54 C
> thermalset 0 341 343
sensor warn high halt fan_off fan_max name
0 341 343 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
>
> temps
PECI : 339 K = 66 C
ECInternal : 324 K = 51 C
G781Internal : 328 K = 55 C
G781External : 327 K = 54 C
>
> fanduty 0
Setting fan duty cycle to 0%
>
> apthrottle
AP throttling type 0 is off (0x00000000)
AP throttling type 1 is off (0x00000000)
>
[430.152000 thermal WARN]
[430.152233 event set 0x00020000]
[430.152497 event clear 0x00020000]
[430.152714 ACPI query = 18]
[430.152444 sci 0x00020000]
[430.153051 set AP throttling type 0 to on (0x00000001)]
> gpioget CPU_PROCHOT
0 CPU_PROCHOT
>
[436.153742 thermal HIGH]
[436.153979 set AP throttling type 1 to on (0x00000001)]
> gpioget CPU_PROCHOT
1* CPU_PROCHOT
> [441.155319 thermal no longer high]
[441.155587 set AP throttling type 1 to off (0x00000000)]
[442.155604 thermal HIGH]
[442.155841 set AP throttling type 1 to on (0x00000001)]
[446.156623 thermal no longer high]
[446.156890 set AP throttling type 1 to off (0x00000000)]
temps
PECI : 343 K = 70 C
ECInternal : 324 K = 51 C
G781Internal : 328 K = 55 C
G781External : 327 K = 54 C
>
[447.156827 thermal HIGH]
[447.157064 set AP throttling type 1 to on (0x00000001)]
apthrottle
AP throttling type 0 is on (0x00000001)
AP throttling type 1 is on (0x00000001)
> gpioget CPU_PROCHOT
1 CPU_PROCHOT
>
Now turn the fan back on:
> fanauto
>
[456.159306 thermal no longer high]
[456.159574 set AP throttling type 1 to off (0x00000000)]
> apthrottle
AP throttling type 0 is on (0x00000001)
AP throttling type 1 is off (0x00000000)
> temps
PECI : 341 K = 68 C
ECInternal : 324 K = 51 C
G781Internal : 328 K = 55 C
G781External : 327 K = 54 C
>
[473.163905 thermal no longer warn]
[473.164168 event set 0x00040000]
[473.164453 event clear 0x00040000]
[473.164670 ACPI query = 19]
[473.164379 sci 0x00040000]
[473.164987 set AP throttling type 0 to off (0x00000000)]
temps
PECI : 340 K = 67 C
ECInternal : 324 K = 51 C
G781Internal : 328 K = 55 C
G781External : 327 K = 54 C
>
> apthrottle
AP throttling type 0 is off (0x00000000)
AP throttling type 1 is off (0x00000000)
>
Change-Id: I9ee1491a637d7766395c71e57483fbd9177ea554
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168802
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 89e688a3325e91d3c59ac639f04f2c91019c9b10.
Time-scaling is added back. We can run this test now.
BUG=chrome-os-partner:19236
TEST=Pass the test.
BRANCH=None
Change-Id: Id3dcec6fc12489f5f0602de91c6560a8dfbef9af
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51551
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Time-scale functionality is temporarily reverted and this test
is now taking too long. Revert this test now. Will add it back
when we solve the time-scale issue.
This reverts commit d9cf88b35ad211d873f48b41fd985e22ff049b83
Change-Id: Id9ce1071eb2114dd6968d3df9f0bce395edaeef6
Reviewed-on: https://gerrit.chromium.org/gerrit/51482
Commit-Queue: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=chrome-os-partner:19236
TEST=Pass the test.
BRANCH=None
Change-Id: I1c96437e1fb3492faa5352383f852dc1d2718ace
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51248
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sadly, the existence of fans may not always imply the existence of keyboard
backlights.
BUG=chrome-os-partner:18825
BRANCH=slippy
TEST=manual
Use the Link EC console to make sure that both functions still behave.
faninfo
fanset 4400
faninfo
fanset 9999
faninfo
autofan
faninfo
fanduty 50
faninfo
fanduty 100
faninfo
autofan
kblight 0
kblight 100
kblight 50
kbligth 100
Change-Id: I2e07cd46c21bce2d0d4162275a8ea6ae40135e96
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49355
|
|
|
|
|
|
|
|
|
|
|
|
| |
They're not x86-specific, so move to the chipset interface.
BUG=chrome-os-partner:15579
BRANCH=none
TEST=x86reset warm, then x86reset cold. Should reboot OS in each case.
Change-Id: Ib571ab916bab16179198a0d054320e59afbae124
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36785
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We'd defined them in a number of different files. This moves
definitions to timer.h, and uses them everywhere we have large delays
(since 10*SECOND is less typo-prone than 10000000).
Also add msleep() and sleep() inline functions. No need for mdelay()
or delay(), since any delays that long should use sleep funcs instead
of spin-waiting.
BUG=chrome-os-partner:15579
BRANCH=none
TEST=boot system; taskinfo displays similar numbers to before
Change-Id: I2a92a9f10f46b6b7b6571759b1f8ab4ecfbf8259
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36726
|
|
|
|
|
|
|
|
|
|
|
|
| |
No functional changes.
BUG=chrome-os-partner:15579
BRANCH=none
TEST='temps' should print good temperatures
Change-Id: I20bd2376b86f1e9d2f9a91016ed90bb933235021
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36611
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, all hook functions returned EC_SUCCESS, which was
meaningless because nothing ever looked at the return value. Changing
the return value to void saves ~100 bytes of code size and an equal
amount of source code size.
BUG=none
BRANCH=none
TEST=code still builds; link still boots
Change-Id: I2a636339894e5a804831244967a9c9d134df7d13
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36372
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, any command which set the fan duty manually would leave
the PWM RPM controller disabled. Setting the fan back to auto mode
via 'ectool autofanctrl' or 'autofan' or 'ectool pwmsetfanrpm'
wouldn't turn the controller back on. Now it does.
BUG=chrome-os-partner:14307
BRANCH=link
TEST=manual
- Reboot in recovery mode and wait for INSERT screen
- From EC console
fanduty 100 -> fan turns on all the way
faninfo -> mode is duty
fanset 6000 -> fan turns down to a lower level
faninfo -> mode is rpm
fanduty 0 -> fan turns off all the way
faninfo -> mode is duty
(wait a min or so for the system to heat up)
autofan -> fan turns on
faninfo -> mode is rpm
- Reboot normally
- From root shell
ectool fanduty 100 -> fan turns on all the way
ectool pwmsetfanrpm 6000 -> fan turns down to a lower level
Change-Id: I3b07e8b49500f5f8a42f20909d2869cf63987d6d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35335
Reviewed-by: Sameer Nanda <snanda@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The remote temperature sensors for case temps are now not used until
they're calibrated by the host. But the EC still tries to control the
fan based on case temps. At best this has no effect because the
sensors haven't been enabled by host calibration. At worst, the host
calibrates them, but doesn't set up the temerature thresholds to
match, so the EC spins up the fan briefly during boot before the host
takes over (annoying), or potentially asserts prochot, shuts the
system down, or triggers a bunch of SMIs (really annoying). It's
safer just to leave these thresholds disabled by default; if the host
wants the EC to use them, it can easily set them at the same time it
sets the remote sensor calibration data.
Also, adjust overheated thresholds up based on snanda's recommendations.
BUG=chrome-os-partner:9193
BRANCH=link
TEST=thermalconf 2 --> should print 0 K for all levels
Change-Id: I5bd1ea65eaefc4d39238b22363176d32663434a0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35449
Reviewed-by: Sameer Nanda <snanda@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, if the AP took fan control, the EC would never take it
back. This meant the EC would leave the fan off even if the system
was sitting at the INSERT screen or booted an alternate OS.
BUG=chrome-os-partner:15189
BRANCH=link
TEST=manual
- boot system
- from EC console, fanset 0
- faninfo shows fan at 0rpm
- from root shell, crossystem recovery_request=123 && reboot
- wait a few mins
- faninfo should show fan spinning again
Change-Id: I534c9978194085467f1df6eae971c55d4e8083be
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35309
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the need for a separate method to check sensor power, and
gets rid of temp_sensor.c knowledge of what powers each sensor.
BUG=chrome-os-partner:15174
BRANCH=link
TEST=manual
- reboot
- within a second, type 'temps'; I2C sensors should return error 1
- type 'temps' again; all sensors should return data
- power off system
- type 'temps' again; I2C sensors and PECI should return error 8
- 'gpioset enable_vs 1'
- type 'temps' again; I2C sensors should return valid data; PECI should still
return error 8.
Change-Id: I17c353b3c483bc320769307c7715008ec729089b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35287
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will be used in a follow-up CL to return specific error codes
(not powered, not calibrated, etc.)
BUG=chrome-os-partner:15174
BRANCH=link
TEST=manual
Power on system.
'temps' should return all good temps.
Power off system (into S5)
Only ECInternal temp should work; others should return Error 1
'gpioset enable_vs 1' and wait a second
Now all the I2C temps should display good data, but PECI will still be error 1.
Change-Id: I925434e71653ad53ad76bad992a7a8fdeadb088c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35286
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=chrome-os-partner:12353
TEST=hack the thermal monitoring and/or battery code to trigger a shutdown
then see that the events get set
Change-Id: I5ef2ac03cdd793ab0c50c0db518cba1ede3ea036
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29429
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As per James advice :
- increase fan speed at low temperature up to maximum "silent RPM",
this will give us more margin for later operations.
- lower the maximum fan RPM threshold to 86 C to try to lower CPU
temperature impact on skin temp.
- do not take into account "object" temp sensors, they are too random
at the moment.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=adhoc
Change-Id: I3b60570e33f82e4015c6588d9e2ae538a33ad14f
Reviewed-on: https://gerrit.chromium.org/gerrit/27921
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have a system with bad temperature sensors and the EC is
constantly shutting the system down, but provides no
visible indication that it is doing so.
I have serious concerns about the EC behavior in this case
as it seems to be doing things it shouldn't. However just
providing indication via the console about what it is doing
is at least useful for development and debug.
BUG=none
TEST=boot on system with bad temp sensors and see that
the EC indicates it is initiating a shutdown.
[14.008340 critical temperature; shutting down]
[14.008660 x86 power force shutdown]
[14.009153 LPC RESET# asserted]
Change-Id: I6beeb269a135bd8c245c0357670fe29648d48968
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27553
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
| |
BUG=chrome-os-partner:11090
TEST=suspend laptop, then press power button; should resume from suspend
Change-Id: I36b7c62b2e115bb97d37defcd3c783af0f91d5f8
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26730
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This sensor doesn't provide accurate case temperature. Let's
disable thermal thresholds for the object tempearture reading from this
sensor.
BUG=chrome-os-partner:9599
TEST=Build success. System works fine.
Change-Id: I9408de59a3349f944c5e215085da93f23965ebc9
Reviewed-on: https://gerrit.chromium.org/gerrit/25824
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Perviously we have a 10-second delay for all temperature sensor. This is
not suitable for CPU temperature. Let's change that to have an option to
set the delay length for each temperature sensor. And also shorten the
delay of TMP006 sensor to 7 seconds, that of EC internal temperature to
4 seconds, and that of PECI CPU temperature to 0 second.
Signed-off-by: Vic Yang <victoryang@chromium.org>
BUG=chrome-os-partner:10233
TEST=Check EC issued warning as soon as CPU temperature reached the
threshold.
(cherry picked from commit cf24df7f3ee24eaa5dbeae3b304d11ddada9a914)
Change-Id: Id2cc4a437bde15697afe4020b6153e5d13466759
Reviewed-on: https://gerrit.chromium.org/gerrit/24694
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Vic Yang <victoryang@chromium.org>
BUG=none
TEST=none
Change-Id: I369522c00724c959d1eac18ca9c3ce57bd55aeff
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Additional help messages and usage are gated by
CONFIG_CONSOLE_CMDHELP, so we can turn it on if there's space (adds
about 3KB to image size) and turn it off when there isn't.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=none
TEST=manual
1) help
2) help list
3) help gpioset
4) gpioset -> wrong number of params
5) gpioset fred 0 -> param1 bad
6) gpioset cpu_prochot fred -> param2 bad
Change-Id: Ibe99f37212020f763ebe65a068e6aa83a809a370
|
|
|
|
|
|
|
|
|
|
| |
'ectool thermalget' should return error if sensor ID or threshold ID is
out of range. This CL fixes a bug that error codes mismatch.
BUG=chrome-os-partner:9840
TEST='ectool thermalget 0 10' gives error.
Change-Id: I74d0c66044cd31743c4fac0a8dc0431db6259e71
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Preparatory work to use common host command code between ARM and x86.
Just rename constants, do not change the binary API.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:9614
TEST=make BOARD=link
Change-Id: I534d427c9b50103273835a6f32a0ddb622c762b3
|
|
|
|
|
|
|
|
|
|
|
|
| |
This would throttle proto1 systems, if it weren't for a HW bug which
means we don't have prochot control over proto1 systems at all.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8982
TEST=system still boots
Change-Id: Ie42c034141f24795ec2bfee592e194001d3cd174
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The EC console input handling code is being enhanced to accept
abbreviated command names.
If the abbreviation is unique, the appropriate command is used, if the
abbreviation is ambiguous, the command is handled as nonexistent. The
error message is being modified to mention that the command either
does not exist or is ambiguous.
This change also makes it impossible to have command names matching
the beginning of other command names. Two such cases are being fixed
(`ch' renamed to `chan' and `thermal' renamed to 'thermalconf').
BUG=none
TEST=manual
. program the new EC image. Try entering at the console:
> h
Command 'h' either not found or ambiguous.
Command returned error 1
> he
Known commands:
adc autofan battery ch charger
...
> help
Known commands:
adc autofan battery ch charger
...
Change-Id: Iaa3e91e1504e42daefb02d561e00c39003548197
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
|