summaryrefslogtreecommitdiff
path: root/power
Commit message (Collapse)AuthorAgeFilesLines
* corsola: Enable CHIPSET_RESUME_INIT hook configurationlschyi2022-06-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Enable CHIPSET_RESUME_INIT hook on mt8186 platform and corsola, and trigger it from S3 -> S0. BUG=b:229810117 TEST=Check the operation mode register (0x00) entering/leaving S3: (1) USB 3 device is connected, register value not changed with different type c side. (2) USB 2 device is connected, only the USB mode bit is unset at S3, and set in S0. (3) USB 2 device is connected in S0, and remove the device when in S3. USB mode bit is unset after back to S0. (4) Connect a A->C adapter in S0, then insert USB 2/3 device in S3. The USB mode bit is set after leaving S3. `lsusb` can identify the device under USB 2/3 bus. (5) USB mode bit is always unset if no device is connected. (6) type c display is connected, register value not changed. BRANCH=None Signed-off-by: lschyi <lschyi@google.com> Change-Id: Ic7bfcbc401e5e94d2cc8f2ec7d39c5801daaf0b5 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3707068 Tested-by: Sung-Chi Li <lschyi@chromium.org> Reviewed-by: Eric Yilun Lin <yllin@google.com> Commit-Queue: Sung-Chi Li <lschyi@chromium.org>
* power/mt8186: delay HOOK_CHIPSET_SHUTDOWN_COMPLETE to S5G3.Eric Yilun Lin2022-05-301-1/+9
| | | | | | | | | | | | | | | | | | | | Normally, HOOK_CHIPSET_SHUTDOWN_COMLETE is called in S3S5, but on Mediatek platform, if it's a shutdown triggered by EC side, then EC is unable to set up PMIC registers for a graceful shutdown. What we can do instead is a force shutdown by asserting EC_PMIC_EN_ODL for 8 seconds, and all the rails are forced off, and the system will enter G3 after EC_PMIC_EN_ODL is released. BUG=b:233988259 TEST=hibernate at S0, and ensure the system enter G3 before hiberate BRANCH=none Change-Id: I8cbc5ad979b6b2fe074b7fd6167d484109a40aa4 Signed-off-by: Eric Yilun Lin <yllin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3676899 Tested-by: Eric Yilun Lin <yllin@google.com> Commit-Queue: Eric Yilun Lin <yllin@google.com> Reviewed-by: Ting Shen <phoenixshen@chromium.org>
* power/mt8186: stay at S5 before PMIC is fully offEric Yilun Lin2022-05-301-10/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we command the device to enter hibernate mode before PMIC is fully off, then there will be power leakage from AP_EC_WDTRST_L which is pulled up by PMIC. On MT8186, the S5 was a transition state, it passed through S5 and entered G3 before the PMIC is fully off. In normal cases, this won't be an issue that it takes long enough time to hibernate from G3. However, firmware_ECWakeFromULP force EC enter hibernation once the DUT gets into the G3, and this hits the PMIC issue. To fix this, we force the DUT staying at S5 until the EC_PMIC_EN_ODL released (8 seconds), and then enter the G3 state. BUG=b:233988259 TEST=stay at S5 until EC_PMIC_EN_ODL deasserted and then into G3. TEST=Test following items: * Cold reset: $ dut-control cold_reset:on sleep:0.2 cold_reset:off Result: G3 -> S0 * Long power press to shutdown: $ dut-control 'ec_uart_cmd:powerbtn 8200' Result: S0 -> S5 -> G3 * Long power press to power-on but then shutdown: $ dut-control 'ec_uart_cmd:powerbtn 8200' Result: G3 -> S0 -> S5 -> G3 * Short power press to power-on: $ dut-control 'ec_uart_cmd:powerbtn 200' Result: G3 -> S0 * Console command: apreset Result: S0 -> S5 -> S0, AP reboots * Console command: apshutdown Result: S0 -> S5 -> G3 * Lid open to power-on: $ dut-control lid_open:no sleep:0.2 lid_open:yes Result: G3 -> S0 BRANCH=none Change-Id: Id5809ff5dc72e35a75d9b20b2013522610ae4eaf Signed-off-by: Eric Yilun Lin <yllin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3676896 Commit-Queue: Eric Yilun Lin <yllin@google.com> Tested-by: Eric Yilun Lin <yllin@google.com> Reviewed-by: Ting Shen <phoenixshen@chromium.org>
* power: MTL: Allow driving PCH_PWROK from ECVijay Hiremath2022-05-171-0/+6
| | | | | | | | | | | | | | | | PCH_PWROK signal is combination of ALL_SYS_PWRGD and SLP_S3. Silego chip used on MTL-RVP can detect the high voltage level at 2.13V. However SLP_S3 coming from PCH is 1.8V. Hence use the EC gpio to trigger the PCH_PWROK. BUG=none BRANCH=none TEST=MTL-RVP can boot to S0 Change-Id: I9a9d12f8d26452db5b446776d8b7c61c84918227 Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3585883 Reviewed-by: Keith Short <keithshort@chromium.org>
* power: Add new chipset_power_on APIJack Rosenthal2022-04-291-0/+8
| | | | | | | | | | | | | | | | | | | This is a simple API for subsystems to request the chipset to power on. It's required so that the chargesplash state machine can request a chipset power on upon AC connection. Right now it's only implemented for x86 and Qualcomm as an example. Support for other platforms can be added as required. BUG=b:228370390 BRANCH=none TEST=with follow-on CL, chargesplash can power on Signed-off-by: Jack Rosenthal <jrosenth@chromium.org> Change-Id: I73a0fa21d5aea6bc46ad23eed2b8d908d217fe0e Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3615483 Reviewed-by: caveh jalali <caveh@chromium.org> Reviewed-by: Wai-Hong Tam <waihong@google.com>
* power/intel_x86: block RSMRST until the system is in S5Zhuohao Lee2022-04-211-5/+3
| | | | | | | | | | | | | | | | | | | | | | | When we set the EN_S5_RAILS to enable the 3.3v/5v power for the ap spi flash programming via the C2D2, the power sequence ic will deassert the SEQ_EC_RSMRST_ODL in the G3 state. In order to avoid the ap being powered on during the C2D2 programming, we need to bypass the RSMRST before the system enters the S5. As a result, we add CONFIG_CHIPSET_X86_RSMRST_AFTER_S5 to block the RSMRST until the system goes to S5. Since the APL/GLK already applied the same approach, we enable the CONFIG_CHIPSET_X86_RSMRST_AFTER_S5 for the APL/GLK by default in the config.h. BUG=b:223084533 BRANCH=None TEST=cros ap flash -b brya -i ${IMAGE} Change-Id: I14039b405adc62e91436759eddacf6f9dc141eff Signed-off-by: Zhuohao Lee <zhuohao@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3583905 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: caveh jalali <caveh@chromium.org>
* amd_x86: Clear SMI/SCI event mask early during suspendRob Barnes2022-04-121-7/+5
| | | | | | | | | | | | | | | | | Clear the SMI/SCI event mask at the earliest indication that the host is suspending. The earliest indication is the host sleep event. This avoids the case where the EC asserts an event while the host has already started suspending which can cause a premature wake. BUG=b:213423172 BRANCH=guybrush TEST=suspend_stress_test while also attempting to trigger an SCI event Do not observe any premature wakes after 100+ cycles Change-Id: I83a842c64d33703595c4e9a5b110d038035cf72e Signed-off-by: Rob Barnes <robbarnes@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3580114 Reviewed-by: Diana Z <dzigterman@chromium.org>
* jsl: Kick chipset SM if power loss in suspendAseda Aboagye2022-04-011-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On the jasperlake platforms, our DSW_PWROK is actually generated by the EC but it relies on the ADC interrupts to be enabled. For power reasons, we do not keep the ADC interrupts enabled during suspend as the assumption is that the power rails will not be lost. However, it seems that that may actually occur. This would cause the chipset state machine to be stuck in suspend when the system is actually no longer in suspend. This commit simply has the EC do a couple of things: - In suspend, assume that the PP3300_A power good follows the enable - During a force shutdown, manually trigger the chipset state machine to re-evaluate the current signals. BUG=b:218596390 BRANCH=firmware-dedede-13606.B TEST=Build and flash magolor, login as guest, close lid, wait for system to enter S0ix. Issue `apshutdown` on EC console, verify that DUT enters S5 and G3. Open lid, verify that DUT boots back to S0. Signed-off-by: Aseda Aboagye <aaboagye@google.com> Change-Id: I2e104857851f245bf37574a8a47e415633fb9e77 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3566111 Reviewed-by: Diana Z <dzigterman@chromium.org> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Feels: Aseda Aboagye <aaboagye@chromium.org>
* power: add casts for power signalsTom Hughes2022-03-282-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | When building with clang, it warns: power/alderlake_slg4bd44540.c:71:11: error: implicit conversion from enumeration type 'enum espi_vw_signal' to different enumeration type 'enum gpio_signal' [-Werror,-Wenum-conversion] .gpio = SLP_S5_SIGNAL_L, ^~~~~~~~~~~~~~~ include/power/intel_x86.h:53:25: note: expanded from macro 'SLP_S5_SIGNAL_L' Although "enum espi_vw_signal" and "enum gpio_signal" are not directly compatible, it appears that the code in power/common.c takes that into account by calling espi_signal_is_vw(). BRANCH=none BUG=b:172020503 TEST=./util/compare_build.sh -b all -j 120 => MATCH Signed-off-by: Tom Hughes <tomhughes@chromium.org> Change-Id: Ic2531bf6c6d5e99674c2a2c35cd4374e7eda1bcd Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3551679 Reviewed-by: Eric Yilun Lin <yllin@google.com>
* scout: use SUSPEND and RESUME hooks for TPU powerPeter Marheine2022-03-231-15/+0
| | | | | | | | | | | | | | | | | | The changes in commit 4481408005a325a7246cefe15d305eb1975c8fac were unnecessarily complex, since HOOK_CHIPSET_RESUME is called on transition to S0 from either S3 or S0ix, and HOOK_CHIPSET_SUSPEND is similarly called when dropping from S0 to either of S3 or S0ix. BUG=b:200923497 TEST=make BOARD=puff BRANCH=puff Change-Id: If3d79ceadf60dac120c5014b0f98fb744e9d6fab Signed-off-by: Peter Marheine <pmarheine@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3544168 Reviewed-by: Sue Chen <sue.chen@quanta.corp-partner.google.com> Tested-by: Sue Chen <sue.chen@quanta.corp-partner.google.com> Reviewed-by: Joe Tessler <jrt@chromium.org>
* Scout: Power off TPU and IMX8 in S0ixSue Chen2022-03-221-0/+15
| | | | | | | | | | | | | | | Turn off PP3300_TPU_A_EN and EC_IMX8_EN in S0ix. EC_IMX8_EN is for PP5000_MX8M. BUG=b:200923497 BRANCH=puff TEST=check power consumption in suspend. Signed-off-by: Sue Chen <sue.chen@quanta.corp-partner.google.com> Change-Id: I9bd4bfa945cb95d62fc104670089e51f7bbb40ae Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3382598 Reviewed-by: Joe Tessler <jrt@chromium.org> Commit-Queue: Joe Tessler <jrt@chromium.org>
* power: Add chipset and board callbacks for sleep hangsRob Barnes2022-03-177-23/+42
| | | | | | | | | | | | | | | | | | Instead of passing a callback to host_sleep, define overridable board and chipset callbacks for sleep hang detection. Introduce a sleep_hang_type enum that identifies the type of sleep hang (suspend or resume). These changes make it eaier for boards to implement custom logic to handle sleep hangs. BUG=b:218892808 BRANCH=guybrush TEST=Observe suspend hang detection on Nipperkin with KI Change-Id: Ifacf90f808b1447633f7cfc2d570209d1e233950 Signed-off-by: Rob Barnes <robbarnes@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3529606 Reviewed-by: Diana Z <dzigterman@chromium.org>
* power: Add base code for Meteorlake power sequencingVijay Hiremath2022-03-152-0/+210
| | | | | | | | | | | | | | | | Added base code for Meteorlake power sequencing. Implementation closely follows Intel Icelake power sequencing as reference and modified the logic based on Meteorlake Platform Development Guide. BUG=b:223985632 BRANCH=none TEST=Able to boot MTLRVP to S0 Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com> Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com> Change-Id: Ia551a1e226c648d9f23aff05ad3d44c3735a2495 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3516600 Reviewed-by: Keith Short <keithshort@chromium.org>
* intel_x86: Add config to configure S5 exit timerSugnan Prabhu S2022-03-091-1/+2
| | | | | | | | | | | | | | | | | | | | On enabling Delayed Authentication Mode(DAM) in the coreboot for latest platforms, system takes more time to exit from S5 than the current wait time(4secs). Due to which EC forces the system to G3 after few retries. This patch adds a new config to allow configuration of this timeout value for which EC has to wait for S5 exit before performing RTC reset and forcing the system to G3. BRANCH=None BUG=b:191742284 TEST=Boot test on Brya with the DAM enabled coreboot Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com> Change-Id: I78821280fa5928682c9c0c742a4e00299ac49db0 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3432445 Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com> Reviewed-by: caveh jalali <caveh@chromium.org> Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.corp-partner.google.com>
* mt8186: enable AP watchdog interruptEric Yilun Lin2022-02-211-2/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reset AP (S0->S0) when AP watchdog interrupt is raised. Note that we should only do watchdog reset when it's a real WDT. A real WDT is that AP_WDTRST_L is the first power signal asserted, otherwise it's a fake WDT. Warm resets, AP shutdown will cause a fake WDT because when they are resetting the chipset, the WDT signal will be asserted in the process. BUG=b:218420108 TEST=in EC console apshutdown : S0->G3 apreset : S0->S0 lid open : G3->S0 toggle cold reset: G3->S0 powerbtn 8.2s : S0->G3 in AP console ectool apreset : S0->S0 shutdown : S0->G3 stop daisydog; echo > /dev/watchdog: S0->S0 reboot : S0->S0 BRANCH=none Change-Id: Ic0360c1eff1cf25d7a28974d76af41dd0c2984cd Signed-off-by: Eric Yilun Lin <yllin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3459589 Reviewed-by: Ting Shen <phoenixshen@chromium.org> Tested-by: Eric Yilun Lin <yllin@google.com> Auto-Submit: Eric Yilun Lin <yllin@google.com> Commit-Queue: Eric Yilun Lin <yllin@google.com>
* qcom: Catch the unexpected case that POWER_GOOD up again after lostWai-Hong Tam2022-02-161-7/+19
| | | | | | | | | | | | | | | | | | When the POWER_GOOD was lost, it sets the shutdown_from_on flag. We don't expect the POWER_GOOD up again. However, a hardware bug makes this happen. Catch this unexpected case and go straight to turn off the switchcap. BRANCH=None BUG=b:218878427 TEST=Typed "shutdown -P now" in userspace. Saw the EC warning message: [41.599700 Warning: POWER_GOOD up again after lost] Change-Id: Ieadffd5347f46070336cc608af2ed3cbc20c612c Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3466417 Reviewed-by: Alexandru Stan <amstan@chromium.org> Commit-Queue: Alexandru Stan <amstan@chromium.org>
* qcom: Unconditionally disable AP_RST_L interrupt on power offWai-Hong Tam2022-02-161-5/+6
| | | | | | | | | | | | | | | | Move disabling the AP_RST_L interrupt out of the if clause. The if clause won't be entered if the shutdown is triggered by POWER GOOD lost. BRANCH=None BUG=b:218878427 TEST=Triggered the power off sequence from the AP side. Checked the AP_RST_L interrupt disabled. Change-Id: I69c22a44f6fa42ec4397b52a7a2d9d025c2de5b4 Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3466416 Reviewed-by: Alexandru Stan <amstan@chromium.org>
* qcom: Swap a reliable signal to confirm PMIC powerWai-Hong Tam2022-02-121-2/+2
| | | | | | | | | | | | | | | | | | | | Previously, we used the PMIC_KPD_PWR_ODL as a signal to confirm if the PMIC is powered. In the recent QC project, the KPD_PWR_N has internal pull-up to a PMIC's 1.1V rail. The 1.1V is under the Vih(min). So the EC may sample it incorrectly and may lead to a wrong decision path. The PMIC_RESIN_L signal has internal pull-up to a 1.8V. Using this signal is more reliable. BRANCH=None BUG=b:218876104 TEST=Verified the power-on and power-off sequence. Change-Id: I9217f334f2684a8b4265a44f3b10b07412a250d2 Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3456706 Reviewed-by: Stephen Boyd <swboyd@chromium.org>
* qcom: Clear all power-on trigger flags after handling oneWai-Hong Tam2022-02-101-22/+20
| | | | | | | | | | | | | | | | | Multiple power-on trigger flags may be flipped. The check_for_power_on_event() handles one according to the precedence. It should clear all other flags at the end. Otherwise, the pending flag may trigger another unexpected power-on. BRANCH=None BUG=b:218518083 TEST=Tested all the power-on triggers. Change-Id: Ia94fa80b3aba40a2cbb552d937ffb56507f9ee3b Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3450999 Reviewed-by: Jeremy Bettis <jbettis@chromium.org>
* AMD: Add fake S0 supportDiana Z2022-02-071-0/+17
| | | | | | | | | | | | | | | | Add in support for a fake S0 state. Since we rely on the SoC SLP signals to sequence, we can encourage sequencing through just turning these GPIOs into outputs and setting them. Disable the forced power sequencing by setting them to inputs again. BRANCH=None BUG=b:209613841 TEST=make buildall Signed-off-by: Diana Z <dzigterman@chromium.org> Change-Id: I30a07b9accdd5632fa303e05ac12201f3f86cfb2 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3430301 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* Power: Add fake S0 console commandDiana Z2022-02-051-0/+26
| | | | | | | | | | | | | | | | Add a console command which can be used to sequence into S0, even when the SoC isn't populated. The bulk of the work is performed in the chip's power code, as the implementation will need to be chipset-specific. BRANCH=None BUG=b:209613841 TEST=make -j buildall Signed-off-by: Diana Z <dzigterman@chromium.org> Change-Id: If7f1467a314ef9ab299bb8ad1a153a1e82bfe758 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3430300 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* qcom: Move the execution of warm reset to CHIPSET contextWai-Hong Tam2022-01-271-11/+28
| | | | | | | | | | | | | | | | | | | | | In CrOS EC, the `apreset` command is executed in the CONSOLE context. But in Zephyr, the command is executed in the lowest priority task context. This low priority task is easily preempted and makes the power signal missing. This miss is wrongly treated as the PMIC not respond correctly and trigger a cold reset sequence: S0 -> S5 -> S0. This CL moves the execution to the CHIPSET task context. It is now independent from the console runtime. BRANCH=None BUG=b:215252361 TEST=Call the `apreset` command, just a warm reset triggered. Change-Id: I2be65db46b453421c2a04d10a75c01dbf16f1f89 Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3418118 Reviewed-by: Alexandru Stan <amstan@chromium.org>
* qcom: Rename the POWER_REQ_COLD_RESETWai-Hong Tam2022-01-271-4/+4
| | | | | | | | | | | | | Make the name clearer to reflect the request of the cold reset. BRANCH=None BUG=b:215252361 TEST=Trigger the `apreset` command and have the same behavior. Change-Id: I4dbd241433945449cd41db5cf956312462280cee Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3418117 Reviewed-by: Alexandru Stan <amstan@chromium.org>
* qcom: Refactor the AP warm reset sequenceWai-Hong Tam2022-01-271-9/+26
| | | | | | | | | | | | | | | | | Separate the warm reset sequence to the function warm_reset_seq(). Rename the power-on sequence to the function power_on_seq(). Rename the power-off sequence to the function power_off_seq(). No logical change. BRANCH=None BUG=b:215252361 TEST=Trigger the `apreset` command and have the same behavior. Change-Id: I90a5a547b8b182b9236fed3d73a0a4febc56ee0c Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3418116 Reviewed-by: Alexandru Stan <amstan@chromium.org>
* zephyr: Change power_common tests to avoid tasksJeremy Bettis2022-01-121-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | Change test_power_exit_hard_off and test_power_reboot_ap_at_g3 to run before ec_app_main, to avoid background tasks. Remove force_power_state from stubs. I plan to remove more code from stubs and replace it with real code from qcom.c, and force_power_state is one of the things that needs to be deleted. BRANCH=None BUG=b:214256453 TEST=zmake testall Change-Id: I022344b1352e0daebf3d12ba623bc78b79f6f2ff Signed-off-by: Jeremy Bettis <jbettis@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3384478 Commit-Queue: Jeremy Bettis <jbettis@chromium.org> Tested-by: Jeremy Bettis <jbettis@chromium.org> Auto-Submit: Jeremy Bettis <jbettis@chromium.org> Reviewed-by: Aaron Massey <aaronmassey@google.com> Commit-Queue: Aaron Massey <aaronmassey@google.com>
* power: add mt8186 power sequenceTing Shen2022-01-072-0/+411
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MT8186 power sequence is a simplified version of 8192/95. EC does not lie between AP and PMIC, so there's no need to forward the signals. Other logics are almost the same. BUG=b:206338930 TEST=Test following items on krabby CL:3233784 * Cold reset: $ dut-control cold_reset:on sleep:0.2 cold_reset:off Result: G3 -> S0 * Long power press to shutdown: $ dut-control 'ec_uart_cmd:powerbtn 8200' Result: S0 -> S5 -> G3 * Long power press to power-on but then shutdown: $ dut-control 'ec_uart_cmd:powerbtn 8200' Result: G3 -> S0 -> S5 -> G3 * Short power press to power-on: $ dut-control 'ec_uart_cmd:powerbtn 200' Result: G3 -> S0 * Console command: apreset Result: S0 -> S5 -> S0, AP reboots * Console command: apshutdown Result: S0 -> S5 -> G3 * Lid open to power-on: $ dut-control lid_open:no sleep:0.2 lid_open:yes Result: G3 -> S0 BRANCH=none Cq-Depend: chromium:3366102 Signed-off-by: Ting Shen <phoenixshen@google.com> Change-Id: Iebfe77c8f6d127ee4d0685903b67afd215ca6682 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3233783 Reviewed-by: Eric Yilun Lin <yllin@google.com> Tested-by: Ting Shen <phoenixshen@chromium.org> Commit-Queue: Ting Shen <phoenixshen@chromium.org>
* power/icelake: Add SLP_S5 as a watched power signalEvan Green2021-12-021-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Add SLP_S5_SIGNAL_L as a power signal we start observing and reporting changes on for alderlake. Note that without CONFIG_HOSTCMD_ESPI_VW_SLP_S5, no software actually responds to changes on this line. Additionally, without the above config switched on, SLP_S5_SIGNAL_L defaults to SLP_S4_SIGNAL_L, so we're actually watching VW_SLP_S4 and reporting it as SLP_S5_DEASSERTED. There's nothing technically wrong with this (since nobody takes any action now on the new signal anyway). But to keep things comprehensible I'll add a dependency on the change that flips on VW_SLP_S5 support, where we'll actually start watching, reporting on, and responding to VW_SLP_S5 under its correct power signal name. BRANCH=None BUG=b:204947672 TEST=hiberman hibernate --test-keys on volteer Cq-Depend: chromium:3289944 Signed-off-by: Evan Green <evgreen@chromium.org> Change-Id: I23191e2a422f1813c2a3d72614f2d7503aacde20 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3310528 Reviewed-by: Keith Short <keithshort@chromium.org> Commit-Queue: Keith Short <keithshort@chromium.org>
* power/alderlake: Add SLP_S5 as a watched power signalEvan Green2021-12-021-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | Add SLP_S5 as a power signal to watch and generate interrupts for when it changes. This change doesn't really do anything by itself since there's no software which observes and responds to these changes. Additionally, without CONFIG_HOSTCMD_ESPI_VW_SLP_S5, SLP_S5_SIGNAL_L is defined to SLP_S4_SIGNAL_L, so we're actually reporting changes of VW_SLP_S4 under this new power signal. In the next CL, we'll wire up the common SLP_S5 power signal to this virtual wire so that the power state machine can actually see changes on this line. A Cq-Depend line is added, though not technically necessary, to indicate this somewhat mind-melting state is only transient. BRANCH=None BUG=b:204947672 TEST=hiberman hibernate --test-keys on volteer Cq-Depend: chromium:3286185 Signed-off-by: Evan Green <evgreen@chromium.org> Change-Id: I77b1aad508eeae3b3f8b307d02cb98460341e6bf Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3310527 Reviewed-by: Keith Short <keithshort@chromium.org> Commit-Queue: Keith Short <keithshort@chromium.org>
* power: Introduce S4 as a real power stateEvan Green2021-12-012-11/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to support hibernate (suspend to disk) on some systems, there are normally two choices for hibernate's destination power state: shutdown and S4. On most systems, shutdown is the logical choice for Chrome OS, since the wake sources are the same, and device state is properly saved/restored across an S5/G3 transition. However on Brya devices with Intel Keylocker technology, there is an IWKey (intermediate wrapping key) which software by design is not allowed to read. Intel, being no stranger to the concept of hibernate, provisioned support to save and restore this register in a platform area, while still keeping its contents inaccessible to software. However, architecturally they only guarantee this mechanism works down to S3/S4. This means in order to preserve keylocker contents during hibernation, shutdown is no longer an option. We must camp out in the architecturally designated S4 state during hibernation on devices with Intel Keylocker. The EC has long ignored this as a state since the OS doesn't support entering it. This needs to change. This patch introduces a POWER_S4 state. It's modeled after the S3 state, but represents itself as a "chipset soft off" state, like S5. Now, on Intel platforms, we (almost) always transition through S4 on our way up and down. For example, where we would normally go G3->S5->S3->S0, we now go G3->S5->S4->S3->S0. The "almost" refers to unusual error cases, where if power signals are totally wonky we may go from S3 straight to S5. The S3 <-> S5 state transitions also still exist because non-Intel platforms transition directly without going through S4. This bit of consistency was sacrificed to avoid retrofitting a bunch of ARM EC code to transition though a completely phony state. The "almost" refers to unusual error cases, where if power signals are totally wonky we may go from S3 straight to S5. The common Intel code used to look at SLP_S4 as a signal to transition between S5 and S3. Now, we look at SLP_S4 as the signal to transition to S4, and use the SLP_S5 signal to transition deeper, into S5. On platforms with virtual wire support, we should have access to the virtual SLP_S5 line already. On platforms that haven't explicitly set the config for VW_SLP_S5, we merge SLP_S5 and SLP_S4 by making them the same GPIO, so that the transition through S4 simply slides on through. This effectively disables S4 residency, so we disallow advertising S4 residency to the AP unless CONFIG_HOSTCMD_ESPI_VW_SLP_S5 is also enabled. We should then enable this on all new Intel platforms. Signed-off-by: Evan Green <evgreen@chromium.org> BRANCH=None BUG=b:204947672 TEST=hiberman hibernate --test-keys on volteer Change-Id: Icf4798fa517d40ad652a278bbea2051e4c9fb118 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3265286 Commit-Queue: Evan Green <evgreen@chromium.org> Tested-by: Evan Green <evgreen@chromium.org> Reviewed-by: Keith Short <keithshort@chromium.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* power/common.c: Merge state handling of S0/S3/S0ixEvan Green2021-12-011-10/+4
| | | | | | | | | | | | | | | | In power_common_state(), S0, S3, and S0ix all have the same thing in their cases. Merge them together in preparation for adding POWER_S4, which will yet again do the same thing. BRANCH=None BUG=b:204947672 TEST=hiberman hibernate --test-keys on volteer Signed-off-by: Evan Green <evgreen@chromium.org> Change-Id: If62fad7e93be8f1bcf4ec843c0ff236587116632 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3286184 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Keith Short <keithshort@chromium.org>
* power: Add default cases for power state handlersEvan Green2021-12-018-0/+42
| | | | | | | | | | | | | | | | | In preparation for the addition of the new POWER_S4 state (and transition states) coming in, add default cases for ARM power state handlers, which won't be adding phony transitions through a non-existent S4 state. BRANCH=None BUG=b:204947672 TEST=hiberman hibernate --test-keys on volteer Signed-off-by: Evan Green <evgreen@chromium.org> Change-Id: I48c884131037cbff917230134a34718c32ce75db Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3286183 Reviewed-by: Keith Short <keithshort@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* power/mt8192: ignore ap-off flag when manual sysjumpTing Shen2021-11-251-2/+1
| | | | | | | | | | | | | | | | | | | | Use system_jumped_late() to distinguish EFS and non-EFS jump when initialization. BUG=b:207456321 TEST=dut-control power_state:rec # wait for DUT dut-control power_state:warm_reset verify AP can boot BRANCH=none Signed-off-by: Ting Shen <phoenixshen@google.com> Change-Id: Id446c248454620eca87ffb3c61e6f732ae90a66b Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3300170 Reviewed-by: Eric Yilun Lin <yllin@google.com> Commit-Queue: Ting Shen <phoenixshen@chromium.org> Tested-by: Ting Shen <phoenixshen@chromium.org>
* intel_x86: Apply chipset resume init and suspend complete hooksDevin Lu2021-11-231-0/+18
| | | | | | | | | | | | | | | | | | | The CL:2321875 introduced a hook for chipset resume init and suspend complete. The application was applied for SPI driver for sc7180. This patch applies to intel_x86 as well. The benefit that we can initial the devices (such as PCHG) prior the chipset resume and shutdown the devices after the chipset suspend is completed. BUG=b:205675485 BRANCH=None TEST=make buildall -j Signed-off-by: Devin Lu <Devin.Lu@quantatw.com> Change-Id: I7ded958e1d2722b2e48c21466ff6fd2f82ecc5e7 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3276030 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* config: rename CONFIG_HOSTCMD_ESPI to CONFIG_HOST_INTERFACE_ESPIKeith Short2021-11-191-1/+1
| | | | | | | | | | | | | | | Rename CONFIG_HOSTCMD_ESPI to CONFIG_HOST_INTERFACE_ESPI. This makes the host interface selection configs distinct from configs used to enable/disable specific host commands. BUG=b:195416058 BRANCH=main TEST=compare_build.sh Signed-off-by: Keith Short <keithshort@chromium.org> Change-Id: I7f52614ca9a0dd54cc7e96e51bba40453564198e Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3095842 Tested-by: Michał Barnaś <mb@semihalf.com>
* falconlite: ensure WDT is deasserted when hard shutdown.Eric Yilun Lin2021-11-171-2/+9
| | | | | | | | | | | | | | | | | | | | There will be two cases when AP has a shutdown request: AP_EC_SHUTDOWN_REQ:1 AP_EC_WATCHDOG_L:1 -> This is a real shutdown request. AP_EC_SHUTDOWN_REQ:1 AP_EC_WATCHDOG_L:0 -> This is a WDT reset, and AP will handle this reboot, EC should not touch it. BUG=b:171029078 TEST=EC is able to handle AP's shutdown request. BRANCH=main Change-Id: Id89f3bc386dc73225731a96bafae48a55df06e73 Signed-off-by: Eric Yilun Lin <yllin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3270227 Reviewed-by: Ting Shen <phoenixshen@chromium.org> Commit-Queue: Eric Yilun Lin <yllin@google.com> Tested-by: Eric Yilun Lin <yllin@google.com>
* qcom: Add checks for EFS2 to the power on sequenceKeith Short2021-11-121-7/+16
| | | | | | | | | | | | | | | | | | | | | | | When EFS2 is enabled, the normal boot will always have the EC_RESET_FLAG_SYSJUMP set. Always enabled auto power on of the AP unless one of the following conditions is true: 1. EC_RESET_FLAG_AP_OFF reset flag is set 2. EC_RESET_FLAG_SYSJUMP reset flag is set, and EC_RESET_FLAG_EFS is not set. BUG=b:193719620 BRANCH=none TEST=Verify EC powers up AP after performing a sysjump when EFS2 is enabled. TEST=Set recovery mode, verify EC goes back to RO. On power down, EC jumps to RW and the AP stays in G3. Signed-off-by: Keith Short <keithshort@chromium.org> Change-Id: I222c5f6c729901b455888432cd01fe7e67b4aa7a Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3257770 Reviewed-by: Wai-Hong Tam <waihong@google.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* power: add casts for power signalsTom Hughes2021-11-123-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | When building with clang, it warns: power/icelake.c:49:11: error: implicit conversion from enumeration type 'enum espi_vw_signal' to different enumeration type 'enum gpio_signal' [-Werror,-Wenum-conversion] .gpio = SLP_S4_SIGNAL_L, ^~~~~~~~~~~~~~~ include/power/intel_x86.h:40:25: note: expanded from macro 'SLP_S4_SIGNAL_L' Although "enum espi_vw_signal" and "enum gpio_signal" are not directly compatible, it appears that the code in power/common.c takes that into account by calling espi_signal_is_vw(). BRANCH=none BUG=b:172020503 TEST=./util/compare_build.sh -b all -j 120 => MATCH Signed-off-by: Tom Hughes <tomhughes@chromium.org> Change-Id: Ibb3ac42516d2e293cf707ca92eacd6bd7c11049c Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3243003 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
* power: Combine chipset_reset_reason and chipset_shutdown_reasonTom Hughes2021-11-1211-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | When building with clang, it warns: power/amd_x86.c:59:18: error: implicit conversion from enumeration type 'enum chipset_reset_reason' to different enumeration type 'enum chipset_shutdown_reason' [-Werror,-Wenum-conversion] report_ap_reset(reason); The two enums are already set up so that they don't overlap, so just combine them into a single enum. BRANCH=none BUG=b:172020503 TEST=./util/compare_build.sh -b all -j 120 => All boards match, except: burnet cerise damu fennel jacuzzi juniper kakadu kappa katsu kodama krane kukui makomo stern willow Signed-off-by: Tom Hughes <tomhughes@chromium.org> Change-Id: I47620e59e02a84c04dde4469f36ad37dccbcd9e5 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3238250 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* power/mt8192: remove unused variableTing Shen2021-11-111-3/+0
| | | | | | | | | | | | | | BUG=none TEST=makeall BRANCH=none Signed-off-by: Ting Shen <phoenixshen@google.com> Change-Id: If1199ed3ad87867c7d6ace54c0865369e6cf7638 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3275003 Tested-by: Ting Shen <phoenixshen@chromium.org> Auto-Submit: Ting Shen <phoenixshen@chromium.org> Reviewed-by: Eric Yilun Lin <yllin@google.com> Commit-Queue: Eric Yilun Lin <yllin@google.com>
* power/rk3399: Change fake GPIOTom Hughes2021-11-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | When building with clang, it warns: power/rk3399.c:605:26: error: implicit conversion from enumeration type 'enum power_signal' to different enumeration type 'enum gpio_signal' [-Werror,-Wenum-conversion] power_signal_interrupt(POWER_SIGNAL_COUNT); ~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~ It appears the intent is to derive a signal to send that is beyond the number of power signals, but "enum gpio_signal" and "enum power_signal" are separate enums, so POWER_SIGNAL_COUNT could be some other valid GPIO. Note that this is a functional change. BRANCH=none BUG=b:172020503 TEST=CC=clang make BOARD=scarlet Signed-off-by: Tom Hughes <tomhughes@chromium.org> Change-Id: Iba143e8903c11a4315e6b74fdb8e3245938b2b50 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3243007 Reviewed-by: Diana Z <dzigterman@chromium.org>
* power: support falcon-lite power sequencingEric Yilun Lin2021-11-052-0/+509
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Copy and modified from power/mt8192.c There's no PMIC in falcon-lite, and EC has to control the rails. Besides PGOOD signals, and power enable pins, the important rails are: - AP_EC_WARM_RST_REQ: AP issues a warm reset request and EC toggles SYS_RST_ODL for a S0->S0 transition. - AP_EC_SHUTDOWN_REQ_L: This pin is repurposed from AP_IN_SLEEP_L. AP issues a shutdown request and EC forces it in to off state. - AP_EC_WATCHDOG_L: This pin is unused since AP is able to reset itself when WDT happened. There's no S3 signals for falcon-lite since AP_IN_SLEEP_L is repurposed, so we used host power info for S3/S0 transition. BUG=b:185846337 TEST=Tried the following cases: * Cold reset: $ dut-control cold_reset:on sleep:0.2 cold_reset:off Result: G3 -> S0 * Long power press to shutdown: $ dut-control pwr_button:press sleep:8.2 pwr_button:release Result: S0 -> S5 -> G3 * Long power press to power-on but then shutdown: $ dut-control pwr_button:press sleep:8.2 pwr_button:release Result: G3 -> S0 -> S5 -> G3 * Short power press to power-on: $ dut-control pwr_button:press sleep:0.2 pwr_button:release Result: G3 -> S0 * Console command: apreset Result: S0, AP reboots * Console command: apshutdown Result: S0 -> S5 -> G3 * Lid open to power-on: $ dut-control lid_open:no sleep:0.2 lid_open:yes Result: G3 -> S0 BRANCH=main Change-Id: I239975513286b062f80184f91e565d2bd6fa01ac Signed-off-by: Eric Yilun Lin <yllin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3045436 Tested-by: Eric Yilun Lin <yllin@google.com> Auto-Submit: Eric Yilun Lin <yllin@google.com> Reviewed-by: Ting Shen <phoenixshen@chromium.org> Commit-Queue: Ting Shen <phoenixshen@chromium.org>
* zephyr: mt8192: gather power-signal information from DTDenis Brockus2021-11-031-0/+4
| | | | | | | | | | | | | | | | | | This currently only uses DT power-signal for platforms that define CONFIG_AP_ARM_MTK_MT8192 BUG=b:188674805 BRANCH=none TEST=zmake testall Signed-off-by: Denis Brockus <dbrockus@google.com> Change-Id: I151c451f0725449459744b1ebda042c0c3aa6ad8 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3246296 Commit-Queue: Denis Brockus <dbrockus@chromium.org> Commit-Queue: Keith Short <keithshort@chromium.org> Tested-by: Denis Brockus <dbrockus@chromium.org> Auto-Submit: Denis Brockus <dbrockus@chromium.org> Reviewed-by: Keith Short <keithshort@chromium.org>
* power/common.c: Add explicit cast when converting between enum typesTom Hughes2021-10-291-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | clang warns: power/common.c:118:28: error: implicit conversion from enumeration type 'enum gpio_signal' to different enumeration type 'enum espi_vw_signal' [-Werror,-Wenum-conversion] return espi_vw_get_wire(signal); ~~~~~~~~~~~~~~~~ ^~~~~~ power/common.c:128:36: error: implicit conversion from enumeration type 'enum gpio_signal' to different enumeration type 'enum espi_vw_signal' [-Werror,-Wenum-conversion] return espi_vw_disable_wire_int(signal); ~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~ power/common.c:138:35: error: implicit conversion from enumeration type 'enum gpio_signal' to different enumeration type 'enum espi_vw_signal' [-Werror,-Wenum-conversion] return espi_vw_enable_wire_int(signal); The conversion appears to be intentional, so add an explicit cast. BRANCH=none BUG=b:172020503 TEST=make CC=arm-none-eabi-clang BOARD=elm -j Signed-off-by: Tom Hughes <tomhughes@chromium.org> Change-Id: Ide2abc115957385097f6ed938b0a15139cbf3d83 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3197755 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
* board: Rename RSMRST_L_PGOOD as PG_EC_RSMRST_ODLfirmware-chameleon-14280.B-mainDivya Sasidharan2021-10-124-7/+7
| | | | | | | | | | | | | | | | | GPIO_RSMRST_L_PGOOD is also used as GPIO_PG_EC_RSMRST_ODL creating redundancy. Removing it will help need for redefinitions for zephyr. Remove reference to GPIO_RSMRST_L_PGOOD in zephyr BUG=b:200975143 BRANCH=main TEST=make buildall -j, boot up on brya Change-Id: Iff46595174c54db347b69cff3ad9e266ba9fd535 Signed-off-by: Divya Sasidharan <divya.s.sasidharan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3180808 Reviewed-by: Keith Short <keithshort@chromium.org> Commit-Queue: Keith Short <keithshort@chromium.org>
* power/mt8192: set correct initial power state for EFS2Ting Shen2021-10-121-1/+2
| | | | | | | | | | | | | | | | | | | | | In EFS2, the boot flow happens in RW, so we should not set power state to S0 by default. BUG=b:185726892 TEST=1. Verify AP bootable and able to update EC-RW in following scenarios: a. old RW b. corrupted (not-bootable) RW 2. DISABLE_EC_SOFTWARE_SYNC vboot flag works. 3. manual sysjump won't reboot AP. BRANCH=main Signed-off-by: Ting Shen <phoenixshen@google.com> Change-Id: Ic088a1ccf80fc49424cc1eeb3ff7b946836e5b68 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3207813 Reviewed-by: Eric Yilun Lin <yllin@google.com> Commit-Queue: Ting Shen <phoenixshen@chromium.org> Tested-by: Ting Shen <phoenixshen@chromium.org>
* power/alderlake: Cleanup code to use common GPIO nameDivya Sasidharan2021-10-051-7/+7
| | | | | | | | | | | | | | | | | | SEQ_EC_ALL_SYS_PG is commonly named as PG_EC_ALL_SYS_PWRGD. Removing it to reduce the redundant declarations needed in zephyr. BUG=b:200975143 BRANCH=main TEST=make buildall -j; boot up brya Change-Id: Ie266460dfe9c61dbbb97e1d1b714824929c5a098 Signed-off-by: Divya Sasidharan <divya.s.sasidharan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3180807 Reviewed-by: Vijay Hiremath <vijay.p.hiremath@intel.com> Reviewed-by: caveh jalali <caveh@chromium.org> Reviewed-by: Keith Short <keithshort@chromium.org> Commit-Queue: Keith Short <keithshort@chromium.org>
* host sleep: fix infinite timeoutBoris Mittelberg2021-09-241-1/+3
| | | | | | | | | | | | | | | | | | | | Add the corner case when default == infinite BUG=b:187532888 BRANCH=none TEST=manual: 1. `/usr/share/vboot/bin/make_dev_ssd.sh --edit --part=2` 2. Add `intel_idle.max_cstate=1` 3. reboot 4. (EC) `sleeptimeout infinite` 5. `echo freeze > /sys/power/state` 6. System doesn't wake up Signed-off-by: Boris Mittelberg <bmbm@google.com> Change-Id: I5903ddd09262254a485eb9d09731bcd687b6d650 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3180260 Reviewed-by: Rajat Jain <rajatja@google.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* qcom: Deprecate WARM_RESET handlings in SC7280Wai-Hong Tam2021-09-171-10/+15
| | | | | | | | | | | | | | | | Add guards to limit the long warm_reset handling only in SC7180, such that the future generations, like SC7280, don't have it. BRANCH=None BUG=b:187980397, b:187098628 TEST=Built all the Chromium EC images and Zephyr EC images. TEST=Modify a board to use the SC7280 CONFIG. Change-Id: Iad011f58522641cde2f469f71114473476c53d67 Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2893070 Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Alexandru M Stan <amstan@chromium.org>
* herobrine: Always enable the 5V railWai-Hong Tam2021-09-161-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Prepare the next hardware revision. It has a PPC chip which requires 5V rail in S5. The 5V rail enable pin should be turned on whenever the EC is powered. Since the existing 5V rail enabling is done inside the qcom power sequence. Trogdor and Herobrine both shares this qcom power sequence. For Trogdor, this CL moves the 5V rail enabling from the qcom power sequence to the board level hook. For Herobrine, this CL updates the GPIO name and modifies the default level to HIGH. The CONFIG of 5V control should be disabled. As no board level hook to modify the 5V rail, the 5V is always on. BRANCH=None BUG=b:199804198 TEST=Booted both Zephyr and EC-OS images on Herobrine. Checked the 5V rail is enabled in S0 and S5. TEST=Booted both Zephyr and EC-OS images on Lazor. Checked the 5V rail is enabled in S0 and disabled in S5. Change-Id: Ifa98ee0c4e970dd89952e94cc6a0e289798e6a57 Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3163918 Reviewed-by: Keith Short <keithshort@chromium.org>
* power: Fix host_command_hibernation_delay returnTomasz Michalec2021-09-031-1/+1
| | | | | | | | | | | | | | | host_command_hibernation_delay() should return enum ec_status and correct value of this type to indicate success is EC_RES_SUCCESS BUG=none BRANCH=none TEST=none Signed-off-by: Tomasz Michalec <tm@semihalf.com> Change-Id: I50902829a7ef5d09786ab81bff9d791bac0dfad6 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3140204 Commit-Queue: Jeremy Bettis <jbettis@chromium.org> Reviewed-by: Jeremy Bettis <jbettis@chromium.org>
View Lorry Controller Status