This fixes two bugs:
- The row order on the slave is reversed
- The last value is missed when transferring data to the master
BUG=None
TEST=Build and check the heatmap
BRANCH=None
Change-Id: Ic51ad1132d948ec6ec68dc673288ec6f29c6ebe7
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200621
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Since stm32l has smaller flash size, undef CONFIG_CONSOLE_CMDHELP to
remove short descripton to save 2560 byes.
If you need to read the description, grep that in the code.
BUG=chromium:374575
BRANCH=tot,nyan
TEST=buildall and
% grep hey build/big/ec.RO.map
0x000000000000ef48
After shrink -->
0x000000000000e548
Change-Id: I856e89def6456607ade610134bf318d8522f5e4d
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200472
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
CL manages various dut-control dependencies for readying the STM32
part for programming.
Additionally deprecated the short-lived --uart_prefix argument as
user's defining this could be problematic without knowledge of
necessary modifications to h/w & s/w.
Signed-off-by: Todd Broch <tbroch@chromium.org>
CQ-DEPEND=CL:200146
BRANCH=none
BUG=chrome-os-partner:28826
TEST=manual,
util/flash_ec --board=samus_pd succeeds.
util/flash_ec --board=spring succeeds.
Change-Id: I7627c77293da187700aeddf7382dbb12e163a2ef
Reviewed-on: https://chromium-review.googlesource.com/200148
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
There are CrOS devices that have multiple embedded controllers and
therefore multiple uarts that can be used for programming.
This CL allows user to set the uart_prefix to access the alternate
uarts via the --uart_prefix argument. Default is still 'ec'.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28826
TEST=util/flash_ec --board=samus_pd --uart_prefix=usbpd
Change-Id: I9fbe8d13067b7f514447645b2587dda706445661
Reviewed-on: https://chromium-review.googlesource.com/199900
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
A single frame of the scanned heat map is too big to fit into RAM. Let's
encode it so that we can get the whole frame.
BUG=None
TEST=Touch on various places on the panel and see corresponding results.
BRANCH=None
Change-Id: I8c7c72d5d4a83ebc2018c0abd57075697c931bef
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199940
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Fix bug to get PD transmit working. Fix config bug
for reading the CC ADCs.
BUG=chrome-os-partner:28350
BRANCH=none
TEST=connect fruitpie and samus via USB-C and run
pd dev on samus and pd charger on fruitpie.
Change-Id: Ic981a1f1e621ef4b69dedc61a02751346274aa4e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200159
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When the supply output is enabled, ensure that we detect quickly any
over-current situation by setting an analog watchdog in continuous
conversion mode.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28331
TEST=plug an electronic load to Zinger and see the OCP triggered
quickly when we go above the current threshold.
Change-Id: I7da50ef242addbd2f4f48f624494daa321ac22b2
Reviewed-on: https://chromium-review.googlesource.com/199924
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Allow flashing the RW firmware by sending Vendor-Defined Messages over
the USB-PD link.
This is not the secure update whose design is still under discussion,
it's a simple update with integrity check.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28330
TEST=using the following CLs,
./util/flash_pd.py ./build/zinger/ec.RW.flat
and see Zinger booting on RW, repeat the operations with different
builds of the RW firmware.
Change-Id: Icd90eb92f7321ccd66341a50b9dabd73c59c68c1
Reviewed-on: https://chromium-review.googlesource.com/197948
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Imported code from VBoot firmware cryptolib and slightly reformat it for
the EC code base.
We already have SHA-256, but for updates over PD, the maximum payload
size is 192 bits, so SHA-1 seems a better trade-off.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28336
TEST=none
Change-Id: I6da7b71a9af03c6689accfa3c59cfcf7776fcfc6
Reviewed-on: https://chromium-review.googlesource.com/199553
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Enable clock to syscfg in order to write DMA remapping
registers in pre_init().
BUG=chrome-os-partner:28350
BRANCH=none
TEST=test on a samus board.
Change-Id: I71b7f9b2bdc45f138f404997ccde65f54a1125d0
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200039
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is useful for testing battery charge profiles. When enabled, a dump of
all battery, charger, and charge state information will be printed whenever
the battery charge percentage changes.
BUG=none
BRANCH=ToT
TEST=make buildall -j
On the EC console:
chg debug on
then watch the console while either charging or discharging the battery.
Disable with
chg debug off
Change-Id: I6725c461461f90fcd812873f97490e980ab47bc6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199816
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This adds an "extra/" directory to hold various experiments and optional
programs. With this change, we add a tool that can simulate the lightbar
behavior on the build machine. That can be used to experment with variations
in the lightbar pattern code without needing to reflash a Pixel with a new
EC to see the effect.
There is no functional change to the EC code, just a couple of #ifdefs to
allow common/lightbar.c to be compiled separately from the EC.
BUG=none
BRANCH=ToT
TEST=make buildall -j
cd extra
make
./lightbar
You may need to install the libxcb1-dev package on your build machine.
Change-Id: I847ce7ea97cae792b1de1b91f488819e873b6555
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199883
This puts the code that talks to the lightbar hardware in one file, and the
code that implements the pretty patterns and behavior into another. This
will let us make improvements or changes to the patterns without requiring
detailed knowledge of the controller chips.
BUG=chrome-os-partner:28596
BRANCH=ToT
TEST=make buildall -j
Refactoring only. There is no new functionality.
Change-Id: I4e5fe8943385ddeab26bbd7e66c20e2dccd3dc43
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199882
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds three new lightbar subcommands to the EC_CMD_LIGHTBAR_CMD host
command, allowing the AP to read the current brightness level, the
current lightbar LED values, and the state of demo mode.
Because this is new, also update LIGHTBAR_IMPLEMENTATION_VERSION. All the
previous commands are unchanged, though.
BUG=chrome-os-partner:28596
BRANCH=ToT
TEST=manual
From the AP, run these commands to see the changes:
ectool version
ectool lightbar brightness
ectool lightbar 0
ectool lightbar 1
ectool lightbar 2
ectool lightbar 3
ectool lightbar demo
The version output is different, the other commands used to just emit
errors.
Change-Id: If32a5d2388217edc3ae7b9b091d66e9d2cf753be
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199881
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add PD MCU interrupt signal to gpio list, currently with a dummy
interrupt function which prints a message to let us know it is
occuring.
BUG=chrome-os-partner:28721
BRANCH=none
TEST=none
Change-Id: I1fab016b84b1abaced905e0ea0bd35dbd67b30bb
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199792
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Typically bq24xxx charging chip limits input current to minimum of
register value and ILIM pin. For fruitpie, the current limit will
be decided solely in software, and the hardware pin will be ignored.
BUG=chrome-os-partner:28611,chrome-os-partner:28311
BRANCH=none
TEST=Tested on fruitpie. Verified that current limit can be set
above the ILIM pin value of 500mA.
Change-Id: Ia687446f95f9d18fde9d2b4ebb0e1c093aebf885
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198940
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Ignore ILIM pin for charging which allows EC to set the input
current limit to anything it desires. This is necessary for
1.9 build because the hardware sets the ILIM to something
like 0.5A.
BUG=chrome-os-partner:28611
BRANCH=none
TEST=none
CQ-DEPEND=CL:198940
Change-Id: I43c57d0040e341e091ee36c97ec601d6bd174606
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199661
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
As per hardware team request, use a higher over-current limit to avoid
false positives due to measurement precision margin.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28331
TEST=use a Zinger connected to an electronic load and trigger the
protection.
Change-Id: If031f6f58b9b7119c6fa3fa3273c08f16cbbbebb
Reviewed-on: https://chromium-review.googlesource.com/199552
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Nothing looks at this except for an EC console command, so leave it at unity
gain until we've confirmed that it's working correctly.
BUG=chrome-os-partner:28721
BRANCH=ToT
TEST=make buildall
Change-Id: I81085743535f4664ac8bf1d016bb7562046ab49b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199243
Reviewed-by: Alec Berg <alecaberg@chromium.org>
There's a constant defined in board/samus/board.h that's only used in
board/samus/panel.c. Let's just put it in that file, so it doesn't clutter
up the config.
BUG=chrome-os-partner:28721
BRANCH=ToT
TEST=make buildall
Change-Id: I23d61aff16726a11a0408957cd109b49c3bf954c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199241
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Previously I neglected to increment the buffer pointer which would
allow double writing of same data and exclude tail if write didn't
complete in one call.
Also fixing bug with EAGAIN/EWOULDBLOCK to retry in those cases.
Previously we'd just have just failed for those errno values.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=none
BUG=chromium:371147
TEST=still compiles
Change-Id: I30dbe56b2a4c735c487464349786a9db430130a8
Reviewed-on: https://chromium-review.googlesource.com/199052
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
The auto_power_on is set 1 unexpectedly while EC jumps. This has a
side effect that would turn on the AP unexpectedly after "power off".
See comment 43 of issue 28249
BUG=chrome-os-partner:28249
BRANCH=tot,nyan
TEST=on nyan:
> reboot
> sysinfo
// If EC is in RO, "sysjump RW"
> power off
// The AP keeps off.
Change-Id: I3c06e99383c06af7cd6c17dd65040e20f06d8e73
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198941
This is a follow-up for CL 197990 and 197991. See issue tracker for
more details.
BUG=chrome-os-partner:28289
BRANCH=tot,nyan
TEST=Copy from https://chromium-review.googlesource.com/#/c/197990
Going battery shipmode and plug-in AC, See booting and expect EC log:
"[... battery initialized]"
Disconnect battery, and plug-in and see booting and expect EC log:
"[... battery not responding]"
Change-Id: Ic218414c21057a971b478ec60e406f1eb69dd379
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198412
FAFT expects the "AP running" shows first, then "XPSHOLD seen".
BUG=chrome-os-partner:28316
BRANCH=tot,nyan
TEST=build only
Change-Id: Ic3e9d68b7727d62d3ccc2c037e7547f0276c2eae
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198766
Reviewed-by: David Hendricks <dhendrix@chromium.org>
If we follow the TEST steps below, the power state machine in AP
and EC were out of sync -- due to the un-clear bit and wrong
initial power state.
BUG=chrome-os-partner:24835
BRANCH=tot,nyan
TEST=on big.
> reboot
> power off // De-assert XPSHOLD
> reboot ap-off
> sysinfo // This reset flags does NOT contain "ap-off".
> power on
% ectool reboot_ec RW // The following message is NOT observed.
// "system is on, but RESET_FLAG_AP_OFF is on".
> power // This should show the AP is "on".
// ensure everything still works.
> reboot ap-off // AP keeps off.
> reboot // AP is on.
Change-Id: I51afed7201d16ebcd889ad12a7af90026591cc2d
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198587
Reviewed-by: David Hendricks <dhendrix@chromium.org>
If we sysjump to EC-RW, that sets enabled=0. enabled is only set back
to 1 when the chipset resumes. But on an AP-requested sysjump, the
chipset is already on, and so the resume hook never gets called.
So, in spi init, check if the AP is already on. If it is, enable spi
transfers right away.
This probably also affects Pit/Pi. That may need an additional fix in
power/gaia.c, if it returns an incorrect chipset state after a sysjump
(I didn't test that.)
BUG=chrome-os-partner:28249
BRANCH=nyan,pit
TEST=Power+Refresh boot system with RONormal disabled, so that the AP
tells the EC to jump to EC-RW. Confirm EC communication still works
after that.
Change-Id: I588ef6d841040cf05d5527f645f122d5708b16ad
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198869
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Yung-chieh Lo <yjlou@chromium.org>
Tested-by: Yung-chieh Lo <yjlou@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The power_request variable is not clear in apshutdown case. Thus,
the AP comes up again by the "power up" request. Clear this variable
only when apshutdown command to avoid affecting the regular power
states.
BUG=chrome-os-partner:28621
BRANCH=tot,nyan
TEST=see below
> reboot // or other methods to turn on the AP.
> power on
> apshutdown
// The AP should remain off.
Change-Id: Icfc8a50db95aba656168f5b10dabd9443d75338d
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198770
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Some battery uses clock stretching feature, and this could disturb
PMU communication before battery going stable.
AP does not know and will attempt PMU setting, and could get fail
For various battery indicates usually 1s for stable
(even if it is much less in real world 200ms~700ms)
Let's checking 'battery is ready' when first pump-up power.
BUG=chrome-os-partner:28289
TEST=Going battery shipmode and plug-in AC, See booting and EC log
Disconnect battery, and plug-in and see booting and EC log
Change-Id: I9b62266132d5322366265afe03adbe0db1f9ae75
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/197991
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Some battery uses clock stretching feature, and this could disturb
PMU communication before battery going stable.
AP does not know and will attempt PMU setting, and could get fail
For various battery indicates usually 1s for stable
(even if it is much less in real world 200ms~700ms)
Let's checking 'battery is ready' when first pump-up power.
BRANCH=ToT
BUG=chrome-os-partner:28289
TEST=Going battery shipmode and plug-in AC, See booting and EC log
Disconnect battery, and plug-in and see booting and EC log
Change-Id: Idd8ae2ab4ec164b11fe67413bbf647cad18bc481
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/197990
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
While debugging reboot issue, it was difficult to get POST code from failing
boards. Currently POST code is only accessible from EC console. Not all boards
are fitted with servo board.
This patch adds Port 80 history access from ectool. Reuse command code 0x48,
EC_CMD_PORT80_LAST_BOOT with version 1.
Signed-off-by: Wenkai Du <wenkai.du@intel.com>
BUG=chrome-os-partner:28514
BRANCH=rambi
TEST=manually test on rambi to confirm port 80 history match EC console
Change-Id: If204d8fb457d8d8d18055f8282a406a35c03305e
Reviewed-on: https://chromium-review.googlesource.com/198012
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Wenkai Du <wenkai.du@intel.com>
Commit-Queue: Wenkai Du <wenkai.du@intel.com>
Tested-by: Wenkai Du <wenkai.du@intel.com>
This may not contain all. I filtered out possible code by the
following command:
find . -name "*.h*" -o -name "*.c*" | xargs grep -n CPRINTF | \
grep -v "\[" | grep -v define | less
BUG=none
BRANCH=none
TEST=make buildall tuntests
Change-Id: I674f84f5966b34aeb8d4321d22629b450627a120
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197997
The electrical design has changed :
the output enable GPIO (PF0) has switched from being the LM5050 shutdown
pin to controlling directly the FET enabling. We need to invert the
control logic and use it in push-pull mode rather than open-drain.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28332
TEST=plug a reworked Zinger to a firefly and check the firefly LED is
displaying a solid ON (meaning the voltage is right).
Change-Id: Iee79b07f49eade1fee7cac1986bc38ba21e04b25
Reviewed-on: https://chromium-review.googlesource.com/198240
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
ensure that the board will get power from VBUS by default, so it can
start-up if it's own battery is fully drained.
Also increase the console stack as the battery code footprint is growing
over time.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28311
TEST=plug a Fruitpie without battery to a Zinger.
Change-Id: I971040da9bedb7bf46363787a13220c39a78100d
Reviewed-on: https://chromium-review.googlesource.com/198557
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
We found some cases where the battery can flip out and get confused
and hold the i2c lines. Since the battery is actually smbus it will
give up after 25ms. Increase our timeout to 30ms so that the next
trasaction will work OK.
BRANCH=ToT
BUG=chrome-os-partner:28425
TEST=Revert (1cd618e Wait for battery boot-up) and use a problematic
battery; see boot works OK.
Change-Id: Ife051220cbbbd49d7bc9c8607ba177cd9582fe58
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198212
Reviewed-by: Randall Spangler <rspangler@chromium.org>
See issue tracker for details.
BUG=chrome-os-partner:28518
BRANCH=tot,nyan
TEST=on big
% reboot ap-off
% powerbtn
[6.100943 power on 4]
Was power on 1 before fix.
% reboot
[0.098134 power on 2]
Was power on 1 before fix.
Change-Id: I7b2fd95234d16467edca041b1c12d63ca4b5112b
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198070
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Detect over-current and over-voltage and trigger a fault.
The over-current threshold is 10% over 3A (3.3A).
Only currently implement the slow protection,
the fast interrupt-based one will be done later.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28331
TEST=with Zinger connected to an electronic load, adjust the current to
3.35A and see the output voltage cut.
Change-Id: I0e848192392fd73f0839d4bcb806528b2a6b9122
Reviewed-on: https://chromium-review.googlesource.com/197947
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
XPSHOLD is not always removed after chipset_force_shutdown(). This is
different to the GAIA design. So, check the RESET_FLAG_AP_OFF flag
again while check_for_power_on_event().
BUG=chrome-os-partner:28371
BRANCH=tot,nyan
TEST=verify on big.
re-flash ec: power on 2, AP is up.
AP is on, reboot@EC: power on 1, AP is up.
AP is off, reboot@EC: power on 2, AP is up.
AP is on, reboot ap-off@EC: AP keeps off (see FLAG_AP_OFF flag)
AP is off, reboot ap-off@EC: AP keeps off (see FLAG_AP_OFF flag)
reboot ap-off@EC, then 'powerbtn': AP is off at boot, then power on 4
reboot@EC: power on 2, AP is up.
re-plug AC (remove battery): power on 2
re-plug battery (without AC): power on 2 (but my battery is dead)
power off (S5), power on: power off 4, power on 5
power off (G3), power on: power off 4, power on 5
lid close / power off (S5)/ lid open: power on 3
lid close / power off (G3)/ lid open: power on 3
press power button and release: nothing happens after 15s. AP keeps in S5.
button off (S5)/ on: power off 3, power on 4
button off (G3)/ on: power off 3, power on 4
power off (S5)/ button on: power off 4, power on 4
power off (G3)/ button on: power off 4, power on 4
button off (S5)/ power on: power off 3, power on 5
button off (G3)/ power on: power off 3, power on 4
button off (S5)/ lid open: power off 3, power on 3
button off (G3)/ lid open: power off 3, power on 3
is off, long press button (60s): power on 4, too long, shutdown, stay off
is on, long press button (60s): power off 3, stay off
AP is on, apreset cold: entered to S5, power off 3, power on 5
AP is on, apreset warm: power state is not changed, but reboots to BIOS
Change-Id: I9ccd13ab4b5f38be1ad8d6c9a04724b56bc5b166
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197604
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Since we already created the firmware-nyan-5771.B branch, we can
remove this from ToT now. But for sure we are still able to
cherry-pick changes back to ToT or from ToT.
BUG=none
BRANCH=tot
TEST=make buildall
Change-Id: I637d27b9f8672c5d17b60e210a5211ab8e19b54a
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197165
Ensure that we finish reception if and only if we started it
whatever other events happened.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28332
TEST=Connect Zinger to Firefly, request higher voltage and ensure that
Firefly was still getting the Pings after several hours.
Change-Id: Ie99984aeb4c565be39d349457dbd2813203b3f5b
Reviewed-on: https://chromium-review.googlesource.com/197946
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Ensure that the power sink as expected by the standard or
times out if nothing happens.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28332
TEST=connect Firefly to Zinger and transition between voltages using
Firefly buttons.
Change-Id: I99e482982e4788a52bc2c1a57d672c3d71ff22e2
Reviewed-on: https://chromium-review.googlesource.com/197052
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
