The SET sub-command of EC_CMD_CHARGE_STATE sets charger current /
voltage parameters to arbitrary values and should be locked down.
EC_CMD_CHARGE_CONTROL, on the other hand, switches between several safe
operation modes, and should be allowed.
BUG=None
TEST=On kevin, set force_locked, plug zinger, and verify:
ectool chargestate param 4 3 <-- ACCESS_DENIED
ectool chargestate show <-- prints params
ectool chargecontrol idle <-- stops charging battery
ectool chargecontrol normal <-- battery charges again
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5503f07bb196d023a9bcd2e33f2e247f061f05e5
Reviewed-on: https://chromium-review.googlesource.com/757237
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The llama is a South American relative of the camel, though the llama
does not have a hump. These sturdy creatures are domestic animals used
by the peoples of the Andes Mountains.
BUG=None
TEST=`make buildall -j`
BRANCH=None
Change-Id: I55dbd8d5b0b14c41e27c4ef473833563f38878c3
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/761298
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Copied board-related files from scarlet folder and made edits to
fit rainier. Left in most battery related code and config since there
is enough logic to detect absent battery
BUG=chromium:776441
TEST=Run "make -j BOARD=rainier"
BRANCH=none
Signed-off-by: egemih@google.com
Change-Id: Ifd1201a9a44cebd9b433545f0ac7ee04741429c9
Reviewed-on: https://chromium-review.googlesource.com/755949
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Ege Mihmanli <egemih@google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Tasks will no longer be scheduled before HOOK_INIT completion, so it's
no longer possible for the chipset task to notify HOOK_SHUTDOWN before
HOOK_INIT completes.
BUG=None
TEST=`make buildall -j`
BRANCH=None
Change-Id: I78349801738ff28fe9774df0c03296fe549dc9c9
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/759242
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
With these changes
$ CROSS_COMPILE_nds32=/opt/coreboot-sdk/bin/nds32le-elf- \
make BOARD=it83xx_evb
works for me.
The -mno-gp-direct option is replaced with -mcmodel=large in new
compilers, as indicated in private email with Andes Tech. It was also
used as a work-around and leaving out the option altogether reduces the
code size significantly, so it's now dropped.
BRANCH=none
BUG=b:35572628
TEST=the above command creates an image
Change-Id: Ib580d65e6e52f291fdb920b7b65fb22cfda9f736
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/753623
Commit-Ready: Stefan Reinauer <reinauer@google.com>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Fizz blinks the power LED to alert a user when power supply isn't
enough. This patch makes the blinking speed twice as fast (on:1sec,
off:1sec).
BUG=b:37646390
BRANCH=none
TEST=Verify the LED blinks as intended.
Change-Id: I017eaf36b91d987f4b03308b1e9ac8781e5f217d
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/757557
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sometimes the AP will generate a short 'wake' pulse on the SPS CS line
just in case the chip is in the sleep state. This pulse is supposed to
wake up the chip and prepare it to process the actual SPS transaction
which follows the wake pulse in 100 us.
It turns out that under certain conditions it takes the Cr50 longer
than 100 us to react to the wake pulse, for instance when it writing
into flash which is in the same bank the code is running from, there
is no way to avoid stalling in this case.
What happens then is that the 'CS deasserted' interrupt for the wake
pulse comes while the actual SPS transaction is in progress. In this
case when processing the CS deassertion interrupt the Cr50 should not
consider it an end of a transaction, but just ignore it making sure
that the next CS deassertion still would trigger an interrupt.
BRANCH=none
BUG=b:68012381
TEST=verified that this patch helps the AP firmware test case which
was often failing due to TPM getting out of sync.
Change-Id: I412459552f4b2d13cd72800c1af7d583226e8466
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754505
TPM reset processing takes certain time, and conceivably the AP could
start SPI transactions before TPM reset is finished. If the SPS
interface comes up while the CS line is active, the H1 controller
considers this a start of the SPI cycle, even though it is not - the
AP has already transferred the header and is waiting for the flow
control.
Let's not complete SPS interface initialization while the CS line is
kept active.
BRANCH=cr50
BUG=b:68012381
TEST=verified that the AP firmware test passes
Change-Id: I53cd49c6139f3c29c4b6d234c7ee4d527c8282f6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754504
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There is no point in invoking SPS receive handler if there has been no
data transferred while CS was asserted, as would be the case when the
AP generates the wake up pulse.
Also, make sure that the flag indicating that data was seen is cleared
when the interface is reinitialized, as TPM reset could come during an
SPS transaction.
BRANCH=cr50
BUG=b:68012381
TEST=verified that the AP firmware test passes
Change-Id: I82d63d257b67a715d6dbc540c2d7480e5ff718ff
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754503
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Coral uses a 1 second delay to report battery being present to help
avoid VSYS glitches than can affect H1. On Eve, it was not expected to
remove and reconnect the battery while running. However, on Coral the
battery connector allows this action to take place.
Current if the battery is removed, when it's reconnected it can't
report as present because the timer_started flag is not being
reset. This CL checks for the case where the battery is not present
after being present and uses that as a trigger to reset the
battery_report_present_timer_started flag.
BUG=b:66923031
BRANCH=coral
TEST=While Coral unit has battery and ext AC connect, remove the
battery connector. Verifed the console log showed that this condition
was caught. Waited about 10 seconds, then reconnected battery and
verified that it reports as present.
[52.778818 Battery was present, but is now removed]
[60.211048 battery will now report present]
[60.217801 Battery FET: reg 0xe000 mask 0x4000 disc 0x0000]
[60.711195 battery woke up]
Change-Id: I41ae8c1b04a56697d20d3037b94189aff778fc4d
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/754025
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Events used when TPM task is running are defined in two different
places, one of them shared with other boards running on H1.
Let's avoid collision by redefining Cr50 only events to be different
from shared ones used by dcrypto.
BRANCH=cr50
BUG=b:68729265
TEST=verified that there is no more 'tpm_reset_request: already
scheduled' messages generated when TPM is reset when performing
long dcrypto operation.
Change-Id: Ic9517fa98be21f3ef5f19b82c593d96b0ddbaf6b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/756914
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Currently the Cr50 code resets TPM communications layer at a certain
point during TPM reset process.
It turns out that this is not sufficient - the comms layer keeps
receiving and trying to invoke TPM layer, which does not mesh well
with TPM reset.
Let's provide two callbacks for each comms layer - to shut it down and
to bring it back up. We shut down the comms when starting TPM reset
and bring them back up when reset is completed.
BRANCH=cr50
BUG=b:68012381
TEST=ran AP firmware test suite on both SPI and I2C based devices.
Change-Id: I7caf4a09b9a5c6e5fc6bfe60eae1c0d64ab24904
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754502
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
In order for BC1.2 detection to succeed, USB data switches must be
open. Previously we performed BC1.2 detection whenever VBUS transitioned
up to 5V, including on power swap. In fact, there is no need to do BC1.2
detection on a PD-capable port, since we will always charge using the
USB-C or PD negotiated ILIM. Skip BC1.2 detection on power swap (and
more generally when a partner port is known to speak PD) by manually
triggering BC1.2 detection. In addition, manage USB switch state
differently, so that "auto mode" is only enabled during BC1.2 detection.
BUG=chromium:780905
BRANCH=gru
TEST=Attach USB-PD phone capable of role swap. Verify USB 2.0 device is
enumerated on plug, and not re-enumerated through a series of
"pd # swap power" commands on the EC console. Also verify BC1.2 charging
and PD charging are still functional on kevin.
Change-Id: I1d7d4dee3bc8d2e7885e7adb49ded84b4f515ad5
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/755878
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Fizz has no battery, so any port / ILIM selection logic that could lead
to de-powering the device should be relaxed.
BUG=b:68953563
BRANCH=None
TEST=Boot fizz with both zinger and barrel charger, verify no panic /
brownout occurs.
Change-Id: I3bf353f5a26fe6210c67f8ee3f785012d4c063f0
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/756924
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
gcc 6.3 (as provided by coreboot-sdk) needs that to know which code
paths end early.
Also add a loop after the command that is "supposed" to reset the
machine so that the compiler believes it (and in case that assumption
fails).
BRANCH=none
BUG=b:65441143
TEST=none
Change-Id: Idb87253ec7880d66ffec30d75f4d007f02f63aab
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/742916
Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
It's undesirable to do BC1.2 detection on power swap, so add a function
to check if the partner port is known to be PD-capable.
BUG=chromium:780905
BRANCH=gru
TEST=With subsequent CL, attach USB-PD phone capable of role swap.
Verify USB 2.0 device is enumerated on plug, and not re-enumerated
through a series of "pd # swap power" commands on the EC console. Also
verify BC1.2 charging and PD charging are still functional on kevin.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ifa75c94e9758d3e407492bbda6fc52ed7bc378fa
Reviewed-on: https://chromium-review.googlesource.com/755877
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The bd9995x driver was written to allow any PD port # to be VBUS or VCC,
but the mapping is broken in a few places. Since all boards use VBUS =
port 0, remove the conversion entirely.
BUG=chromium:781849
BRANCH=kevin
TEST=Verify PD and BC1.2 charging still works on kevin.
Change-Id: I3687866835d1684342d9f746d91b3a6079ab5cc4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/755000
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
One can pass either a board name (e.g. hammer) or a chip name (stm32)
to the flash_ec command. If given a board name, will map to a proper
chip name and then call its chip-flashing method.
The NEED_SERVO variable ("no" if servo not needed) was set according
to the board name. It was broken if only given a chip name. It should
be set according to the chip name.
BUG=b:68943874
BRANCH=None
TEST=Flashed the Staff firmware
SERVO $ dut-control ec_boot_mode:on
DUT $ ectool gpioset PP3300_DX_BASE 0
DUT $ ectool gpioset PP3300_DX_BASE 1
DUT $ flash_ec --chip stm32_dfu --image staff_ec.bin
SERVO $ dut-control ec_boot_mode:off
DUT $ ectool gpioset PP3300_DX_BASE 0
DUT $ ectool gpioset PP3300_DX_BASE 1
Change-Id: I1799f083115bfdf203a405733c5baefadbe3fe3e
Signed-off-by: Wai-Hong Tam <waihong@google.com>
Reviewed-on: https://chromium-review.googlesource.com/755614
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Change chipset_force_shutdown() to not call power_button_pch_press()
when called from POWER_S5G3 state, so that we don't set pwrbtn=LOW
when entering G3.
BUG=b:68760602
BRANCH=none
TEST=push kahlee power button
Change-Id: I931fc73f2386f8124f1e082cccb095e3863cbb99
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/752682
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Since poppy provides a custom battery present hw gpio, enable the
config option CONFIG_BATTERY_HW_PRESENT_CUSTOM.
BUG=b:65864825
BRANCH=None
TEST=Verified that when AC power is provided without battery present,
then EC auto powers up the AP. THis is essential for factory
testing. However, in order to make this work, CONFIG_SYSTEM_UNLOCKED
needs to be disabled. Verified device boots reliably after hardware
and software battery cutoff.
Change-Id: I9da1c68dfca3fd8c76570c78259adf42bf52522f
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/752686
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
When allowing an unlocked system to automatically power up we
may attempt to boot before the charger is ready to supply enough
power and get stuck in a reset loop.
In addition, if the batttery is not physically present in the system
then delay power-on until the charger is providing at least 15W of
power. (currently defined as LIKELY_PD_USBC_POWER_MW)
By adding a final check to the charge_prevent_power_on() function
to ensure that charge_manager_get_charger_current() is returning
a valid value instead of CHARGE_CURRENT_UNINITIALIZED then the
board is able to reliably boot.
This CL combines 2 CLs made on Eve which addressed the same problem
I'm seeing on Robo devices.
https://chromium-review.googlesource.com/582545https://chromium-review.googlesource.com/709473
BUG=b:68226308
BRANCH=coral
TEST=Used Robo system which was consistently failing when external
power was connected to Port 1. After adding this change was able to
consistently power up the system without going into a reboot loop. In
addition had signal wires attached to VBUS and VSYS so could verify
that VSYS was no longer collapsing.
Change-Id: Iadecf032feaacfda230bfc98a332cd7963fb0afe
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/752755
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
We didn't set BATT_FLAG_WANT_CHARGE in battery_get_params(), so
battery command always shows 'charging not allowed'.
Let's set the flag in the same condition as it is set in
battery/smart.c.
BUG=b:68027469
BRANCH=none
TEST='battery' on EC console shows 'Charging: Allowed'
Change-Id: Ifbdb6aee2572c8fc5f67103ca940738fb221ce5d
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/749025
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Charge port / current selection often needs to be significantly altered
when a battery cannot provide sufficient charge, so have charge_manager
initially enter safe mode. After a battery with sufficient capacity has
been identified, charge manager will leave safe mode, and port / current
selection will return to standard rules.
BUG=chromium:777596
BRANCH=None
TEST=Pass charge_manager unit tests. On kevin, remove battery, attach
Apple PD charger, verify safe mode is not exited and device does not
brown out. Hot-plug battery and verify safe mode is exited. Next,
remove battery, attach to Samus, verify safe mode is not exited and
device doesn't brown out. Hot-plug battery, verify that safe mode is
exited and no active charge port, due to dual-role exclusion.
Change-Id: I7784865750087a037aad8dbbac058b22c77ba6d4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/733954
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Ensure GPIOs are inputs when read: Initialize GPIO direction on startup,
and clean up register accesses using reg names rather than magic numbers.
Add board version reporting with CONFIG_BOARD_SPECIFIC_VERSION.
BUG=None
BRANCH=servo
TEST=version is correctly 3
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Change-Id: Ia04b01932fc36540af64b48b5e0bb6516f1529e2
Reviewed-on: https://chromium-review.googlesource.com/749693
Reviewed-by: Shawn N <shawnn@chromium.org>
Most boards had an identical implementation for this function,
previously known as board_is_consuming_full_charge(). To reduce copy
paste, let's just move it to common code. Boards that charge ramp
without a battery will have to define their own implementation, but
there probably won't be any boards like that in the near future.
BUG=None
BRANCH=None
TEST=make -j buildall
Change-Id: Ic99a378ac26dfd35d7d718bf9376eacfa8609166
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/748919
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Robo's LED spec is Red <= 5%, Orange 6 < SOC < 97, Green >=
97%. However, the table had Orange and Green flipped. This CL corrects
that error.
BUG=b:64192049
BRANCH=coral
TEST=Used EC console battfake command to verify that charge LED color
is red until 5%, then orange until 94%, and green after that. Note the
94% limit is due to the define CONFIG_BATTERY_LEVEL_NEAR_FULL which is
set to 94 as that's when the battery will want charging again after
reaching 100%.
Change-Id: Ia8395d6ca28ab000e12fb7a43f13721c7959e35d
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/748971
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add support the ITE IT5205 Type-C USB alternate mode mux.
BRANCH=none
BUG=none
TEST=1. Successfully verify chip ID.
2. Verify set_mux() and get_mux() functions set and return
consistent values.
3. The mux control register setting as expected after set_mux().
Change-Id: I9ff066dc9e74683df1371b70290e2aeaa86cb96b
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/741211
Reviewed-by: Shawn N <shawnn@chromium.org>
power_board_handle_host_sleep_event was added to allow boards like
poppy to enable/disable PMIC VR decay only once during S0ix
entry/exit. Now that the chipset hooks have been fixed, there is no
need of this board specific callback. If in the future, there is a
need to have such a callback, this change can be reverted.
BUG=None
BRANCH=None
TEST=make -j buildall
Change-Id: I1d60e43da6c0d462132593efa26bc52312b81786
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/745982
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Now that chipset suspend/resume hooks are called only once per S0ix
entry/exit, move the calls to enable/disable PMIC VR decay to
suspend/resume hooks.
BUG=None
BRANCH=None
TEST=Verified that PMIC VR decay enable/disable are called only once
during one S0ix entry/exit.
Change-Id: Ie01c083963efeacaf0092927f5778b7c1cebf74f
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/745981
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Bump up port80 buffer size to 256.
BUG=None
BRANCH=None
TEST=Verified that all port80 messages from a boot-up or S3 resume are
present in port80 history buffer.
Change-Id: I76c95f308eaa30cc3789b93e59235a2dac0f632f
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/747121
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The default behavior for this state is the charge color for 1 second
and then off for 3 seconds. The existing table entry for this state
was incorrect.
BUG=b:67759004
BRANCH=none
TEST=Verfied that in S3 state the pattern is 1 second charging color
followed by 3 seconds off.
Change-Id: I838cdb34a23cd9224761bd7f16a3a1d9cb980fd6
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/741076
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
1. Add a new config option to define history buffer length. This
allows boards to override this option if required.
2. Get rid of unused PORT80_POLL_PERIOD macro
BUG=None
BRANCH=None
TEST=Verified that all port80 messages from a boot-up or S3 resume are
present in port80 history buffer.
Change-Id: Ie64680459f58358713a1b1445a0b99fcfe1c1cdc
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/745902
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of using HOST_SLEEP_EVENT_S0IX_RESUME as a reset state to
reinitialize S0ix flag, add a new default state
HOST_SLEEP_EVENT_DEFAULT_RESET. This also allows different parts of
the code to take correct action depending upon the state that is
currently triggered.
BUG=None
BRANCH=None
TEST=Verified that SLP_S0# interrupt doesn't get asserted during
runtime S0ix.
Change-Id: Id6fc8f3b015561d2899a9d39796b77a11a57e758
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/745901
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a common hook handler on CHIPSET_RESUME to log port80 resume
message instead of duplicating the same code in all chip lpc_resume.
BUG=b:68669668
BRANCH=None
TEST=Verified that port80 resume is logged on S0ix and S3 resume.
Change-Id: I313692f5499717d0d8f62be2ba3b8566c46e4dde
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/745362
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a new LPC helper routine lpc_resume_clear_masks that can be used
to clear SCI, SMI and wake masks upon resume from S3. This is done to
mask the events until host explicitly unmasks them.
It also ensures that these masks do not get reset on resume from S0ix
where the host does not re-configure these masks.
BUG=b:68669668
BRANCH=None
TEST=Verified following:
1. make -j buildall
2. On resume from S0ix, SCI mask is not reset.
3. On resume from S3, SCI mask is reset and then set again by host request.
Change-Id: I17a86bd60ef066b3716fb79ecce62f311eb45509
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/745533
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
