Allow the host to self-report its sleep state through
EC_CMD_HOST_SLEEP_EVENT, which will typically be sent with SUSPEND
param when the host begins its sleep process. While the host has
self-reported that it is in SUSPEND, don't assert the interrupt
line, except for designated wake events.
BUG=chrome-os-partner:56156
BRANCH=None
TEST=On kevin, run 'ectool hostsleepstate suspend', verify that
interrupt assertion is skipped for battery host event. Run 'ectool
hostsleepstate resume' and verify interrupt is again asserted by the
battery host event.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I74288465587ccf7185cec717f7c1810602361b8c
Reviewed-on: https://chromium-review.googlesource.com/368391
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Cr50 has sys_rst_l as a wake source, but it can't tell which pin woke it
on resume. To know the source it has to check the value of the pin on
resume. This change makes the delay long enough for Cr50 to resume and
check that sys_rst_is asserted.
BUG=chrome-os-partner:55674
BUG=b:30308276
BRANCH=none
TEST=enable sleep on cr50 and verify apreset still reset it
Change-Id: I8e088c5f13a4222142161d8b79550dfc6eb529d6
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364170
Reviewed-by: Shawn N <shawnn@chromium.org>
On a power press that will bring the system to S0, start our 8 sec
timeout in case the power button is never released.
BUG=chrome-os-partner:55666
BRANCH=None
TEST=Press and hold power button on kevin to bring device to S0, verify
device boots in normal mode and powers down ~8 seconds after initial
press.
Change-Id: I1cbb52974bcc09d23a130df13815cee07968467a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363592
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Before, as soon as the EC started booting, it would unconditionally boot
the AP (unless explicitly told not to. ie: "reboot ap-off"). However,
we weren't waiting for our power to settle which was causing some
brownouts. This would happen when trying to boot without the battery.
This commit causes the EC to inhibit powering on the AP until we have
sufficient power.
BUG=chrome-os-partner:55289
BRANCH=None
TEST=Flash EVT2; verify can boot normally.
TEST=Remove battery and insert charger. Verify that DUT can boot up.
TEST=Insert drained battery. Verify power on is inhbited. Plug in
charger and verify that DUT can power on.
Change-Id: Ifb40766fcc1d330674ec39de6d81174f92b6d658
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/361005
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The firmware needs to talk to the EC while the power button is pressed.
If the EC did not even leave the S5->S3 state this is not possible.
Seems like the piece of code is not even necessary, check_for_power_off_event
will catch the long press asynchronously later on anyway.
BRANCH=none
BUG=chrome-os-partner:54781
TEST=power up by power button and hold it, there should be
no error logs during EC sync, and screen turns on for a short time
then off
Change-Id: Ic0cccb6cfc5ddd389c1111a77ec06530a9e429ef
Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/359152
Reviewed-by: Rong Chang <rongchang@chromium.org>
- Power up the AP automatically on initial EC power-on.
- In S0, wait for 8s power button hold before powering down.
- In S3 and lower, power down immediately on power press.
- In G3 / S5, power up on lid open.
BUG=chrome-os-partner:54582,chrome-os-partner:54511
BRANCH=None
TEST=Manual on gru. Verify the following:
- AP powers up when battery initially attached.
- `reboot` powers up AP after EC reset.
- `reboot ap-off` doesn't power up AP.
- `apshutdown` + `lidclose` + `lidopen` causes AP power-up.
- Holding power for 4s in S0 does not change power state.
- Holding power for 8s in S0 causes AP power down.
Change-Id: I588056549a972212c28b9aa6a83fe2e0b179baa9
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/355650
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
PP1800_PMU impacts the initial centerlogic voltage due to DVS circuitry.
Since there's no other sequencing dependency, turn it on earlier.
This fixes centerlogic from initially starting too high (1.5V).
BUG=none
BRANCH=none
TEST=Watch PPVAR_CENTERLOGIC and confirm that it starts at the target voltage
Change-Id: Icac076a7e8aef978401452a98d9f6bc8b373d94f
Signed-off-by: David Schneider <dnschneid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/352247
Reviewed-by: Shawn N <shawnn@chromium.org>
Leave USB-A charging enabled in S3, and move gru-specific code into
board hooks, out of the power state driver.
BUG=chrome-os-partner:54159
BRANCH=None
TEST=Manual on gru. Verify USB-A enable GPIOs are asserted in S0 and
deasserted in G3.
Change-Id: Icadeb771226dd0fda4ae96fdde9b3984d87fdd15
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/351670
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Power-down sequence in reverse order of power-up, with delays extended
to 10ms, to allow rails extra time to decay.
BUG=chrome-os-partner:54159
BRANCH=None
TEST=Manual on gru. Verify repeated `powerbtn` commands on console
boot + power-down the SOC.
Change-Id: I2e8fb39f8f900e56deef6b386bae1c336aa1f963
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/351520
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Move power rail and pmic enable control to be handled at
board level due to specific board design.
Modify rsmrst where assertion is pass-through at all time
and de-assertion is only pass-through at power up.
BUG=chrome-os-partner:53666
BRANCH=none
TEST=amenia is able to handle apreset warm/cold, pmic shutdown,
soc reset/shutdown.
Change-Id: I7ff819d88d0e194073bee8f02b1e3fa70ca44ba7
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/347370
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Divya Jyothi <divya.jyothi@intel.com>
This adds the basic framework for Reef including full GPIO listing,
board config file, and rudimentary functionality. It has not been
fully tested and still has several TODOs/FIXMEs. For now we just need
something that will build and can be incrementally improved.
BUG=chrome-os-partner:53035
BRANCH=none
TEST=EC and AP both boot, seems reasonably stable for now
Change-Id: I4934ad00917e251dd1d7eb759207a92c45a36136
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/339292
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use input signals to verify power state and determine power state after
sysjump.
BUG=chrome-os-partner:52878
BRANCH=None
TEST=Manual on kevin.
- Verify AP powers up on 'powerbtn'.
- AP shuts down on 'apshutdown'.
- AP re-powers / resets on 'powerbtn' + 'apreset'.
- AP doesn't shutdown on 'sysjump rw' while in S0.
Change-Id: Id24feb0f8490aa7cb73c46178085ff2e46f8d0a6
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/341704
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: David Schneider <dnschneid@chromium.org>
Reviewed-by: Shawn N <shawnn@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>
Previously calls to hook_call_deferred were passed the function to call,
which was then looked up in the .rodata.deferred section with a linear
search. This linear search can be replaced with a subtract by passing
the pointer to the deferred_data object created when DECLARE_DEFERRED
was invoked.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
CQ-DEPEND=CL:*255812
TEST=make buildall -j
Change-Id: I951dd1541302875b102dd086154cf05591694440
Reviewed-on: https://chromium-review.googlesource.com/334315
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
PMIC already has a built-in 100ms delay for V1P05S when ALL_SYS_PWRGD
asserts, hence EC can assert SOC_PWROK immediately. On shutdown RSMRST_N
should assert and SOC_PWR_OK should de-assert immediately when PMIC asserts
PMIC_RSMRST_N and de-assert All_SYS_PWRGD respectively. Hence removed
the unnecessary timing delay for SOC_PWROK and RSMRST_N.
BUG=none
BRANCH=none
TEST=Issued a shutdown command and manually tested on amenia.
RSMRST_N asserts immediately when PMIC asserts PMIC_RSMRST_N
SOC_PWR_OK de-asserts immediately when PMIC de-asserts All_SYS_PWRGD.
Change-Id: I8bb79277a3dcf8545764ba58736f422ac377776e
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/339001
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Implement warm reset and force shutdown routines, which are called from
other modules.
BUG=chrome-os-partner:51926, chrome-os-partner:51923
BRANCH=None
TEST=Verify 'apshutdown' on EC console goes to G3. Verify 'apreset'
causes AP reset while staying in S0.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ifb479287f87f31ac49e007c337cc0c24a79898e6
Reviewed-on: https://chromium-review.googlesource.com/338923
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Elm is an oak variant that uses ANX7688 PD port controller. This CL sets
PD port count to 1 and modifies TCPC I2C address to 0x50.
Other elm changes are included in this change:
- add 2 KX022 motion sensors, remove BMI160
- remove ALS
- LED configuration changed to 2 bi-color LEDs
- remove pi3usb30532
- add ANX7688 mux driver
- change PD interrupt polarity
BRANCH=none
BUG=none
TEST=manual
make BOARD=elm -j
load and test on elm proto
Signed-off-by: Rong Chang <rongchang@chromium.org>
Change-Id: I8ad02da9acade985bc0e7e2f85d9e58db7e6b38d
Reviewed-on: https://chromium-review.googlesource.com/331453
Reviewed-by: Shawn N <shawnn@chromium.org>
Various voltage rails will be enabled / disabled by the PMIC when
GPIO_PMIC_SLP_SUS_L changes. We need to delay the disable of V0.85A
by approximately 25ms in order to allow V1.00A to sufficiently discharge
first.
BUG=chrome-os-partner:52047
TEST=Probe V1.00A and V0.85A during power-down, verify V1.00A discharges
faster than V0.85A.
BRANCH=glados
Change-Id: Ibbf4f989e1814e131dc373d2b5da9b6fa1ac9cce
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/337325
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The debounce timer might be too slow to actually update the state of
debounced_power_pressed by the time we do power_button_is_pressed in
the S3->S5 state transition.
Call power_button_wait_for_release() instead of wait_for_power_button_release()
to make sure there are no deferred actions.
BRANCH=none
BUG=chrome-os-partner:50362, chrome-os-partner:51109
TEST=During dev mode screen, press power button, note the device stays off
TEST=sudo test_that -b oak <DUT_IP> firmware_FwScreenPressPower
Change-Id: Ic60c1847ba461ef874dea5bf7d03675622f24beb
Signed-off-by: YH Huang <yh.huang@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/332310
Reviewed-by: Rong Chang <rongchang@chromium.org>
CONFIG_PMIC_FW_LONG_PRESS_TIMER was ported long time ago from
Tegra, but the codes are actually not used and erroneous.
It might wrongly trigger set_pmic_pwron(0), and turn off
PMIC power accidentally. This causes POWER_GOOD lost and
power state will go back to S5 during boot up.
Clean up the codes by referencing check_for_power_off_event()
of Rockchip.
BRANCH=none
BUG=none
TEST=bootup and press power button quickly right after we are in S0.
Bootup should still complete normally.
Change-Id: Ie034efa3575dbebae4debb1afc206fddd9116350
Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/332724
Reviewed-by: Rong Chang <rongchang@chromium.org>
After power good is lost, PMIC requires some time to turn off
all its internal power before we can turn off VBAT by
set_system_power(0). This ensures the power measurement is within
PMIC spec when system is shut down.
BRANCH=none
BUG=none
TEST=measure the power rails of PMIC after system is shut down
Change-Id: I55d4d99ed0ef69b103a4e52e9f9eec1c9e6265b5
Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/332409
Reviewed-by: Rong Chang <rongchang@chromium.org>
this is to move the existing code from chipset level to board level
since PseudoG3 is a board feature that required specific hardware.
BUG=none
BRANCH=glados
TEST=use hibernate command to enter PseudoG3
Change-Id: I309ef89e0ff7057ce46c634baa9791731a771984
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/327677
Reviewed-by: Shawn N <shawnn@chromium.org>
In http://crosreview.com/28402 code was added to power/gaia.c that
disabled keyboard scanning if the power button was pressed. The
purpose, according to that change, was to prevent accidental reboots by
pressing the power button together with another key that wasn't the
"Refresh" key (specifically: LCtrl, Tab, Reload, t, [, ], y, Dim Screen
and Mute).
At the time the original code was added, there was already code in the
power button interrupt handler to accomplish the same purpose: see
commit 29d25d807c ("Keyboard scan must stop driving columns when power
button is pressed."). It's unclear if the code in the interrupt handler
didn't work or if there was some other bug with it. ...or if perhaps
the changes in "gaia/power.c" weren't actually needed and the important
part of the original change was the mutex added to the scanning task.
In any case, current testing indicates that the code in power/gaia.c,
power/rockchip.c, and power/tegra.c isn't needed anymore. I ran through
the test sequence described in the original CL on my veyron_jerry and I
don't see any accidental reboots.
It's also instructive to note that only ARM boards (all presumably
copied from gaia) have this extra code. Presumably if the code was
actually needed then x86 boards would also need it.
In any case, let's remove it. It's suspected that there's some crazy
race where the disable in power/rockchip.c is overriding the enable in
the main power key handling code and leaving the keyboard disabled.
BRANCH=None
BUG=chrome-os-partner:48470
TEST=Same test as CL:28402
Change-Id: I6d21167ce3d773c9616abd4a728247a1934b96d6
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327843
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit dfae7e7ad45f4ce0e8f820caaa05a8754bba0250)
Reviewed-on: https://chromium-review.googlesource.com/328013
In the S0 <-> S3 transition, Coreboot sends EC messages to set/clear the
wake masks when the SMI is invoked. For S0ix, EC sets and clears the
wake mask via this patch.
These functions are directly invoked from the state machine transition states.
During S0ix entry, the wake mask for lid open is enabled. During S0ix exit,
the wake mask for lid open is cleared. All pending events are also cleared
BRANCH=none
BUG=chrome-os-partner:48834
TEST=test lidopen in S0ix
Signed-off-by: Archana Patni <archana.patni@intel.com>
Signed-off-by: Subramony Sesha <subramony.sesha@intel.com>
Change-Id: I52a15f502ef637f7b7e4b559820deecb831d818f
Reviewed-on: https://chromium-review.googlesource.com/320190
Commit-Ready: Divya Jyothi <divya.jyothi@intel.com>
Tested-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
If we are doing a cold reset or if Deep S5 is disabled we will go into S5
and need to be able to power up again, but we do not have enough information
to know what direction the sequencing may go from S5 (to G3 or up to S0).
So limit the RTCRST check to just the explicit G3->S5 path and let the normal
checking of SLP_S4 signal happen otherwise.
BUG=chrome-os-partner:49564
BRANCH=glados
TEST=pass FAFT testing finally
Change-Id: I202234e58281e6b007ad2b98396994222d0831b2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/323087
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The power state machine goes through POWER_S5 state both when
sequencing up and down, but we only should check for it to
time out on the way up. In order to know what direction it
is going add a variable to indicate the direction.
On samus where this was done before it did not go through
POWER_S5 on the way down, instead going directly to POWER_S5G3
so I did not run into this same issue.
BUG=chrome-os-partner:49564
BRANCH=glados
TEST=successfully power down without the EC thinking it is
timing out and trying to reset RTC.
Change-Id: I1f53f3a252bdc2ec8c656e30b3de7f98aaa661a0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/322898
Reviewed-by: Shawn N <shawnn@chromium.org>
In order to pulse RTC reset to the PCH when power sequencing exit fails we
need to watch for SLP_S4 to deassert and if it does not then assert RTCRST
using a board specific method. This is attempted up to 5 times before giving
up and staying in G3.
On skylake the RSMRST passthru needs to be honored when the task is woken up,
so while waiting call handle_rsmrst() if woken up early. This is needed
because it is RSMRST that actually tells the PCH to try and wake.
This is all wrapped in a config option and board specific method because not all
boards have a GPIO to control RTCRST and if they do they may not all use the
same method to assert it.
BUG=chrome-os-partner:49564
BRANCH=glados
TEST=manually tested on chell EVT:
First, ensure board sequences properly if everything is OK for a normal boot.
Next, modify handle_rsmrst() to not pass through the signal in order to
simulate being stuck in S5, and ensure that the EC attempts to assert RTCRST
and power up again 5 times before giving up and staying in G3.
Change-Id: Ia3c13069c92762b51beb682a19e5a074194a3c26
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/322724
Reviewed-by: Shawn N <shawnn@chromium.org>
x86 systems will auto-power-on when power is applied to the EC. When
the battery level is critically low, power-on is prevented, except when
the system is unlocked. So, when unlocked, some systems will
auto-power-on regardless of battery level, overcurrent the charger /
battery, and then repeat forever.
Prevent this reboot loop by ignoring auto-power-up when the battery is
critically low, regardless of system unlocked status.
BUG=chrome-os-partner:48339
TEST=Verify power-up is prevented on no-battery chell w/ donette. Then,
run 'powerbtn' on EC console and verify system powers on (and
overcurrents).
BRANCH=None
Change-Id: Ia631b5a8c45b42ec805e4a0c3f827929a0efd236
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/319187
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
During power up, system will wait at most CHARGER_INITIALIZED_TRIES
delay to check if battery percentage or negociated charger power can
meet minimum requirement. In some cases, it takes longer time(observed
negotiated to min power took 2 seconds). So increase
CHARGER_INITIALIZED_TRIES from 10 to 40 to give total 4 seconds delay.
BUG=chrome-os-partner:48339
BRANCH=none
TEST=Verified in Kunimitsu system, negotiation to 5V@3A is done within
retry/delay.
Change-Id: I18c5fc676076f8d37d0a5360543f54aa85f48f77
Signed-off-by: li feng <li1.feng@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/318652
Commit-Ready: Li1 Feng <li1.feng@intel.com>
Tested-by: Li1 Feng <li1.feng@intel.com>
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>
1. refer to commit 8bd44bf4, oak has similar issue:
if power good is lost and the power button still press, we need
cancel the long press timer, otherwise EC will crash.
2. Furthermore, EC will crash too if long press timer is still active
during entering S3.
3. The debounce of suspend & power_good signal can be removed on rev4
because rev4 doesn't adopt level shifter.
BRANCH=None
BUG=chrome-os-partner:46857
TEST=Manual
1. press power button during coreboot, and it can shutdown normally, or
2. run test case:
> test_that -b oak <DUT IP> firmware_FwScreenPressPower
Change-Id: I584d8beeb31b6c01289bfe4790453a4a3bd35b1c
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/309942
Reviewed-by: Rong Chang <rongchang@chromium.org>
Warm reset key from servo board lets the POWER_GOOD signal
deasserted temporarily (about 1~2 seconds) since Oak rev4.
In order to detect this case, check the AP_RESET_L status,
ignore the transient state if reset key is pressing.
BUG=chrome-os-partner:46655
BRANCH=none
TEST=make buildall -j;
Press warm reset key of servo board, AP should reset normally.
Change-Id: Ib9f111d2273cde61354e72367fe74d4ee15d2291
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/307201
Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-by: Rong Chang <rongchang@chromium.org>
There is a race condition between SYSJUMP and function
release_pmic_pwron_deferred().
Process of EC SW Sync will delay the execution time of
release_pmic_pwron_deferred(). PMIC will shutdown the power, if
PMIC power button can not be released within 8 seconds (depends
on PMIC spec). In order to ensure PMIC power button will be
released in time, just release it after SYSJUMP.
BUG=chrome-os-partner:46392
BUG=chrome-os-partner:46656
BRANCH=none
TEST=make buildall -j;
Enable EC SW sync and normal mode in coreboot,
Kernel should bootup successfully.
Change-Id: I45d4aa0f0d4280e68282ea11ccfda05201f88aae
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/307220
Reviewed-by: Rong Chang <rongchang@chromium.org>
Some boards may not have a USB2_ENABLE GPIO so we need each
board to do the USB power enable/disable in a board hook.
BUG=chrome-os-partner:46289
BRANCH=none
TEST=make -j buildall
Change-Id: I830cbaf41c118b2f74e23fa946a4187f6293a7d5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304397
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Currently, the only way to prevent a system from hibernating is via the
EC console command "hibdelay". This commit adds the host command
equivalent so that it can be set elsewhere. The host command takes the
amount of time in seconds to delay hibernation by and responds with the
current time in the G3 power state, the time remaining before
hibernation should be invoked, and the current setting of the
hibernation delay.
BUG=chrome-os-partner:45608
BUG=chrome-os-partner:44831
BRANCH=None
TEST=Build and flash on samus. Issue the host command from EC
console. Verify that the hibernation delay was updated by checking with
the hibdelay command.
Change-Id: I34725516507995c3c0337d5d64736d21a472866c
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/302197
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Modify the GPIO seeting according to the Oak rev4 schematic.
BRANCH=none
BUG=none
TEST=manual
Confirm all reversion of oak can be built pass:
make -j EXTRA_CFLAGS=-DBOARD_REV=4 BOARD=oak
make -j BOARD=oak clean
make -j EXTRA_CFLAGS=-DBOARD_REV=3 BOARD=oak
make -j BOARD=oak clean
make -j EXTRA_CFLAGS=-DBOARD_REV=2 BOARD=oak
make -j BOARD=oak clean
make -j EXTRA_CFLAGS=-DBOARD_REV=1 BOARD=oak
Change-Id: Ib1051f29df9d1919f0ae3ecaf55dc0997ea29c3e
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/300728
Reviewed-by: Rong Chang <rongchang@chromium.org>
since we add debounce time (50 ms) for SUSPEND & POWER GOOD signal
after oak rev3 (commit e58a913b). It will causes the chipset_reset
function failure, because PMIC_COLD_RESET_L_HOLD_TIME is short.
PMIC_COLD_RESET_L_HOLD_TIME should be greater than 100 ms
[SUSPEND_DEBOUNCE_TIME (50 ms) + POWER_DEBOUNCE_TIME (50 ms)].
So, revise PMIC_COLD_RESET_L_HOLD_TIME to 120ms.
And, using hook to avoid blocking the EC console when executing
"apreset" EC console command.
BRANCH=none
BUG=chrome-os-partner:44955
TEST=manual
Run EC console command, after AP enter S0:
> apreset
AP should be reset normally.
Change-Id: I04e31aef8be3092ad39b5f1b1c2b75b78b4d1d7b
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/299625
Reviewed-by: Rong Chang <rongchang@chromium.org>
Since the firmware_ECPowerButton testcase holds down power button
about 10s to shut down without powerd, we set DELAY_FORCE_SHUTDOWN
about 8s to make sure the powerbutton is pressed long enough to
force shutdown.
BRANCH=none
BUG=chrome-os-partner:43412
TEST=manual
run "firmware_ECPowerButton" testcase on rev3.
Change-Id: Ib41cdecfa0342236d618e6fdffcb64bf7f51b557
Signed-off-by: YH Huang <yh.huang@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/296884
Reviewed-by: Rong Chang <rongchang@chromium.org>
Enable the support for limiting the inrush current by routing the PCH_SLP_SUS
through EC gpio PMIC_SLP_SUS which allows the DUT to boot on charger without
the battery / dead battery. This is applicable to Kunimitsu FAB4 only.
Enabling the Glados patch for Kunimitsu FAB4.
Change-Id: I55de857f7006777640f7853b7bde98ba97e8bd13
Reviewed-on: https://chromium-review.googlesource.com/287378
BUG=chrome-os-partner:44706
TEST=FAB4 prototype boots to UI without battery / dead battery.
BRANCH=none
Change-Id: Ie81cdf3c59fc02d6d59dd06ca321705ca06e7b88
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/296521
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
