| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If HAS_TASK_CHIPSET is not defined, common/power.c is not compiled.
So provide a default implementation which indicates the chipset
is always off.
BUG=b:119846880
BRANCH=scarlet
TEST=emerge-scarlet chromeos-ec
Change-Id: Ieb123bb27f088b3ec6b138b56db39a0d46016718
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1346989
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The host command is enabled by defining CONFIG_HOSTCMD_AP_RESET.
It calls the chipset_reset() function, similar to the console
command "apreset".
BRANCH=none
BUG=b:119261783
TEST=Manually tested as follow:
Enabled CONFIG_HOSTCMD_AP_RESET on Cheza and flashed EC image.
Copied the compiled ectool to Cheza. Ran "ectool apreset".
Checked EC console:
[6698.093141 chipset_reset(4)]
[6698.093753 power off 5]
...
the power state changing S0 -> S5 -> S0
Change-Id: I09f26f0c7ccd22905979e8b8675185505ad739eb
Signed-off-by: Wai-Hong Tam <waihong@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1327841
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is a backup solution if JTAG_SRST gets fused out.
The WARM_RESET_L signal is wired to JTAG_SRST, such that we can
hold AP when servo/H1 programs the AP SPI flash. But when JTAG_SRST
gets fused out (just in case it happens), still have a way to hold
AP, i.e. overdriving the AP_RST_L and PS_HOLD signals.
The WARM_RESET_L signal is pulled by a rail from PMIC, the same as
POWER_GOOD. The drop of WARM_RESET_L may be caused by either servo/
cr50 holds the signal or its pull-up rail drops. We should handle
both cases.
Also add WARM_RESET_L as one of the power signals for debug purpose.
BRANCH=none
BUG=b:78194018, b:112723105, b:112564635
TEST=Ran "dut-control warm_reset:on" and "dut-control warm_reset:off".
Scoped the signal of AP_RST_L and PS_HOLD to verify the correctness.
Verified AP hold and back booting up.
TEST=Changed to the gpio.inc to swap LID_OPEN and WARM_RESET_L and
ran "dut-control lid_open:no" and "dut-control lid_open:yes" to emualte
the case JTAG_SRST gets fused out. Scoped the signal correctness.
Verified AP hold and back booting up. Ran flashrom to program AP SPI
flash through servo.
Change-Id: I71ebd920171da9994192f7742675feb7cb39ce2f
Signed-off-by: Wai-Hong Tam <waihong@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1234743
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AP watchdog line can fall in either of 2 cases:
- AP asserts watchdog while the AP is on: this is a real
AP-initiated reset.
- EC asserted GPIO_AP_SYS_RST_L, so the AP is in reset and AP
watchdog falls as well. This is _not_ a watchdog reset. We
mask these cases by disabling the interrupt just before
shutting down the AP, and re-enabling it before starting the
AP.
Also, take the opportunity to move warm reset code out of board
file into generic MT8183 power code, as well as code to enable
interrupts.
BRANCH=none
BUG=b:109900671
TEST=apshutdown => EC understand this is an EC-initiated shutdown
TEST=Use test-wd from bug, see that EC detects it is a watchdog.
Change-Id: I02037e5be0254fef991ae2459be35e4561e0994c
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1293132
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need a method that we can call from the chipset notify hooks that can
clearly distinguish which state you are about to be in. This is made
evident by the child CL for putting a MUX into low power mode in S5.
Without this method, we have to put chipset state into the PD task
variable and use that instead (since chipset_in_state won't work because
we are in the S3S5 state)
BRANCH=none
BUG=b:112136208,b:111196155,chromium:736508
TEST=On Phaser the 3300_pd_a drops from 92mW to 32 mW when the charger
is plugged into C1 and the SoC is in S5. The rail also says at 32mW
after
removing and plugging the power back in while the SoC is in S5. Also
ensured that power is low upon first insertion and AP does not come on
automatically.
Change-Id: I93cce2aa319c9689efce222919e5389471001a00
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1211368
Reviewed-by: Justin TerAvest <teravest@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 548e4d9708cc4402497ed290daf4df672114302c.
The following CL uses the POWER_GOOD signal as an indicator, instead of
the AP_RST_L which has a short low pulse during warm reset. So revert
the confirmation logic for the AP_RST_L.
BRANCH=none
BUG=b:78455067
TEST=Check the following CL.
Change-Id: Iec0a7592f8dd1686b1bce8304b42ad0407b6dfde
Signed-off-by: Wai-Hong Tam <waihong@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1169952
Reviewed-by: Stephen Boyd <swboyd@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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
BRANCH=none
BUG=none
TEST=make BOARD=cheza tests -j
Change-Id: Ifec4653bf71b870b616669f0a32ba528c1e38787
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1072217
Reviewed-by: Wai-Hong Tam <waihong@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Keep the timestamp of the latest power lost. Add a handler to wake
the chipset task to check if power lost stays low for a while (the
time between now and the latest power lost is longer than a period).
BRANCH=none
BUG=b:78455067
TEST=Toggle EC GPIO SYS_RST_L for a low pulse to execute PMIC reset
sequence and verified AP reset but not a transition S0 -> S5.
TEST=Toggle EC GPIO PMIC_KPD_PWR_ODL and SYS_RST_L for a low pulse
(see power_off function) to execute PMIC shutdown sequence and verified
a power-lost transition S0 -> S5.
Change-Id: I8ed789d701e834195865bfdf2d302388d42618d2
Signed-off-by: Tom Wai-Hong Tam <waihong@google.com>
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1028831
Commit-Ready: Wai-Hong Tam <waihong@google.com>
Tested-by: Wai-Hong Tam <waihong@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the EC listen to the AP_RST_REQ GPIO from AP. The rising
edge interrupts to trigger a hook to call chipset_reset().
As the hook task will be preempted by the chipset task, it adds a
flag bypass_power_lost_trigger to avoid triggering to S5 as the
chipset state machines sees power lost during the reset.
So far the chipset_reset() implementation is to do a cold reset;
will be revised to a warm reset after the PMIC registers are
reprogrammed.
BRANCH=none
BUG=b:74395451
TEST=make buildall -j
TEST=Ran 'reboot' on AP console which toggles the GPIO.
Change-Id: I946cb029541ce018a8ed1ce25681d38998a7f4b6
Signed-off-by: Wai-Hong Tam <waihong@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1023986
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds a callback for chipset_pre_init_callback which is
made by x86 common power state machine when in G3S5 state. Until now,
there was a hook CHIPSET_PRE_INIT_CALLBACK that was notified by
chipset task when in G3S5 state. However, there are at least following
reasons why this should be a callback and not a hook notification:
1. The initialization that is done as part of pre-init could be
essential for the power state machine to make progress. Though the
chipset task goes to sleep waiting for power signals after the hook
notification, pre-initialization can all be done as part of a callback
since it is mostly board-specific code that is doing work to
initialize PMIC.
2. Typically, boards use I2C transactions to setup PMIC on getting
chipset pre-init notification. However, since i2c transfers are not
encouraged in hook task, they have to be deferred anyways.
3. Since the initialization is being done as part of hook task, use of
any constructs e.g. pwr_5v_en_req which allows multiple consumers to
enable/disable power rails will use task id for hook task. Instead it
is better to provide correct information about the task by letting
chipset task perform this request.
Thus, this change adds a callback chipset_pre_init_callback in G3S5
state for x86 power state machine. This callback is guarded by
CONFIG_CHIPSET_HAS_PRE_INIT_CALLBACK.
The hook notification is left as is for now until all x86 boards are
moved over to using the newly added callback.
BUG=b:78259506
BRANCH=None
TEST=None
Change-Id: I2e1d73e5308759fef41680ae715ef71268b61780
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1018733
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Majority of the chipsets do not have a dedicated GPIO to trigger
AP cold reset. Current code either ignores cold reset or does a warm
reset instead or have a work around to put AP in S5 and then bring
back to S0. In order to avoid the confusion, removed the cold reset
logic and only apreset is used hence forth.
BUG=b:72426192
BRANCH=none
TEST=make buildall -j
Manually tested on GLKRVP, apreset EC command can reset AP.
Change-Id: Ie32d34f2f327ff1b61b32a4d874250dce024cf35
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/991052
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When AP requests cold reboot, currently EC does not perform PMIC
reset because chipset_handle_reboot is executed only after EC jumps
to RW. This causes EC to miss CHIPSET_STARTUP and CHIPSET_RESUME
events because power rails do not cycle.
This patch will make EC execute PMIC reset to before vboot_main.
BUG=b:73093795
BRANCH=none
TEST=reboot, reboot ap-off, verify USB ports are powered after
transitionining to dev mode.
Change-Id: Ic04395d8a4bff45d9fc60601b07c600dfb75d9c0
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/908094
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modify chipset_in_state to always say that the chipset is off,
when we do not actually have a chipset (like on hammer): that
makes sure the battery can actually be cut off (else the EC
would just wait forever for the chipset to turn off).
Also, wake the charger state on "AC" change, that is, when
charging_allowed changes state, to make sure the charging loop
is executed after lux tries to charge it (else the charging loop
would wait until timeout expires, and wand would ask the battery
to be cut off again).
BRANCH=none
BUG=b:65697962
TEST=Deplete wand battery, reboot without providing external power
to it.
After 30 seconds, battery is cut off:
[1.354683 Low battery: 2%, 6866mV]
[1.354888 charge warn shutdown due to critical battery]
[31.381410 Low battery: 2%, 6865mV]
[31.381643 charge force battery cut-off due to critical level]
TEST=Upon providing power to wand, charging loop is executed
regularly, and battery is charging.
Change-Id: I7154b25bd852b8422a0ae3b506675a297a948132
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/842742
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two different types of suspend states that are supported on
x86 platforms -- S3 and S0ix. When AP enters S3, the chipset state is
identified as CHIPSET_STATE_SUSPEND. On the other hand, when AP enters
S0ix, the chipset state is identified as CHIPSET_STATE_STANDBY. There
are several components within the EC e.g. charger state machine, usb
pd task, motion sense task that take actions based on the chipset
suspend state (and checked only for CHIPSET_STATE_SUSPEND until
now). In order to ensure that different EC components do not have to
worry about checking for all the different types of suspend states
that are supported, introduce a new combination
CHIPSET_STATE_ANY_SUSPEND which is a combination of
CHIPSET_STATE_SUSPEND(S3) and CHIPSET_STATE_STANDBY(S0ix).
BUG=b:69690699
BRANCH=None
TEST=make -j buildall. Ruben verified that with this change, EC power
consumption in S0ix drops from 7.85mW to 6.59mW on Soraka.
Change-Id: I599a0ea2fe2f39132764a6068fa77c3aea02affa
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/786919
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In case there is a sudden power loss to PCH, then there are no eSPI VW
messages sent from the PCH to EC indicating power state transition into
S5. Instead, the eSPI compatibility spec defines such events as global
reset events. For global reset events, eSPI_Reset# signal is asserted
without SLP_SUS# being asserted. This acts as an indication to the EC
that there was a global reset event.
Add a callback chipset_handle_espi_reset_assert that takes any necessary
action whenever eSPI_Reset# pin is asserted. On skylake, it would check
if power button was being pressed and release the button.
BUG=chrome-os-partner:62014
BRANCH=None
TEST=Verified that apshutdown works as expected.
Change-Id: I409afa0d00faca55ae3aa577743cedac58d4d877
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/438935
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
add optional chipset specific function to check if PLTRST# is valid
BUG=chrome-os-partner:52656
BRANCH=none
TEST=make buildall, able to boot to OS on amenia
Change-Id: I7a2747c4f77f50393c3250c2ab0e1625e64e5a41
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/341732
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On assertion of SLP_S0, EC goes to S0ix while system is in Lucid sleep
and EC is eligable to enter heavy sleep idle task.
Wakeup from S0ix by lid open, any key press, power button or track pad
will be done by PCH block by asserting SLP_S0.
At S0ix, 1 msec pulse will be generated every 8sec and this signal
should be ignored since this is NOT S0ix entry/exit related and defered
interrupt for SLP_S0 were added.
BRANCH=master
BUG=none
TEST=in OS shell, run following commands.
Following command is valid with coreboot with S0ix patches.
"echo freeze > /sys/power/state"
then,
Measure EC power consumption and compare it with one in S0.
And on EC console, there should be NO periodic message, "power
state 4 = S0ix, in 0x001d" every 8 sec.
Change-Id: Ia9cf5256b1ad7234815d4b6dbe2b45788aaf49dd
Signed-off-by: Kyoung Kim <kyoung.il.kim@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/307947
Commit-Ready: Kyoung Il Kim <kyoung.il.kim@intel.com>
Tested-by: Kyoung Il Kim <kyoung.il.kim@intel.com>
Reviewed-by: Kyoung Il Kim <kyoung.il.kim@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the gpio_info struct, we had a irq_handler pointer defined even
though a majority of the GPIOs did not have irq handlers associated. By
removing the irq_handler pointer out of the struct, we can save some
space with some targets saving more than others. (For example, ~260
bytes for samus_pd).
This change also brings about a new define:
GPIO_INT(name, port, pin, flags, signal)
And the existing GPIO macro has had the signal parameter removed since
they were just NULL.
GPIO(name, port, pin, flags)
In each of the gpio.inc files, all the GPIOs with irq handlers must be
defined at the top of the file. This is because their enum values from
gpio_signal are used as the index to the gpio_irq_handlers table.
BUG=chromium:471331
BRANCH=none
TEST=Flashed ec to samus and samus_pd, verified lightbar tap, lid, power
button, keyboard, charging, all still working.
TEST=Moved a GPIO_INT declaration after a GPIO declaration and watched the build
fail.
TEST=make -j BOARD=peppy tests
TEST=make -j BOARD=auron tests
TEST=make -j BOARD=link tests
Change-Id: Id6e261b0a3cd63223ca92f2e96a80c95e85cdefb
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/263973
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Trybot-Ready: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename x86_* to power_signal_* and X86_* to POWER_*.
BUG=chrome-os-partner:24832
BRANCH=link,falco,samus,rambi,peppy,squawks,snow,spring,nyan
TEST=make -j buildall run_tests
Change-Id: Ifaa06391da5a483851ff56eca91fbf6d038dff0a
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181719
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Every chipset had its own header file just to declare a GPIO interrupt
handler. Since this seems to be a common feature of the power
interface, make a standard power_interrupt() API provided by
chipset.h. This lets us get rid of 4 include files, and makes it
easier to add more chipsets in the future.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I1fc5612d42625ea46e0a8e16a83085b66d476664
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173745
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For bringup, we need to be able to compile a binary with the chipset
task disabled. Chipset functions should be stubbed to do nothing in
that case.
BUG=chrome-os-partner:22820
BRANCH=none
TEST=compile falco, pit, link with chipset task commented out in ec.tasklist
Change-Id: I73a4e09effb049f19b1a128e643b267d6469037b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170221
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CONFIG_ macros should be set directly. Expanding the task names in the same
way made it difficult to tell what was a configuration choice and what was
due to changes in ec.tasklist
BUG=chrome-os-partner:18343
TEST=build all, run link
BRANCH=none
Change-Id: Ib82e34f974238ee2dd216f33b701b6f4c6a4f1f1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49098
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a function which handles translation of PWROK from logical level
to physical level.
Also implement chipset_force_shutdown() in gaia_power.c, so PMU code
doesn't need to know about PWROK physical level.
BUG=chrome-os-partner:18738
BRANCH=none
TEST=build all platforms; boot spring
Change-Id: I360266ef89b6ead49a633cd57b7530f791b04c9e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48251
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now pingpong and mutex tests compile. Still need some more work to
handle the i8042-specific KEYPROTO task for keyboard tests.
BUG=chrome-os-partner:18598
TEST=Build tests for link
BRANCH=None
Change-Id: I9ee35d4edb811f17b9a81beb799484a07c0bef14
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47981
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's no chipset for mccroskey, so its keyboard code stopped compiling.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build mccroskey, spring, link
Change-Id: If94dfaf2819f047a6aa825ee10aa1d320c8ca882
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47566
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This saves ~70mw of power.
To make this work, I also had to stretch the power button signal to
give the system a chance to come back up when the user taps the power
button.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9574
TEST=manual
For each of the following tests, wait ~15 sec after the system is
powered off to give it a chance to drop DPWROK.
1) tap power button -> system turns on
2) hold power button 1 sec -> system turns on
3) open lid -> system turns on
4) silego reset (power+refresh, or power+esc on proto1) -> system stays off
5) silego recovery (power+esc+refresh) -> system turns on
6) hold down power button and type 'reboot' on EC console -> system turns on
7) type 'powerbtn' on EC console -> system turns on
Change-Id: I781cf3e665104192521b7fb9ff75a3c3e7f43464
|
|
...since x86_power_in_S0() is a terrible function to have implemented
for gaia chipsets, and I need to add more detectable states for lid
switch handling anyway.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=none
TEST=none
Change-Id: I0c90c6875b27d1bf23f093e88e34eabf2a8c86e4
|