| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This enables the AP to limit charging current via ACPI.
BUG=chrome-os-partner:23971
BRANCH=rambi
TEST=manual
drain battery down to <90%, then plug into AC
(charger commands at EC console, iotools at root shell)
iotools io_write8 0x66 0x81
iotools io_write8 0x62 0x08
iotools io_write8 0x62 3
charger -> dptf limit 192, I_batt=192
charger dptf 320
charger -> dptf limit 320, I_batt=320
iotools io_write8 0x66 0x80
iotools io_write8 0x62 0x08
iotools io_read8 0x62 -> 0x05
iotools io_write8 0x66 0x81
iotools io_write8 0x62 0x08
iotools io_write8 0x62 0xff
charger -> dptf disabled, I_batt=(something > 192)
iotools io_write8 0x66 0x80
iotools io_write8 0x62 0x08
iotools io_read8 0x62 -> 0xff
Change-Id: Iace2ebbbc018143c0154310d7acd02d16a6b7339
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185411
Reviewed-by: Bill Richardson <wfrichar@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>
|
|
|
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>
|
