Our pericom charge detectors can reset themselves on rapid charger plug
/ unplug, which resets the interrupt enable to the power-on default
(off). Work around this problem by re-enabling pericom interrupts from
the VBUS interrupt.
BUG=chrome-os-partner:33823
TEST=Manual on samus. Rapidly plug + unplug charger, verify that Pericom
continues to trigger interrupts.
BRANCH=Samus
Change-Id: I7370525e28c59bdde3765e52523d5158d1d6175d
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231700
Reviewed-by: Alec Berg <alecaberg@chromium.org>
A non-zero error code returned by the callback causes EP0 to STALL.
This is the common mechanism used in USB to indicate an error while
processing a control request. This simplifies the implementation
of interface callbacks.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I89ceb4892f9f810fcaf6e975e6982fc5b2ae447b
Reviewed-on: https://chromium-review.googlesource.com/232368
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
For accessories without software-sync mechanism, add the option to do a
RSA-based signature verification of the Read-Write firmware.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:31192
TEST=enable the configuration on Fruitpie and see the RW firmware
validated and jump to. Tried with good and bad RW images.
Change-Id: I3c886c2cbe17ca9543e19bf8599061c3f9751d4f
Reviewed-on: https://chromium-review.googlesource.com/229594
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
CL adds sleep to USB-PD flashing loop in ectool. Real problem is
likely busy waiting within the host command master in the EC which
causes it to starve other lower priority tasks there.
Additionally,
1. Sleep 100ms after reboot to attempt to avoid colliding with other
USB-PD traffic communication that happens when accessories boot.
2. Sleep 100ms after last flash write prior to reboot as there's some
race between finalizing flash write.
Workaround should be removed once we've identified root cause.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33905
TEST=manual,
1. attach zinger to port 1 of samus
2. create ec.RW.bin for zinger and copy to samus
3. update RW fw on zinger via:
ectool --name cros_pd flash_pd 1 1 ec.RW.bin
Result:
- No longer see watchdog fire on samus EC
- See successful update of RW fw on zinger. Takes ~15secs.
Change-Id: If617cbf1c25ee92de94bdb312ec822af2a688640
Reviewed-on: https://chromium-review.googlesource.com/230845
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
We still need to decide which direction to use. Refer to the bug
for details & discussion.
BUG=chrome-os-partner:32227
BRANCH=ToT,samus
TEST=make buildall -j
From the EC console, use
lightbar seq tap 0
lightbar seq tap 1
If you don't give the third arg, it just uses the previous direction.
Change-Id: I3a6566e8ba18d392f8d9d3419745a5377d22db25
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231893
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When other tasks call lightbar_sequence() to indicate power state
changes, a single-bit event is delivered to the lightbar task and
the requested sequence is saved in a variable. This is
intentional, because we want the lightbar to run only the most
recently requested sequence.
Of course this means there's a small race condition, which caused
occasional problems. This change reduces the window for problems,
by making a copy of the requested sequence immediately after the
event is delivered (rather than after printing a bunch of stuff),
and then having the current sequence function return that new
sequence back to the lightbar_task() main loop.
While we're at it, the transitional sequences (S5S3, etc.) can
just return their next sequence directly instead of letting that
decision be made in the lightbar_task() loop.
BUG=chrome-os-partner:33401
BRANCH=ToT,samus
TEST=make buildall -j
Power on/off, reboot, open & close the lid, double-tap, etc.
Watch the lightbar the whole time. It should do the right thing.
Change-Id: Icbe96194e523ef4d85d2643ec14675cf5c893dc0
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231881
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When another task is holding the lock, mutex_lock() should call
task_wait_event_mask() to wait only for TASK_EVENT_MUTEX events.
If it calls task_wait_event(), any pending events are silently
discarded while its waiting for the the lock.
BUG=chromium:435611
BRANCH=ToT,samus
TEST=make buildall -j, and:
Before this change, I watched the EC console while shutting down
and rebooting Samus. I saw the request event arrive:
[37.576295 LB lightbar_resume() requests 5 S3S0]
[46.055725 LB_version]
But the lightbar task never saw it. Adding a bunch of debug
messages showed that it was being lost in mutex_lock().
After this change, the event is delivered:
[30.167670 LB lightbar_resume() requests 5 S3S0]
[30.171009 LB cur_seq 2 S3 returned pending msg 5 S3S0]
[30.173816 LB running cur_seq 5 S3S0. prev_seq 2 S3]
[32.410073 LB cur_seq 5 S3S0 returned value 0]
[32.410865 LB running cur_seq 3 S0. prev_seq 2 S3]
[39.938388 LB_version]
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I011838538960cc57171f0a3c4cdee113d156e9ff
Reviewed-on: https://chromium-review.googlesource.com/231370
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add active charge port for the PD status exchange so that EC
knows which port we are currently charging from.
BUG=chromo-os-partner:32227
BRANCH=samus
TEST=load onto samus. use "pdcmd 0x100 0 0"
from EC console to read the active charge port and
verify that it matches which port we are charging from.
Change-Id: I419befef8f0a14ca2da237be1a4944fd08733b83
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231349
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Fix bug where if a power swap fails in the final stages, it
will have switched its CC resistor, but will not have actually
switched roles, which causes all sorts of weirdness.
BUG=none
BRANCH=samus
TEST=make buildall. tested power swap between two samus'. modified
one samus to never send PS_RDY when in PD_STATE_SNK_SWAP_COMPLETE,
and verified that when source asks for power swap and fails, that
it properly resets CC to pull-up.
Change-Id: If0fc8d3d51ede3be1160ae3b106061edabeaa948
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231193
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
In sink hard reset recovery, when VBUS finally goes high, go
to SNK_DISCOVERY quickly so that we can set our SINK_WAIT_CAP
timer.
BUG=none
BRANCH=samus
TEST=tested with zinger. when samus sends hard reset, it goes
to SNK_DISCOVERY quickly after VBUS goes high.
Change-Id: Ie5b3ed95ea9e0c405861be71bd694b057de289d0
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231397
Reviewed-by: Vincent Palatin <vpalatin@google.com>
Remove host_event_commands.c from build to save flash space. The
PD MCU does not use host event infrastructure and instead has a
simple gpio line it uses to notify EC that it has info to share.
BUG=none
BRANCH=samus
TEST=make buildall. view the .map file and see we save about 700
bytes of flash.
Change-Id: I71b8a4e32b9ecb57eb1a57f6d28652476ee6afe6
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231444
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Change zinger/minimuffin product type from AMA to
undefined.
BUG=none
BRANCH=samus
TEST=make buildall. load onto zinger, plug in samus, see:
SVDM/4 [1] ff008041 040018d1 00000000 50120001
[19.163111 DONE]
Verify ID header, 2nd word, bits 27-29 are product type,
where 0 is undefined.
Also verify that product VDO is present, 4th word.
Change-Id: I34a70d9356b5a8ee7ad64a4e8f072d7748aa916e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231172
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Remove dualrole power capable flag from source/sink cap packets
so that samus/ryu default to drawing power from plankton.
BUG=none
BRANCH=samus
TEST=load on plankton. select 20V to DUT, attach samus or ryu
and see that it charges
Change-Id: I3d31b14f65ee8dfa4d817d47598c505b0f6d7479
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231342
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
For P3, we'll use PI3USB9281A, which fixes the I2C clock problem. Let's
remove the workaround and leave the clock enabled all the time.
BRANCH=Ryu
BUG=chrome-os-partner:31526
TEST=Boot on Ryu
Signed-off-by: Vic Yang <victoryang@chromium.org>
Change-Id: I05a3ebbff82282b69e3c5573608e500a34d370c0
Reviewed-on: https://chromium-review.googlesource.com/231180
Reviewed-by: Alec Berg <alecaberg@chromium.org>
I need more information to find the source of some problems. This
just adds a little more context to the lightbar console messages.
BUG=chrome-os-partner:33401
BRANCH=ToT,samus
TEST=make buildall -j
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I97a210754833c9384eae517f9df2e97d3a9ea6b4
Reviewed-on: https://chromium-review.googlesource.com/231136
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Added new hard reset recovery states for sink and source state machines
and transition there on hard reset. This is necessary because on a hard
reset we are not supposed to turn off vconn, nor disconnect USB, nor
switch the data role. In other words hard reset is not the same as a
disconnect.
This also changes timing around when to send source cap after a hard
reset and when to expect source cap after hard reset.
This also adds a delay between sending hard reset and executing it to
give time for sink to recognize the hard reset as differentiated from
a disconnect when VBUS goes down.
For sink, when a hard reset is issued or received, sink waits for VBUS
to go away, then for VBUS to come back, and then starts the sink wait
cap timer.
BUG=none
BRANCH=samus
TEST=make buildall
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Change-Id: Icb6ceaf242cebfcf8d08d7317976f83286a256ff
Reviewed-on: https://chromium-review.googlesource.com/228111
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Without a PD contract, regularly monitor CC line voltage to determine
if CC pull-up has changed its current advertisement.
BUG=chrome-os-partner:33682
BRANCH=samus
TEST=test with donette prototype: plug in one donette port to a samus,
see it set current limit to 3A, then plug in another port to a different
samus and see the first samus lower the current limit to 1.5A.
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Change-Id: I965ab5fde7a67025f3f7ea34eb86fa35187080a6
Reviewed-on: https://chromium-review.googlesource.com/230594
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
If our request is rejected, go to SNK_READY, but don't set
explicit contract flag.
This also changes charge manager slightly to avoid new power
request loops. A new power request is only requested if the
charge port changes, or if the active charge port changes its
voltage/current offering. A new power request does not occur
if the current ceiling changes, since the existing contract
still suffices.
BUG=chrome-os-partner:33692, chrome-os-partner:28332
BRANCH=samus
TEST=make buildall. use samus and make sure we negotiate for 20V
as normal. modify zinger to send a REJECT and make sure we go from
PD_STATE_SNK_REQUESTED to PD_STATE_SNK_READY and explicit contract
bit is 0.
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Change-Id: Iec02663364dcdc4aa66c681ec08911db7424abbc
Reviewed-on: https://chromium-review.googlesource.com/230522
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add tSenderResponse timeout to waiting for response from a request
message. If timeout triggers, send hard reset.
BUG=chrome-os-partner:33687
BRANCH=samus
TEST=test with zinger that we can negotiate normally. then modify
zinger code to not send any response when it receives a request and
see that samus sends hard reset from PD_STATE_SNK_REQUESTED.
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Change-Id: If147d809cfe185ec714e292a4814fbbfb50af04b
Reviewed-on: https://chromium-review.googlesource.com/230521
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add flag for whether or not a type-C port is in an explicit
contract. This flag will be used in the future to determine if
VDMs can be sent.
BUG=chrome-os-partner:33861
BRANCH=samus
TEST=load onto samus. plug in to zinger, use pd 1 state to verify
explicit contract bit is set. plug in to another samus, issue a power
swap, see contract bit go away and come back when contract is
established.
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Change-Id: I9404e7cc920ebe0b37d9efae758436cc6aa7be85
Reviewed-on: https://chromium-review.googlesource.com/230520
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When using gpio_set_flags_by_mask() to modify a GPIO pin setting, the
former code was not able to revert an open-drain GPIO into push-pull
mode (the other way round was working). Fix it to be able to transition
in each direction.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=all
BUG=none
TEST=on Twinkie, run "tw res none RP3A0" then "adc" and see the RP3A0
GPIO set to 1 and pulling the CC to 3.3V.
Change-Id: Ic2d8ed95ea21b21d261a12ba298931d8bd5e6919
Reviewed-on: https://chromium-review.googlesource.com/231150
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Ensure that the PD source changes the output voltage after
tSnkTransition delay after having sent the ACCEPT message
(rather than before).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33684
TEST=connect Zinger to a PD power sink and monitor VBUS and CC while
doing a 20V to 5V transition.
Change-Id: If86f59eec67630491f4e8dc13a52015ac2de918a
Reviewed-on: https://chromium-review.googlesource.com/230805
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
The latest gcc picked up a couple out-of-bounds issues, so
"make buildall" was failing. This fixes them.
BUG=none
BRANCH=ToT
TEST=make buildall -j
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Idcd6a3358ecbb0e0d2a610e1cd28c2f138ce520b
Reviewed-on: https://chromium-review.googlesource.com/231156
Reviewed-by: Randall Spangler <rspangler@chromium.org>
For USB console, we wait for USB host to grab the data before writing
the next chunk of characters. However, if the USB peripheral is
disabled, the current implementation is confused as to whether the host
has grabbed the previous chunk of data.
Fix this by explicitly checking for USB peripheral enabled.
BRANCH=ryu
BUG=None
TEST=Boot on Ryu and check console isn't slow.
Signed-off-by: Vic Yang <victoryang@chromium.org>
Change-Id: I438c95835e56707b7ca1796734f2e47062799f44
Reviewed-on: https://chromium-review.googlesource.com/231115
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If USB hub is connected to the type-C port, we need to reset the hub
whenever a cable plugs in. Otherwise, USB3.0 may fail to enumerate.
BRANCH=None
BUG=None
TEST=Plug/unplug cable and measure hub reset signal.
Change-Id: I60f67c83653d532971ee156914fe6ae0ecdb8d3a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229490
Reviewed-by: Pin-chih Lin <johnylin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
With this change, when we modify some config file related
to space, the lds is recompiled properly.
TEST=Check that when chip/stm32/configXX.h is modified,
ec.RO.lds is recompiled.
BRANCH=ToT
BUG=None
Change-Id: I0a49065e59f00dd37d945d9593126ab9fd1598b5
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/230908
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add host command to set charge port override.
BUG=chrome-os-partner:32003
BRANCH=Samus
TEST=Manual on Samus. Insert PD charger in port1 and BC1.2 charger in
port0.
./ectool --name=cros_pd chargeoverride 0 --> Charges from port 0
./ectool --name=cros_pd chargeoverride off --> Charges from port 1
./ectool --name=cros_pd chargeoverride dontcharge --> No charge port
./ectool --name=cros_pd chargeoverride 1 --> Charges from port 1
./ectool --name=cros_pd chargeoverride 2 --> Correctly returns error
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ib35f797a4a24e96fd2e3c008ace3fd6291b89d25
Reviewed-on: https://chromium-review.googlesource.com/230910
Reviewed-by: Alec Berg <alecaberg@chromium.org>
pd[port].timeout will be 0 immediate after set_state(), thus will cause
a negative value result for timeout calculation in the pd_task's ending
loop. This will cause task_wait_event to receive a negative timeout value.
Obviously it causes no harm to the current implementation, but should be
fixed by being paranoid.
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: Ib2817e1d95ca6c6eedcaff16a9e7e95033953901
Reviewed-on: https://chromium-review.googlesource.com/229760
Commit-Queue: Bernard Shyu <bernard_shyu@bizlinktech.com>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Bernard Shyu <bernard_shyu@bizlinktech.com>
The role of hoho & dingdong is UFP, and the corresponding protocol
fields in VDO (vdo_idh) should reflect it.
Fix error in IDH_PTYPE definitions of SVDM Identity Header, it's reversed
Adds more legible names to protocol field constants
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: Idac9327bf3e8e9597221654bce80bb311b3304af
Reviewed-on: https://chromium-review.googlesource.com/230657
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Bernard Shyu <bernard_shyu@bizlinktech.com>
Tested-by: Bernard Shyu <bernard_shyu@bizlinktech.com>
This is fairly large change set to accomodate a new hardware
release. There are enough differences to require refactoring the
registers.h file. Autogenerated constants are now in gc_regdefs.h
and all constant names begin with GC_, while register names are
defined in registers.h and begin with GR_.
Yes, I know the new header files are wider than 80 chars, but we
agreed that was okay in some cases if it makes them more readable
(see commit 3500c28).
BUG=chrome-os-partner:33423
BRANCH=none
TEST=make buildall -j
Build and run on the development board.
Change-Id: I21bd88c490f4f359ad17b5af9d17d8caca8dc9e4
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/230513
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Add commands to send PD packets and to tweak individual parameters (TX
clock frequency, RX detection threshold, resistors on CCx).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28337
TEST=verify that the PD sniffing is still working by dumping traffic
between Zinger and Samus.
Connect Twinkie to Zinger, set Rd by using "tw res NONE RD" and see VBUS
going to 5V (reading it using "ina 0").
Send a BIST mode 2 request using the following command :
tw send 2 0x1043 50000000
and see the other end starting sending BIST.
Change-Id: I3c8ddf858435ac1c17a43f59351bbaa69603a209
Reviewed-on: https://chromium-review.googlesource.com/227778
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Force enabling STOP mode when we have a power contract etablished but
the sink is consuming a low current (<500mA).
As a side effect, when the STOP mode is on, the fast OCP is no longer
reacting fast because the analog watchdog ADC conversion will only
happen on the next wake-up (dozens of milliseconds).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=run on Zinger with the UART RX used as debug GPIO to record STOP
mode entry/exit.
Change-Id: If78b2651862782cee45cfcdb22425b94f1eee678
Reviewed-on: https://chromium-review.googlesource.com/230341
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Extend the Zinger runtime to take into account the disable_sleep()
issued by the USB protocol stack and avoid going into deep-sleep while
connected.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=connect Zinger to a PD power sink (Twinkie) and monitor the stop
mode entry/exit on a GPIO.
Change-Id: I04e35fdd65f3be3da7a4304dc1a92e6268930888
Reviewed-on: https://chromium-review.googlesource.com/230340
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
For samus, use learn mode on BQ24773 to avoid the soft start that
causes backboosting on some boards.
BUG=chrome-os-partner:33644
BRANCH=samus
TEST=tested in EE lab on a board that was backboosting reliable.
this fixes backboosting at 5V, and also on 20V to 5V transitions.
Change-Id: I97c52a55ba07662d444e67bfbc9ca488b530f423
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229282
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Fix task_wait_event() so that it only wakes when an event is received
or on timeout. Currently it wakes up on any interrupt, which can cause
subtle timing issues with PD communication.
BUG=none
BRANCH=samus
TEST=load onto samus, see it negotiate for 20V a few times
Change-Id: Ia1268a1ac902433433949269d779ef11403eeae3
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226811
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
With this change we can use power event to configure sensors
and trigger motion detection in suspend.
BUG=chrome-os-partner:31071
BRANCH=ToT
TEST=Check power states. Check power up messages and commands are
present at the console.
Message at boot:
[0.007142 hash start 0x00010000 0x000096dd]
[0.007293 Inits done]
[0.007506 power state 2 = S3, in 0x0000]
[0.007765 power state 3 = S0, in 0x0000]
[0.007908 event set 0x00002000]
[0.008021 hostcmd init 0x2000]
[0.146870 hash done
f87d7824b439db923d270df016af5aabec51b73505b7c4faa6e40c16b12dd392]
Change-Id: I9c56fe5203506462f0820bbc8a5fe4528f6805ac
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226881
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
