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>
(refer to CL:273620) enable the MKBP event feature to send host event
and wire up the PD specific events.
But, CONFIG_MKBP_EVENT conflicts with CONFIG_KEYBOARD_PROTOCOL_MKBP,
due to the GPIO name of EC interrupt pin. Align the GPIO naming of EC
interrupt pin to EC_INT_L.
BRANCH=none
BUG=chrome-os-partner:44643
TEST=On Oak rev3, plug/unplug USB devices and add kernel trace to see
the PD events happening.
Change-Id: I10de9c6611583bb6165bdc1848e542d4b8bba954
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/296012
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
If the power button is pressed while S5 inactivity timer is about to
expire, EC need to give CPU a little time to start up before changing
the state from S5 to G3 (the hard off state); otherwise the system will
not start up. This issue can be reproduced on Rambi.
BUG=chrome-os-partner:42728, chrome-os-partner:42811
BRANCH=None
TEST=Implement an ec command to simulate power button press while S5
inactivity timer is about to expire, and then make sure that the
patch did solve the issue.
Change-Id: I022e8e14fd41447898760a4d57a4702e2c00a0d5
Signed-off-by: Kaiyen Chang <kaiyen.chang@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/290280
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/296436
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
On skylake the apshutdown command holds the power button asserted until
the power state machine decides to deassert the power button. Previously
this check was taking place in G3 state. As such when the board waited
in S5 for 10 secs one couldn't re-power on the system. To alleviate that
move the logic for power button deassertion into the S5 state.
BUG=chrome-os-partner:44532
BRANCH=None
TEST=Used apshutdown. When device got to S5 power noted another
powerb command would bring the system back up instead of waiting
to enter G3 power state.
Change-Id: I9989b27bd48819d7c3e5efd071b0327c38fe91e2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295198
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The internal keyboard and trackpad must be disabled in tablet mode to
prevent unwanted input.
BUG=chrome-os-partner:44305,chrome-os-partner:40849
TEST=Manual on Glados. Boot system with lid open, verify that keyboard
is functional and ENABLE_TRACKPAD is high. Swing lid to tablet mode,
verify that keyboard is not functional and ENABLE_TRACKPAD is low.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9f250ae82963c8b497de991b6cce52c86841d08a
Reviewed-on: https://chromium-review.googlesource.com/295206
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
BUG=none
TEST=Used "shutdown -h now" Kernel console command to test on Kunimitsu.
With only battery after 1 hour, device enters to Pseudo G3 and the
V3p3A is off. With AC connected, device is in G3.
BRANCH=none
Change-Id: I955662eb69ac608e9b2d12bdcfbc1258ca83f3a5
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/292976
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There are a number issues with the current skylake power
sequencing. First, SLP_SUS_L was not being honored from
the chipset when a deep S5 or S3 was requested. Additionally
the BATLOW_L signal was being used to block the chipset from
waking which caused a race in waking from deep S5 that required
an additional pulse of the PCH_WAKE_L signal instead of the
chipset seeing the power button event. Another issue is that
POWER_S5 state was being completely bypassed so any global
resets that brought down SLP_S4_L caused the state machine
to enter into G3 state.
The code was changed to remove BATLOW_L usage, PCH_WAKE_L
in the POWER_G3S5 state, and SLP_SUS_L is honored in the
non POWER_S5G3 and POWER_G3 state. That allows SLP_SUS_L
pass-thru to work on glaods. Lastly the code was reorganized
to accomodate the above change without sprinkling them
throughout the state transitions.
BUG=chrome-os-partner:44081
BUG=chrome-os-partner:44082
BUG=chrome-os-partner:43475
BRANCH=None
TEST=Built and booted glados. Deep S3 and S5 wakes work. Fresh
flash plus a global reset doesn't bring the system down to G3.
Change-Id: Id1d7af1b6a733a9db5aad584950da8ab5898ea83
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293844
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The system will not wake from Deep S5 if BATLOW# is asserted,
so wait for that to deassert, then pulse the wake pin and wait
for SLP_SUS_L to deassert.
BUG=chrome-os-partner:43545,chrome-os-partner:44079
BRANCH=none
TEST=verified on P2 board
Change-Id: I3b36159b574d418c9b79c478d0a41f753474fa6a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293595
Reviewed-by: Shawn N <shawnn@chromium.org>
Switch to V2 glados as the default, and remove support for V1.
BUG=chrome-os-partner:43075
TEST=`make buildall -j`
BRANCH=None
Change-Id: I58f33225177d259916e8877084c2c431922e7bc5
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293303
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
In case of 'apshutdown', during transition to S5 state,
GPIO_PCH_SLP_S4_L signal was not getting deasserted but
required rail went away (GPIO_PCH_SYS_PWROK). So it was
going on a loop S5 -> S3 and S3 -> S5.
In strago GPIO_PCH_SYS_PWROK is the PMIC_EN GPIO and hence
conditinally setting it based on CONFIG_PMIC
BUG=none
TEST=apshutdown on strago
BRANCH=none
Change-Id: I9c581a3dfcb9cc84a22b41505e7df496d72d5f4c
Signed-off-by: Kumar, Gomathi <gomathi.kumar@intel.com>
Signed-off-by: Divagar Mohandass <divagar.mohandass@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/292024
Reviewed-by: Shawn N <shawnn@chromium.org>
There are 3 methods to power on the system:
1) Pulling PWRKEY low (User presses PWRKEY)
2) Setting BBWAKEUP high
3) Valid charger plug-in
We should ensure that BBWAKEUP should be high when release PWRKEY.
Due to the RTC driver of coreboot will move to ramstage, and the
setup timing of BBWAKEUP will be postpone. In order to ensure PMIC
keeping the power until coreboot pull BBWAKEUP up, it needs to
increase the PMIC power key press time to avoid PMIC turn the
power off. This change is related to:
https://chromium-review.googlesource.com/#/c/257389/
BRANCH=none
BUG=none
TEST=manual
Update coreboot with above patch, press power key and system
should power on normally.
Change-Id: I7fabc49e0b3956885cb83a0b40c31c60080d0cbc
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/290538
Reviewed-by: Rong Chang <rongchang@chromium.org>
The AP warm reset pin is changed from rev3 of oak board.
PB3 is stuffed before rev3 and connected to PMIC RESET pin to
reset the AP. For rev3, the AP reset mechanism is changed:
PC3 connects to PMIC SYSRSTB, pull PC3 to low, to reset AP.
BRANCH=none
BUG=none
TEST=manual
1. define CONFIG_BOARD_OAK_REV_2 in board.h
make -j BOARD=oak
2. define CONFIG_BOARD_OAK_REV_3 in board.h
make -j BOARD=oak
both cases should be built successfully and run "apreset" command.
AP should be reset normally.
Change-Id: I979e93acf755509f8cb7a12dd77eb7c9e7a98ccc
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/289476
Reviewed-by: Rong Chang <rongchang@chromium.org>
