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>
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
