summaryrefslogtreecommitdiff
path: root/power
Commit message (Collapse)AuthorAgeFilesLines
* power/mt8183: Re-enable watchdog interrupt after sysjumpNicolas Boichat2019-06-251-1/+2
| | | | | | | | | | | | | | | | | Without this, watchdog reset is not detected properly by the EC after software sync. BRANCH=none BUG=b:132938532 TEST=Boot kukui with SW sync enabled stop daisydog echo 1 > /dev/watchdog Board reboots after ~30 seconds (and does not get stuck) Change-Id: Ia33f5f2b2b610d921ef36874226d23ed09b2f793 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1663542 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* power/mt8183: Hold PMIC enable to force S5->G3 transition.Nicolas Boichat2019-06-241-3/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Asserting VSYSSNS should only be done as a last measure. If the PMIC is configured properly, it will shut down upon holding POWER+HOME key for 8+ seconds. This is shorter than the S5->G3 timeout, so we should never need to assert VSYSSNS. BRANCH=none BUG=b:134912821 TEST=reboot ap-off, immediately powerb, see that AP turns on and stays on. TEST=apshutdown, PMIC shuts off gracefully TEST=In power/common.c, change S5_INACTIVITY_TIMEOUT to 3 seconds, see that state machines forces PMIC off using VSYSSNS. TEST=Boot DUT: mosys eventlog clear; poweroff power on DUT, run dut-control power_state:off Wait 8 seconds for EC to go to G3, power on DUT again mosys eventlog list shows events with correct time stamps: 0 | 2019-06-14 15:44:31 | Log area cleared | 79 1 | 2019-06-14 15:44:38 | System boot | 0 2 | 2019-06-14 15:44:38 | Chrome OS Developer Mode 3 | 2019-06-14 15:45:13 | System boot | 0 4 | 2019-06-14 15:45:13 | Chrome OS Developer Mode Change-Id: I9b73d06e07296e47e15fe87dd87fffac2af04d12 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1660073 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* intel_x86: Use common code to get power signal's levelVijay Hiremath2019-06-202-7/+2
| | | | | | | | | | | | | | | Removed redundant code in intel_x86 and reusing the common code for getting power signal's level. BUG=none BRANCH=none TEST=make buildall -j Change-Id: I9cd550a2326456189a087459aeb8e6c88a8cad8e Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1667647 Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* ec: Remove extraneous new line as the end of CPRINTS stringsNicolas Boichat2019-06-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | CPRINTS already prints a new line, no need to add another one. Spotted during boot on kukui, and then realized there are many more instances: "" [3.689239 Module 7 is not supported for clock disable ] "" BRANCH=none BUG=none TEST=make buildall -j TEST=`git grep CPRINTS | grep "\\\\n\""` shows nothing of interest. Change-Id: I4d2bbbc65a91fa56c6e6115aa5c353bfd2b384a1 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1660519 Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* LICENSE: remove unnecessary (c) after CopyrightTom Hughes2019-06-196-6/+6
| | | | | | | | | | | | | | | | Ran the following command: git grep -l 'Copyright (c)' | \ xargs sed -i 's/Copyright (c)/Copyright/g' BRANCH=none BUG=none TEST=make buildall -j Change-Id: I6cc4a0f7e8b30d5b5f97d53c031c299f3e164ca7 Signed-off-by: Tom Hughes <tomhughes@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1663262 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* power/mt8183: Stay in S5 for 10 seconds before forcing PMIC shutdownNicolas Boichat2019-06-171-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On forced/emergency shutdown, the EC is only able to force the PMIC off by asserting GPIO_PMIC_FORCE_RESET_ODL, which also loses the RTC state. And it does so immediately after transitioning to S5. This causes issues with FAFT, as the RTC resets to original time. Instead, wait for 10 seconds in S5 before forcing the transition to G3, which is what other platforms do, and only force the reset at that time. BRANCH=none BUG=b:134912821 TEST=apshutdown => System stays in S5 for 10 seconds before force shutdown. TEST=apshutdown => powerb wakes the system in both S5 and G3 TEST=apshutdown; reboot ap-off in S5 still waits 10 seconds to force shutdown to G3. TEST=poweroff in AP console works, directly goes to G3, and powerb wakes the system TEST=Boot DUT: mosys eventlog clear; poweroff power on DUT, run dut-control power_state:off Within 10 seconds, power on DUT again mosys eventlog list shows events with correct time stamps: 0 | 2019-06-14 15:40:10 | Log area cleared | 55 1 | 2019-06-14 15:40:24 | System boot | 0 2 | 2019-06-14 15:40:24 | Chrome OS Developer Mode 3 | 2019-06-14 15:40:58 | System boot | 0 4 | 2019-06-14 15:40:58 | Chrome OS Developer Mode Change-Id: I7495950da58179fc066608d804e263c81b0993aa Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1660070 Reviewed-by: Yilun Lin <yllin@chromium.org>
* power/mt8183: Clarify comment about force PMIC shutdownNicolas Boichat2019-06-171-2/+3
| | | | | | | | | | | | | | | | | | It turns out MT6358 cannot be configured to shut down when receiving WATCHDOG input, so the statement in the comment is incorrect. However, it is still correct to say that forcing PMIC shutdown should be rare. And add a note that PMIC RTC state will be lost. BRANCH=none BUG=b:109850749, b:134912821 TEST=none Change-Id: I7c84b012d7095fb94473303c83b4ffecb01ee5da Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1657074 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Yilun Lin <yllin@chromium.org>
* intel_x86: Report S0ix hang detected by EC using console printFurquan Shaikh2019-06-141-0/+1
| | | | | | | | | | | | | | | | | | | | | This change prints out a warning indicating that S0ix hang is detected by EC. This is very helpful when debugging S0ix issues to understand when exactly the EC triggered the wake because of hang detect. BUG=b:134781711 BRANCH=None TEST=Verified on a system stuck before going into S0ix that EC prints out the warning when waking host up because of hang detect. Change-Id: I73c64dc675ed8c4d35ca891fdc5de3e7e8449437 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1660014 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Scott Collyer <scollyer@chromium.org> Commit-Queue: Furquan Shaikh <furquan@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Auto-Submit: Furquan Shaikh <furquan@chromium.org>
* intel_x86/power: Consolidate chipset specific power signals arrayVijay Hiremath2019-06-1311-27/+240
| | | | | | | | | | | | | | | Currently chipset specific power signals are defined at board/baseboard level. These power signals are moved to chipset specific file to minimize the redundant power signals array defined for each board/baseboard. BUG=b:134079574 BRANCH=none TEST=make buildall -j Change-Id: I351904f7cd2e0f27844c0711beb118d390219581 Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1636837 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* icelake: Add option to turn-off 5V-rail in power sequencingVijay Hiremath2019-06-111-0/+14
| | | | | | | | | | | | | | | | | | | Need to enable or disable the 5V-rail in power sequencing to support boards with 5V-rail. This CL is a derivative of Cometlake CL. Change-Id: Ia1acd5a592f60973a3b852a987e93283f10d0ac0 Reviewed-on: https://chromium-review.googlesource.com/1503956 BUG=b:134688223 BRANCH=none TEST=Able to control 5V-rail of ICLRVP Change-Id: Iefaa1091e863c1c431ea784d2e02478ce67f8911 Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1647369 Reviewed-by: Jett Rink <jettrink@chromium.org> Reviewed-by: Scott Collyer <scollyer@chromium.org>
* cml: Remove while loop to check for PP5000_A_PG signalScott Collyer2019-05-242-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When cometlake is sequencing from G3->S5, the 5000_A rail is enabled. After enabling the 5000_A rail there was a while() loop to wait for the 5000_A rail to go high. If for some reason this rail did not go high, then it would just loop there until a watchdog reset. This CL removes this while loop check and instead modifies the macro CHIPSET_G3S5_POWERUP_SIGNAL to include the PP5000_A_PG signal. The common intel_x86 power sequencing code already has a check just after the call to chipset_pre_init_callback. BUG=none BRANCH=none TEST=Manual If no battery is present and the bq25710 reset register bit is set, then PPVAR_VSYS gets set to ~4V which is not high enough to generate PP5000_A rail. In this state the EC would consistently watchdog loop when just as AP power sequencing was initiated by the EC. Verified with this CL, that while the PP5000_A rail still doesn't come up, that the EC no longer hits a watchdog and power signal failure is logged in the EC console. Change-Id: I02aab7ed4f4723ec0d3ae04e4b8093494877615f Signed-off-by: Scott Collyer <scollyer@google.com> Reviewed-on: https://chromium-review.googlesource.com/1599674 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Scott Collyer <scollyer@chromium.org> Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* power: Manipulate wake mask during s0ix timeoutsEvan Green2019-05-082-12/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | When S0ix failure detection is enabled and a timeout occurs such that the SLP_S0 line never actually toggles, then s0ix_transition_timeout() sets the HANG_DETECT event bit. This doesn't quite work in this scenario, since the wake mask is only enabled when the power state transitions to S0ix, which happens when the SLP_S0 line toggles. So the AP never sees the event, since it's not in the wake mask and so never causes the EC->AP interrupt line to change. Detect this situation in the timeout function, and explicitly move the wake mask to its S0ix value so that when the event bit is set, (if it is in the wake mask), the system will wake up. Doing this forcefully gets the wake mask out of sync with the power state. So upon resume, explicitly restore the wake mask to its S0 state. BUG=b:131434497 BRANCH=none TEST=suspend_stress_test -c1 --suspend_min=60 with a firmware where S0ix fails. Change-Id: Id2e67c6933a7895fba85ccfdff9b336629eabf24 Signed-off-by: Evan Green <evgreen@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1592469 Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* 7-seg display: Add config to display port80 msg and power statesAyushee2019-05-031-0/+3
| | | | | | | | | | | | | | | | | Adding this CL to display port80 message and power states of EC & SOC on the 7-segment display. BRANCH=None BUG=b:130738086 TEST=Manually tested on intelrvp, able to verify the power states and port80 message displayed on the 7 segment display Change-Id: I4437cfcd60662c8637e406e425f98fad1a4ba7ed Signed-off-by: Ayushee <ayushee.shah@intel.com> Reviewed-on: https://chromium-review.googlesource.com/1575433 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Ayushee Shah <ayushee.shah@intel.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* power: Init host_sleep_event resume_transitionsEvan Green2019-04-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | I had missed a piece of feedback from Karthik about initializing the sleep transitions member of the resume response to avoid returning uninitialized data from the EC. This is especially important if CONFIG_POWER_S0IX_FAILURE_DETECTION is not selected, because then it will *always* return uninitialized data. This drives the kernel nuts, since it has no way to know if that config is on or not. BUG=b:123716513 BRANCH=none TEST=Test suspend with kernel support for this message, and the EC config both on and off. Change-Id: Id35bfe2730327b08f451a4d84277a13e47380a61 Signed-off-by: Evan Green <evgreen@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1551687 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
* power/intel_x86: Introduce s0ix failure detectionEvan Green2019-03-282-12/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change introduces logic in the EC that can detect if the host attempted to go into S0ix, but never made it. The host already sends commands indicating its intent to enter S0ix, and the EC has a SLP_S0 line that gets asserted by the AP when it actually enters S0ix. All that's needed to monitor failures is to arm a timer when receiving the S0ix suspend message. If the SLP_S0 pin goes low, then the suspend occurred and the timer is canceled. If the timer expires before SLP_S0 goes low, then the EC wakes the AP up, since it has entered a shallower idle state than intended, and should be alerted to avoid short battery life. The timer is also started when SLP_S0 is deasserted on resume. The SoC comes out of S0ix to perform housekeeping activities unbeknownst to Linux. In cases where housekeeping fails to suspend all the way back down, this timer will wake the AP. Additionally, the number of S0ix transitions is reported on resume. This enabled the AP to analyze the amount of "sleepwalking" that is done, and can complain if it seems to be waking up too often. Design doc at: https://docs.google.com/document/d/1mY-v02KAuOyET3td9s5GnxeUgMiAcD058oLEo57DZpY/edit BUG=b:123716513 BRANCH=None TEST=Test S0ix on hatch with modified code that forces a timeout, use ectool to send messages manually before and after timeout, Hack Linux to fail suspend very late to verify no regressions. Signed-off-by: Evan Green <evgreen@chromium.org> Change-Id: Ia64b496675a13dbed4ef74637f51e39eee68aa1a Reviewed-on: https://chromium-review.googlesource.com/1501512 Commit-Ready: Evan Green <evgreen@chromium.org> Tested-by: Evan Green <evgreen@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Karthikeyan Ramasubramanian <kramasub@chromium.org>
* power: Allow board to take custom action on G3 timer expirationDaisuke Nojiri2019-03-281-9/+24
| | | | | | | | | | | | | | | | | | | | | This patch introduces board_system_is_idle callback function. It's called when system is in G3. A board can customize its action taken when system is idle in G3 using battery thresholds, expiration timer, etc. determined at runtime. Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=none BRANCH=nami,strago,coral TEST=Verify Vayne cut off battery on G3 idle expiration while other Nami's hibernate. Change-Id: I6118a074ac7d844b99d9c0f3eb638b72d5894008 Reviewed-on: https://chromium-review.googlesource.com/1512623 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* cometlake: Add PP5000_CONTROL config for PP5000_A railScott Collyer2019-03-161-6/+9
| | | | | | | | | | | | | | | | | | | This CL adds the config option CONFIG_POWER_PP5000_CONTROL to the instances where PP5000_A is turned on or off as part of power sequencing. This option is used for cases where the PP5000_A rail may need to stay on for bc1.2 detection even with the AP is in G3. BUG=b:122265772 BRANCH=none TEST=Verified that AP power sequencing still behaves as expected. Change-Id: Ia1acd5a592f60973a3b852a987e93283f10d0ac0 Signed-off-by: Scott Collyer <scollyer@google.com> Reviewed-on: https://chromium-review.googlesource.com/1503956 Commit-Ready: Furquan Shaikh <furquan@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* cometlake: pass RSMRST_L to PCH early to meet tPCH12Rachel Nancollas2019-03-141-0/+3
| | | | | | | | | | | | | | | | | | | tPCH12 dictates that _A rails should go low >= 400ns of RSMRST_L going low. Waiting for this to propagate through the power good chip and EC takes too long. This patch asserts RSMRST_L to the PCH as soon as we the chipset shuts down to meet this timing. BRANCH=none BUG=b:124924912 TEST=Veify on scope that PP3300_A goes low >= 400ns of EC_PCH_RSMRST_L going low during a regular shutdown. Change-Id: I7e6691159f58bc70a0078af53652f8efca3094ff Signed-off-by: Rachel Nancollas <rachelsn@google.com> Reviewed-on: https://chromium-review.googlesource.com/1520768 Reviewed-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* power: Refactor POWER_G3 state logicDaisuke Nojiri2019-03-121-18/+13
| | | | | | | | | | | | | | | | | | | | | | This patch refactors the logic for POWER_G3 state. This patch additionally makes the power task sleep instead of break and return from power_common_state if system_hibernate returns, which shouldn't happen. Other than that, there is no functionality change. Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=none BRANCH=nami,strago,coral TEST=Verify Vayne hibernates when it's left idle in s5 for 60 mins. Change-Id: Ib4a0e9a0e26fdc867395950e3f77bb06e6977f8b Reviewed-on: https://chromium-review.googlesource.com/1512622 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* kukui: Runtime configure GPIO settings between rev1 and rev2.Yilun Lin2019-03-071-18/+0
| | | | | | | | | | | | | | | | | | Considering we have more space on flash now, we would like to share one image between two board revisions to ease the development. This CL also removes unused powerrails in P1. TEST=flash image on P1 and P2, and check both boards boots. BUG=b:126315091 BRANCH=None Change-Id: Ifd0242396013e18e7e1cbc29048a5fc508626e5b Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1505214 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* power/mt8183: Do not react to watchdog interrupt if PMIC is offNicolas Boichat2019-02-271-2/+7
| | | | | | | | | | | | | | | | | | | | | | When the PMIC is shut down, the watchdog line will naturally fall as well. From measurements, this takes about 70ms+, so the EC will have enough time to do the power sequencing and mask watchdog interrupts, unless something exceptional happens. The exceptional case is easy to handle anyway, so let's do that. BRANCH=none BUG=b:124474520 TEST=With msleep(10) in power_handle_state and printout in the else branch of chipset_watchdog_interrupt => AP poweroff does not cause a watchdog reset. TEST=stop daisydog; echo > /dev/watchdog => system resets after a few seconds Change-Id: I532b1968abb90bd9e96856020faf16080fe67af3 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1490793 Reviewed-by: Yilun Lin <yllin@chromium.org>
* power/mt8183: Detect AP-initiated PMIC shutdown and stay S5/G3Nicolas Boichat2019-02-271-1/+12
| | | | | | | | | | | | | | | Without this change, EC would go to POWER_S5 state, and immediately go back to S3, which resets the system. BRANCH=none BUG=b:126295807 TEST=poweroff in AP console, systems goes to G3 (without requiring forced PMIC shutdown) and stays there Change-Id: Icbff7eb3962e26a6e2e9cb061f53665b9d94423b Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1490791 Reviewed-by: Yilun Lin <yllin@chromium.org>
* power/intel_x86: Do not restore SCI/SMI masks if not backed upFurquan Shaikh2019-02-201-0/+11
| | | | | | | | | | | | | | | | | | | | | | Currently, if the host indicates intent to enter S0ix using host command but fails to drop into S0ix (i.e. assert SLP_S0#), then it results in EC not backing up SCI/SMI masks. However, SCI/SMI masks were being unconditionally restored when host sent command to exit S0ix. This resulted in failed S0ix to wipe out the SCI mask. This change skips restoring SCI/SMI masks if backup masks are zero. BUG=b:124540202 BRANCH=None TEST=Ensured that with S0ix failure, SCI mask was not wiped out. Change-Id: Ia79829b616ebff460e2436b03653f74aaf6c1ba0 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/1476291 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* cometlake: Guard passing RSMRST_L to PCH by PP5000_A railScott Collyer2019-02-041-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | RSMRST_L gets passed along to the AP by EC when it changes state. For low to high transitions the EC needs to ensure that the PP5000_A rail is up prior to passing the RSMRST_L transition to the AP. This CL adds a check to prevent calling common_intel_x86_handle_rsmrst() when RSMRST_L is high if the PP5000_A rail is not up. Since PP5000_PG signal will float high when the regulator is not powered at all, both the enable and power good signals are used to verify that PP5000_A rail is powered. BRANCH=none BUG=b:122631914 TEST=Verified on scope that RSMRST_L to PCH rising edge happens after PP5000_A rail rising. Change-Id: Icfd4dabbdfaf6ae76b3cdcbc6f75a5188a21ff51 Signed-off-by: Scott Collyer <scollyer@google.com> Reviewed-on: https://chromium-review.googlesource.com/1406497 Commit-Ready: Scott Collyer <scollyer@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* cometlake: Add power sequencing support for cometlake chipsetScott Collyer2019-01-244-0/+168
| | | | | | | | | | | | | | | This CL adds cometlake specific portions of power sequencing. BRANCH=none BUG=b:122251649 TEST=make buildall, verified in factory that AP gets to S0 Change-Id: I84726cd522ab55ca9ec095b94392ffa387fb253f Signed-off-by: Scott Collyer <scollyer@google.com> Reviewed-on: https://chromium-review.googlesource.com/1377570 Commit-Ready: Scott Collyer <scollyer@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* kukui: Add BOARD_REV 2 configs.Yilun Lin2019-01-231-0/+12
| | | | | | | | | | | | | | TEST=BOOTBLOCK=... make BOARD=kukui -j flash_ec; and see AP boots. BUG=b:122993147 BRANCH=None Change-Id: I1f76d87aa152ba3c3d7c8697140c7c4769b55d28 Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1420247 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Tony Lin <tonycwlin@google.com> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* kukui: Remove BOARD_REV 0 GPIO configs.Yilun Lin2019-01-221-4/+0
| | | | | | | | | | | | | | | We don't use P0 boards anymore, so let's remove P0 GPIO configs. TEST=make BOARD=kukui -j BUG=b:122993147 BRANCH=None Change-Id: I1859c4c9b182a0acee6e314e8c06fb34a3973f10 Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1420246 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* cheza: Ensure POWER_GOOD low after forcing shutdownWai-Hong Tam2019-01-111-21/+23
| | | | | | | | | | | | | | | | | | In power_chipset_init(), it forces the system shutdown by turning off the switchcap if it is not a sysjump. The POWER_GOOD indicator needs time to drop. Make sure it is low before executing the power state machine. Make this wait to every case of turning on/off the swithcap. BRANCH=none BUG=b:120889835 TEST=Typed "reboot ap-off" in EC console and verified AP off. Change-Id: I50f4f51793de1482fc2dd9b3dd05819bb2501cdc Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/1404100 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org>
* sdm845: Wait for battery to stablize before bootPhilip Chen2019-01-101-5/+8
| | | | | | | | | | | | | | | | According to the comments, we should call battery_wait_for_stable() to avoid a potential issue. BUG=b:121392631 BRANCH=None TEST=Cutoff cheza battery and plug in AC to boot to display Change-Id: I917622968babe626a4a88bb99c96bc3d864702f9 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/1389062 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Wai-Hong Tam <waihong@google.com>
* cheza: Wait power button release before actually boot APWai-Hong Tam2018-12-101-22/+17
| | | | | | | | | | | | | | | | | | | | | The power button hold may be a recovery boot trigger, i.e. long holding the key combination: power button + volume up + volume down. We don't want AP up during the long-hold. BRANCH=none BUG=b:119628964 TEST=Holding Power button 8s to shutdown; holding the combo Power + VolUp + VolDn and saw: * power state machine staying at S5S3 (AP still down) * after 8s, H1 issuing EC reboot and EC waiting VolDn release * releasing VolDn and EC boot continue * power state machine staying at S5S3 (AP still down) * releasing VolUp and Power button to boot into S0 Change-Id: I637fe54ad9e51050df5d950647c1f00c6da72c52 Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/1355369 Reviewed-by: Stephen Boyd <swboyd@chromium.org>
* flapjack: add initial content for the buildYH Lin2018-12-101-1/+1
| | | | | | | | | | | | | | | | | Initial content of flapjack is taken after kukui. It will need to be revised later. BUG=b:120704238 TEST=build_packages --board=flapjack BRANCH=none CQ-DEPEND=CL:1368583,CL:1368475,CL:*727368 Signed-off-by: YH Lin <yueherngl@chromium.org> Change-Id: Id2ccb43af46ef0b498112ecc2b9995227cbb9bc6 Reviewed-on: https://chromium-review.googlesource.com/1369384 Commit-Ready: YH Lin <yueherngl@chromium.org> Tested-by: YH Lin <yueherngl@chromium.org> Reviewed-by: Nick Sanders <nsanders@chromium.org>
* cheza: Make chipset_reset do a warm resetWai-Hong Tam2018-12-091-6/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the chipset_reset function do a warm reset to match the expectation of what AP-initiated reset does, which is also a warm reset but triggered by PS_HOLD. The warm reset is done by sending a low pulse to the PMIC RESIN_L pin, which requires PMIC registers being reprogrammed that makes it as a warm reset trigger. If the PMIC registers not reprogrammed properly, it falls back to do a cold reset power sequence. It is done by EC monitoring the AP_RST_L signal, which is already one of the power signals. BRANCH=none BUG=b:117941911 TEST=Typed "apreset" just after "reboot" (PMIC registers not programmed), checked the transition S0 -> S5 -> S0. TEST=Typed "apreset" when AP booted into userspace (PMIC registers programmed), checked a warm reset happened, AP_RST_L toggled. Change-Id: Ia1c5c7a8fd56a9e4867d4dd4c8bf2333c083c616 Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/1330117 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org>
* cheza: When warm_reset-toggling finished, issue a request to resetWai-Hong Tam2018-12-091-25/+10
| | | | | | | | | | | | | | | | | | When warm_reset-toggling finished, don't call the chipset_reset() function, which will be changed to do a warm reset, do issue a request to initiate a reset sequence. BRANCH=none BUG=b:117941911 TEST=Tried "dut-control warm_reset:on" and "dut-control warm_reset:off" during firmware (PMIC registers not programmed) and userspace (PMIC registers reprogrammed). Checked doing S0 -> S5 -> S0 transition. Change-Id: I6011fa6bfc9c5b60807bcbef6326b13a2983b37f Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/1330116 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Alexandru M Stan <amstan@chromium.org>
* cheza: Make apreset and apshutdown calls follow the state machineWai-Hong Tam2018-12-091-24/+24
| | | | | | | | | | | | | | | | | | | | | The console command 'apreset' and 'apshutdown' now just set flags which trigger state transition in the power state machine. They no longer call the power-off sequence directly. So the hooks should be triggered properly. BRANCH=none BUG=b:119050865 TEST=Ran "apshutdown" and checked the state transition from S0 -> S5. TEST=Ran "apreset" and checked the state transition from S0 -> S5 -> S0. TEST=Call "dut-control warm_reset:on sleep:0.2 warm_reset:off" and checked the state transition from S0 -> S5 -> S0. Change-Id: Idb5af2021273d32ec7f718abf18e43c43b752c7e Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/1325173 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org>
* cheza: Execute the power-off sequence on S3S5Wai-Hong Tam2018-12-061-15/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the power-off call from S0S3 to S3S5, such that the hooks are triggered in an expected order. The console command apreset and apshutdown still have some wrong orders. Will be fixed later. BRANCH=none BUG=b:119050865 TEST=Tried the following cases: * Cold reset: $ dut-control cold_reset:on sleep:0.2 cold_reset:off Result: S3 -> S5S3 -> S3 -> S3S0 -> S0 * Long power press to shutdown: $ dut-control pwr_button:press sleep:20 pwr_button:release Result: S0 8s-> S0S3 -> S3 -> S3S5 12s-> S5 10s-> S5G3 -> G3 * Long power press to power-on but then shutdown: $ dut-control pwr_button:press sleep:20 pwr_button:release Result: G3 -> G3S5 -> S5 -> S5S3 8s-> S3S5 12s-> S5 10s-> S5G3 --> G3 * Not-long power press to power-on: $ dut-control pwr_button:press sleep:5 pwr_button:release Result: G3 -> G3S5 -> S5 -> S5S3 5s-> S3 -> S3S0 -> S0 TEST=Verified the suspend and shutdown hooks are triggered properly. Change-Id: I6350d1535f1c6374eacc710c1b3f0c6e25027d1f Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/1325172 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Philip Chen <philipchen@chromium.org>
* baseboard/octopus: Enable CONFIG_BOARD_HAS_RTC_RESETKarthikeyan Ramasubramanian2018-12-051-0/+1
| | | | | | | | | | | | | | | | | | | Add a helper function to reset the RTC using EC_PCH_RTCRST GPIO. Enable the config to use the hardware support to reset the RTC. BUG=b:119678692 BRANCH=octopus TEST=make -j buildall && Boot to ChromeOS. Create a forced scenario to trigger an RTC reset and ensure that EC does not get reset while the SoC boots to ChromeOS. Execute warm reboot from AP, cold reboot from EC and wake from ec hibernate (10 iterations each) and suspend_stress_test for 50 iterations successfully. Change-Id: I5eb1025cdaa62098de0250640788921621829cd1 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1354494 Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* power/rk3399: Remove unused power_seq_versionPhilip Chen2018-12-011-17/+11
| | | | | | | | | | | | | | | | | | The current power_seq_version 1 is only for Scarlet rev0, which is not supported anymore. BUG=b:119617491 BRANCH=scarlet TEST=manually test on dru, confirm S5->S0->S5 and S0->S3->S0 still work fine TEST=buildall Change-Id: I0784cecddd3911f057998eb21b8edb5c577431e5 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/1337464 Commit-Ready: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Wai-Hong Tam <waihong@google.com>
* power/rk3399: Do not boot until power button is releasedPhilip Chen2018-11-191-2/+15
| | | | | | | | | | | | | | | | | This is the expected behavior for tablet/detachable. BUG=b:119508214 BRANCH=scarlet TEST=When a dru is off, press VolUP + VolDN + Pwr buttons for 10 secs without seeing dru boots, and then release those buttons, confirm dru enters recovery mode. Change-Id: Ib8d018da2af23a80a644f75808f9ed391b35d0f0 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/1336739 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Wai-Hong Tam <waihong@google.com>
* power/mt8183: Fix power transition from S3 to S0.Yilun Lin2018-11-081-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AP_IN_S3_L asserted should equal to IN_SUSPEND_ASSERTED rather than IN_SUSPEND_DEASSERTED. BRANCH=None BUG=b:113367227 TEST=See AP booted into kernel; and test in EC console: /* booted */ > powerinfo [22.104134 power state 3 = S0, in 0x0002] > gpioget AP_IN_SLEEP_L 1* AP_IN_SLEEP_L /* shutdown */ > aps > powerinfo [94.526641 power state 0 = G3, in 0x0001] > gpioget AP_IN_SLEEP_L 0* AP_IN_SLEEP_L /* boot again */ > powerb > powerinfo [42.273465 power state 3 = S0, in 0x0002] > gpioget AP_IN_SLEEP_L 1 AP_IN_SLEEP_L Change-Id: I13f32505dd0be82ab30a9b48b296918be688d464 Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1322183 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* power/mt8183: Obey ap-off reset flag if PMIC is already upstabilize-11217.BNicolas Boichat2018-11-011-1/+7
| | | | | | | | | | | | | | | | | On startup, we need to start from POWER_S5 if the PMIC is already up. However, if the ap-off reset flag is set, we need to make sure that we transition to G3 (and not to S3->S0). BRANCH=none BUG=b:118090373 TEST=reboot ap-off in S0/G3 works fine (AP does not boot). TEST=AP initiated reboot works fine (AP boots up) TEST=EC initiated reboot without ap-off works fine (AP boots up) Change-Id: I515f8f947bfb6b1ef45f1c2ceb7b9d9e0a324c78 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1309435 Reviewed-by: Yilun Lin <yllin@chromium.org>
* cheza: Do S0->S5->S0 transition after warm_reset-toggling finishedWai-Hong Tam2018-10-311-10/+26
| | | | | | | | | | | | | | | | | | The warm_reset is used for programming the AP SPI flash. This signal is async that the SPMI transaction between PMIC and AP may get wedged. So after the warm_reset-toggling is finished, should cold- reset PMIC and AP to get a clean state. BRANCH=None BUG=b:112723105, b:112564635 TEST=Toggled the warm_reset on different cases, e.g. S5, S0, coreboot, userspace, etc., and checked the AP reboot as expected, expected S5. Change-Id: I8d5e8690f5a6387d43f79718a8e68b2c810f4d26 Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/1285289 Reviewed-by: Stephen Boyd <swboyd@chromium.org>
* power/common: Wait some time before updating wake masksFurquan Shaikh2018-10-301-5/+35
| | | | | | | | | | | | | | | | | | | | | | On platforms like KBL, the device keeps waking up periodically for very short intervals to allow some SoC components to do book-keeping activities. If the user happens to trigger EC-related wake event during this short window, then the wakeup event could be missed because it looks like the host is in S0 to the EC. In order to avoid the race condition, update wake mask using a deferred call to allow the system state to stabilize. BUG=b:118490626 BRANCH=nocturne TEST=No more lid open failures observed on nocturne. Change-Id: I13f9f5760aaf7e54c676f43c48f9fc8de572fd01 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/1303133 Commit-Ready: Furquan Shaikh <furquan@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* cheza: Monitor the WARM_RESET_L signal to hold APWai-Hong Tam2018-10-301-1/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* system: Remember if reset was due to AP watchdog triggeringNicolas Boichat2018-10-291-1/+6
| | | | | | | | | | | | | | | | | On MT8183, when EC detects a watchdog reset, EC needs to reboot itself in preparation for the next boot. This means that AP loses the reset cause (as AP system reset is toggled), and, therefore, we need to save the reset reason in the EC. BRANCH=none BUG=b:109900671 TEST=apshutdown, powerb, see that reset reason is: reset-pin TEST=Use test-wd from bug. Reset reason: reset-pin ap-watchdog Change-Id: I2e30306db5727a22de930f00dc30de40b9695bef Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1295890 Reviewed-by: Jett Rink <jettrink@chromium.org>
* power/mt8183: Implement watchdog-initiated resetNicolas Boichat2018-10-251-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* power/mt8183: Pulse PMIC_FORCE_RESET_ODL for 10s to force resetNicolas Boichat2018-10-241-0/+20
| | | | | | | | | | | | | | | | | | On forced shutdown, assert PMIC_FORCE_RESET_ODL for 10 seconds. Sometimes, just a short 5ms pulse is enough to shut down the PMIC, but we have seen boards where it is required to assert force reset for a longer time, else the PMIC would immediately power back up. BRANCH=none BUG=b:117747023 TEST=Boot kukui (current AP FW that has no PMIC code yet), type apshutdown in EC console, see that the PMIC is shut down. Change-Id: Ic1793b6f27cebd25f96e42a9de90268566ec5772 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1278224 Reviewed-by: Yilun Lin <yllin@chromium.org>
* power/mt8183: Reboot EC before trying to boot AP for a second timeNicolas Boichat2018-10-151-3/+10
| | | | | | | | | | | | | | HW will prevent us from asserting AP_SYS_RST_L a second time, so we need to reset the EC. BRANCH=none BUG=b:117244116 TEST=Boot kukui => apshutdown => powerb, see that EC resets itself Change-Id: I55236db05777652c171a71dc3fd15fafd7d87434 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1278223 Reviewed-by: Yilun Lin <yllin@chromium.org>
* intel_x86: Clear SCI/SMI masks only after host enters S0ixFurquan Shaikh2018-10-081-42/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CL:1099968 cleared SCI/SMI masks on receiving host command indicating entry into S0ix. On the other hand, wake mask is programmed only after host actually enters S0ix based on the EC power state machine. However, if the host actually takes a long time to suspend, then it leaves a wide window open where none of the masks are programmed and hence user events like lidopen could get dropped. This change updates the behavior to ensure that SCI/SMI masks get cleared only after power state machine actually enters S0ix based on the SLP_S0 signal. This action is not done as part of a suspend hook because other hooks can result into host events getting set that can trigger SCI/SMI thus leading to the original problem of EC not going into low power idle. Hence, SCI/SMI masks are cleared before any suspend hook is run. BUG=b:116540387 BRANCH=nocturne TEST=None Change-Id: I463c12febc49eefe852bd6e2c2535e96ad94ada0 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/1258564 Commit-Ready: Furquan Shaikh <furquan@chromium.org> Tested-by: Caveh Jalali <caveh@google.com> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Caveh Jalali <caveh@google.com>
* cheza: Turn off 3.3V rail on S5Wai-Hong Tam2018-10-041-2/+4
| | | | | | | | | | | | | | | Once the hardware bug is fixed, we can turn off the 3.3V rail on S5 to save power. BRANCH=none BUG=b:110988793 TEST=Tested the EC UART work properly in S5 on a r3 board. Change-Id: I5d1dfcf8a6887e962d761b93e25722de66f61d62 Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/1194345 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org>
* mt8183: Hold power button 10s for hard shutdown.Yilun Lin2018-10-041-2/+2
| | | | | | | | | | | | | | | | Hard shutdown rules for tablet is 10 sec. go/crosdebug TEST=press pwr btn for 10s, and see chipset_force_shutdown in console BUG=b:117243957 BRANCH=None Change-Id: I44fed345f71b503a0d502c5566f4fcba54f80fb9 Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1260722 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Tony Lin <tonycwlin@google.com> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
View Lorry Controller Status