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