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 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>
MOTIONSENSE_CMD_DUMP is deprecated, replaced with MOTIONSENSE_CMD_GET_DATA
Also use vector_3_t instead of x,y,z
ectool motionsense commands only work with newer firmware, to
handle a dynamic number of sensors.
- The host sends the number of sensor it has allocated space for.
- If 0, the EC just sends the number of sensors available
- Otherwise returns sensor information up to the limit imposed by the host.
Remove MOTIONSENSE_GET_STATUS: not needed. It is only useful for LPC,
to guarantee atomicity of the data.
Remove MOTIONSENSE_GET_DATA: not needed since we increase the version
number of MOTIONSENSE command.
BUG=chrome-os-partner:31071,chromium:430792
BRANCH=ToT
TEST=Compile. On a firmware that support the new command:
/usr/sbin/ectool --name=cros_sh motionsense
Motion sensing active
Sensor 0: 92 15 1030
Sensor 1: -94 -63 718
/usr/sbin/ectool --name=cros_sh motionsense active
0
On a machine with older firmware (samus), check these
functions are not working anymore.
Change-Id: I64b62afff96670fb93457760d43d4e64e26e029f
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226880
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Don't charge from dual-role capable ports, unless an override is set to
force charge. Also, if an override is set to charge from a dual-role
capable port and a dedicated charger is attached, remove the override.
BUG=chrome-os-partner:32003
TEST=Pass unit tests
BRANCH=Samus
Change-Id: I4e81e39a9f6ba325fa8a5e8f0d77fd5bfc7a672c
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229465
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Allow a charge port to be selected as the override port, which means it
will always be selected as the charge port, if any charge supplier is
available.
BUG=chrome-os-partner:32003
TEST=Attach PD charger and BC1.2 charger. Verify that active charge port
switches to BC1.2 after running `chargeoverride [port]` from console.
Also, pass unit tests.
BRANCH=Samus
Change-Id: Ia1b48ca89641842d51be7eed3b92d36d3eedc9ef
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227730
Reviewed-by: Alec Berg <alecaberg@chromium.org>
For request message, add the operational and max current for each
board. If the requested power is less than the operational power
required, then set mismatch bit.
BUG=none
BRANCH=samus
TEST=make buildall. load onto samus, plug in zinger and see
that request 20V, operational current 3000mA and max
current of 3000mA.
Change-Id: I4df45d88b7e060f66ff5b806f6fe30803f1afcf7
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227393
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Remove redundant 5V source PDOs in source cap packet. We only
need one 5V advertisement with the maximum current that we can
provide.
BUG=none
BRANCH=samus
TEST=make buildall
Change-Id: I94a01813787eb92fafbf600dcbbc8a2f0aa69e2b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227392
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Add support for PR_SWAP command as per PD specification.
BUG=chrome-os-partner:28343
BRANCH=samus
TEST=test by connecting two samus' and running 'pd 1 swap power'
from console. verified that both sides switch power roles by
observing console output. also tested against third party
devices.
Change-Id: I0e8738b544de9f9a4348250630e67d0fefb4486d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225559
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The fans on samus have a recommended minimum duty cycle of 20%
while running, but 30% in order to start. We've been using the
EC's built-in fan controller for the start requirement, but it
has a minimum fast-start duty cycle of 50%. It turns out that
that speed is noticeably noisy.
This change handles the startup with logic in the EC instead, so
that the fan only tries to spin at 30% initially (or if it drops
too much below the minimum turning speed).
BUG=chrome-os-partner:33429
BRANCH=ToT,samus
TEST=make buildall -j
Boot the system, let it idle with the browser windows closed, the
browse a bit, then idle. Listen for changes to the fans.
Before, I could hear the fans kick in and out as the AP load
changed. Now it's much quieter.
Change-Id: Id35215520c064eb6843686ec8bb5f3618dac6cf6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227658
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Split motion_sense.c.
Translate the accel data in the Android coordinate right away.
BUG=chrome-os-partner:32002
BRANCH=ToT
TEST=On samus, check lid angle are still correct.
Change-Id: If743e25245dc1ce4cdacb8a4d5af22616c4a79e4
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225486
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Design Goals:
1. Every time the AP boots, the same default sensor settings are configured.
2. If the AP goes to suspend (S3) and wakes back up (S0),
then the AP sensor settings will be restored.
3. In S3 and in S5, only sample specific sensors that are needed.
BUG=chrome-os-partner:32368
BRANCH=ToT
TEST=Verified on Samus.
Verified suspend and resume logic with EC console messages.
- Test Case0: close lid & open lid
- Test Case1: powerd_dbus_suspend
Change-Id: I553c53e63ecfcb39d5e649a7189aa6ea02589471
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220371
Reviewed-by: Alec Berg <alecaberg@chromium.org>
PULSE and TEST sequences are not used anywhere. Remove them to save
flash space. Also, fix msleep(MSEC) calls in the unit test; it's
essentially usleep(SECOND) written in an incorrect way.
BUG=chrome-os-partner:32203
TEST=make buildall
BRANCH=None
Change-Id: I61ba897df632538eb89364a4c913d5fee87f3864
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220711
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is mostly the same as previous commits, but with increased delay.
Previously, we have short delays (e.g. 3ms) which is too short and may
cause instability.
Now that we have slowed down the time when running unit tests and
increased the delay, this shouldn't cause problems anymore.
BUG=chrome-os-partner:31200
TEST=Repeatedly run multiple unit tests in parallel.
BRANCH=Samus
Change-Id: Ib55e3adc5fd27a8e233996b4799dab3cefd62318
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220734
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When a timing sensitive test run on a heavily loaded system, sometimes a
task runs for longer than it usually does and causes the test to fail.
All the timing requirements in the unit tests are trying to verify the
various delays in our codebase, and mostly we don't care about the time
taken by active running code (as they are very quick.) To improve the
stability of tests, let's slow down the time. To a test, it's as if the
code runs faster. If a test uses udelay() and exceeds the 10-second time
limit, we can make that single test faster by setting the time scale.
BUG=None
TEST=Repeatedly run 'make runtests'
BRANCH=None
Change-Id: I9bc5c77e0d34d04c8630d495387a751ef29c7bd5
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220717
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously there was no way to remove multiple units at a time
from the queue, and the queue was wasting an entry to disambiguate
full from empty. There was also no way to get the free entry
count from the queue, only the ability to query if it was above
a required amount. The queue was also storing its constant
compile time configuration as well as its dynamic state in the
same structure. This wasted RAM on configuration information
that doesn't change.
This refactor fixes these issues, making the queue suitable for
use in the new USART stream driver.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I284cee52d8189928dbc4c499f87ab34e14019e5a
Reviewed-on: https://chromium-review.googlesource.com/210533
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Changed motion_sense task to assume sensors are unpowered in G3
and re-initialize sensors every time coming out of G3.
Added EC command line test utils as well.
Fixed some bug during unit tests.
BUG=chrome-os-partner:27313,27320
BRANCH=ToT
TEST=Verified on Samus.
Tested with accel EC CLIs
accelread, accelrange, accelrate, accelres
Tested accelcalib, a ACCEL calibration util, and it succeeded.
Tested sysfs interface:
cd /sys/bus/iio/devices/iio:device1
cat in_accel_*_gyro_raw
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Change-Id: I5752b00c03e1942c790ea4f28610fda83fa2dcbc
Reviewed-on: https://chromium-review.googlesource.com/211484
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This module controls the inductive charging transmitter. For now, the
policy is to charge whenever possible.
BUG=chrome-os-partner:31392
TEST=Unit test passed
BRANCH=None
Change-Id: Ie48a38ad92fe2bc3329c4962e96572f2bc40b4e6
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212715
This CL ensures that temporary "one-shot" sequences such as KONAMI, TEST,
TAP, etc. will revert to the previous "normal" sequences even when
interrupted by other one-shot sequences.
This also adds a test for those cases.
BUG=chrome-os-partner:29873
BRANCH=ToT
TEST=manual
make runtests
Change-Id: Ie83908731acdf2f7c9108568a1ba047943175d26
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213230
Previously our accel / gyro drivers assumed that we had exactly two of
each identical part in the system. Some systems may have different
configurations, so allow this to be specified at the board-level.
Note that our motion_sense algorithm currently assumes that we have one
accelerometer in the lid and one in the base -- we'll need to fix that
in another CL.
BUG=chrome-os-partner:27320
TEST=Compile-only. Tested in future Samus commit.
BRANCH=None.
Change-Id: I1fae1f6c578fedebe78b473a5d66a5794ccaae00
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212321
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add back the test but only enable USB PD tasks for usb_pd test. This
should ensure that we do not break existing tests.
BUG=chrome-os-partner:31200,chromium:402335
TEST=make buildall
BRANCH=None
Change-Id: I4daa41a96a1067362b2c40a2a09fce733843bdff
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211923
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Initial commit of usb_pd unit test. The test cases are very simple.
We'll add more test cases in similar format.
BUG=chrome-os-partner:31200
TEST=Pass usb_pd test
BRANCH=None
Change-Id: I9e3de5b2c032ee1d3670cde6d8227ce0378ae8a0
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211643
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When emerging chromeos-ec for ryu the build blows up when doing
tests. Remove all tests for RYU so that we can start building the
EC code through the build system.
BUG=chrome-os-partner:30659
BRANCH=None
TEST=Can emerge-rush_ryu chromeos-ec
Change-Id: I293f2640891f42cfea0eb8aeb1ff1de603db9a93
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208063
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Fix motion_sense unit test flakiness by making sure that the lid
angle calculations ran by checking LPC sample id number instead of
relying on a fixed time delay.
BUG=chromium:391625
BRANCH=none
TEST=make -j runtests
Change-Id: I6e879ef28837e62e0c9d4e5f05e0165fa9f9a966
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206878
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This test checks:
- flash_is_erased() returns true when flash is erased.
- flash_is_erased() returns false when the entire flash except one
byte is erased.
BUG=chrome-os-partner:30281
TEST=Check this test fails without the fix for flash_is_erased(), but
passes with it.
BRANCH=all (if the fix is cherry-picked)
Change-Id: Id4fe5591381cabcdad9bb16ba820acd48e92ba13
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206897
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Some chargers support a timeout mechanism that it would stop charging
if no voltage/current setting comes from battery or EC. This is designed
for safety.
In charger v1, it always updates charger periodically. But in v2, old code
only updates charger when needed. New code updates the charger periodically.
Also keep the ability for debugging. A manual mode is introduced so that
any requested volt/curr from host and force idle mode request would trigger
this mode. To leave this mode, just disable the force idle mode.
BUG=chrome-os-partner:28201,chrome-os-partner:28208
BRANCH=nyan
TEST=See below.
Plug AC and battery. Wait for 10 mins and the battery is charged normally.
'chgstate idle on': the charger doesn't charge the battery.
'chgstate idle off': charge again.
Plug in AC and remove battery: No annoying repeated message and works fine.
Plug in battery and remove AC: No annoying repeated message and works fine.
Power up machine with battery only: No annoying repeated message and works fine.
Power up machine with AC only: No annoying repeated message and works fine.
Change-Id: I00d62f8afa2fe2627ea9259f11679ced02af897a
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196385
Refactored keyboard scan enable/disable flag such that it is a mask of
potential disable sources. When all disable sources are off, scanning is
enabled, otherwise scanning is disabled. This fixes a recently introduced
bug in which enabling/disabling keyboard scanning due to lid angle in S3
was interfering with enabling/disabling keyboard scanning due to power
button. This also allows for easy expansion for future causes for disabling
keyboard scanning.
BUG=chrome-os-partner:27851
BRANCH=rambi
TEST=Manual tests with a glimmer. Used the ksstate console command to
check state of keyboard scanning under all permutations of power button
pressed/unpressed, lid switch open/closed, and lid angle in tablet position
vs. laptop positon.
Change-Id: Ied4c5ebb94510b1078cd81d71373c0f1bd0d6678
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194287
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This improves some of the smart battery mocks, and adds some more tests for
the new change state machine.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=make coverage
Line coverage of this file jumps from 53% to 93%.
Change-Id: I4a9b8818cefaffd3022cebe08a36d592b0611295
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193690
Added a sub-command to the motionsense host command (0x2b) for getting/setting
the lid angle at which the keyboard is disabled as a wake source in S3. The
value can be anywhere from 0 to 360 degrees, default set to 180. Note, this
only takes affect for boards that have CONFIG_LID_ANGLE_KEY_SCAN defined.
Modified ectool motionsense command to use new host sub-command.
Also modified the lid angle measurement in the EC to be in the range [0, 360],
instead of [-180, 180], and changed casting of lid angle as an int to round
to nearest.
BUG=none
BRANCH=rambi
TEST=Tested on a glimmer:
Using default keyboard disable lid angle of 180, made sure that when lid
angle is past 180, key presses do not wake system, and when lid angle is
less than 180, key presses do wake up system.
Used ectool motionsense kb_wake to set the keyboard disable lid angle to 0.
Made sure that keyboard never wakes up the system. Set keyboard disable lid
angle to 360 and made sure that the keyboard always wakes up the system.
Change-Id: I437164c6e38c29169ef6e20e86c9cf2a1c78f86e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193663
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194172
Created a host command to set/get various motion sensor parameters and
added an ectool command to use that host command.
The host command is created such that the first argument is a
sub-command. Sub-commands created include:
dump: dumps all current motion sensor data
info: returns general information about each motion sensor
ec_rate: set/get the EC sampling rate of sensors
sensor_range: set/get the sensor range (ie +/- 2G,4G,8G)
sensor_odr: set/get the sensor output data rate (ie 50Hz, 100Hz, ...)
For sensor_range and sensor_odr parameters, since the host doesn't know
what are valid values for the parameter, the host can specify to round
up or down to the nearest valid value. For example, the host can specify
to set the output data rate to at least 100Hz, and the EC will return
the closest valid output data rate that is at least 100Hz.
BUG=chrome-os-partner:27321
BRANCH=rambi
TEST=Test on a glimmer using ectool from vt-2 prompt:
> ectool motionsense help
Usage:
motionsense - dump all motion data
motionsense info NUM - print sensor info
motionsense ec_rate [RATE_MS] - set/get sample rate
motionsense odr NUM [ODR [ROUNDUP]] - set/get sensor ODR
motionsense range NUM [RANGE [ROUNDUP]]- set/get sensor range
>
> ectool motionsense
Sensor 0: 0, 0, 1024
Sensor 1: 1024, 0, 0
Sensor 2: None
> ectool motionsense info 0
Type: accel
Location: base
Chip: kxcj9
> ectool motionsense ec_rate
10
> ectool motionsense ec_rate 1000
1000
> ectool motionsense odr 0
100000
> ectool motionsense odr 0 40000 1
50000
> ectool motionsense range 0 8
8
After running this I verified on the EC console that all the parameters
were set appropriately. I tested the EC sampling rate was 1000ms by
running lidangle on and making sure samples were displayed roughly every
second. I verified the sensor odr and range by defining
CONFIG_CMD_ACCELS and typing:
> accelrange 0
8
> accelrate 0
50000
Change-Id: I444e2f0eafabd607f1c7aa78b5c4e91f6cb06387
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192064
Reviewed-on: https://chromium-review.googlesource.com/193307
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Sometimes the battery happily reports that it's current temperature is
6280C, which is just a little bit high. This just treats unreasonably high
temperatures as an error.
BUG=chrome-os-partner:27527
BRANCH=ToT
TEST=manual
Make the change, watch the EC console while the AP is running and the
battery charges and discharges. The problem is intermittent, but when it
occurs it shuts the AP down immediately. With this change, it just prints a
warning instead.
I've also added a check for this to test/sbs_charging_v2.c
Change-Id: Ibfa53cf0244499ec52d4887bcd06fb9126c07a6c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193277
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is a complete rewrite of the charge_state task used by x86 platforms.
Rather than having a bunch of state-specific functions, each with their own
error handling and special cases, this is organized like so:
Forever:
1. Read everything we can from the battery and charger.
2. Figure out what we'd like to do (including error handling).
3. Allow for customization to override that.
4. Do it.
Things I need to file bugs for are marked with "TODO(wfrichar)". I'll file
the bugs after this CL goes in, so that they'll have something relevant to
refer to.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=manual
make buildall -j
Try it on Samus, watch it charge from nearly empty to full, both with and
without fastcharge enabled.
Also undefine CONFIG_BATTERY_PRESENT_CUSTOM, plug and unplug the battery to
be sure the trickle charging logic is correct when it can't tell if the
battery is present.
Change-Id: I3935cd3b87f322eb52178f8a675a886c16b75d58
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191767
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:26838
BRANCH=ToT
TEST=Verify only one ACPI 4 event is generated
when attaching external power and that only one
ACPI 5 event is generated when removing external
power. (using the ec console)
Change-Id: I7f8efa03a18bda39152abc2326f1cda928355868
Original-Change-Id: Icaec298bd0f41708260117c26f83fe9158a7ad4e
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189930
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192135
Added ability to disable the keyboard to wake from suspend when the lid
is outside a certain angle range. This has been added to glimmer by
defining CONFIG_LID_ANGLE_KEY_SCAN in its board.h.
Also modified the lid angle calculation to include a reliability
flag which can be used to tell when the hinge aligns too closely
with gravity and the lid angle value is unreliable.
BUG=none
BRANCH=rambi
TEST=Tested on a glimmer:
In S3, verified that when the lid is open past ~180 deg, the keyboard
does not wake the machine. Also verified that if you align hinge with
gravity, the keyboard enabled/disabled status remains the same (since
we can't actually trust the lid angle value).
Change-Id: I45b2c7c3c4bbcae61d3a0f8b5baa461ab8dabfb0
Original-Change-Id: If1a1592d259902d38941936961854b81b3a75b95
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190061
Reviewed-on: https://chromium-review.googlesource.com/191612
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Making room for a new charge_state implementation.
BRANCH=ToT
BUG=chrome-os-partner:23776
TEST=make buildall -j
No new functionality, just renaming some files.
Change-Id: I80ce861f09129a518e180cac20d32e867a93cd46
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190852
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When measuring speed gain of mem*() in utils test on host, there are too
many reasons that the results may be fluctuate. This gets even worse
when the unit tests run on buildbots. Let's only check for speed gain on
device.
BUG=chromium:351870
TEST=Check the speed gain check assertion is not compiled.
BRANCH=None
Change-Id: I0369d07d1da8cbb469d3a2a9d846406415c06745
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189804
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On some CPU cores, the compiler needs an helper to perform the 64-bit
multiplication. As the only remaining 64-bit multiplication in the code base
is not necessary, fix it rather than adding the helper.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=build for Cortex-M0 platform.
Change-Id: I88dd7a4f2eabeca5b03fb3db232bbca9a037dcf8
Reviewed-on: https://chromium-review.googlesource.com/189151
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
On some CPU cores, the compiler needs an helper to perform the 64-bit
multiplication.
As the only 64-bit multiplication in the code base is not necessary, fix
it rather than adding the helper.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=build for Cortex-M0 platform.
Change-Id: Id5d6b4b6641f81732a456dacb78dee7262f6729d
Reviewed-on: https://chromium-review.googlesource.com/188980
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Compiling with coverage enabled screws up the time that things take, so
don't test for a particular speedup in that case. It fails unreliably.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=manual
cd src/platform/ec
make coverage
Before, it failed about half the time. Now it doesn't.
Change-Id: I535f0193bf450a922b486777b296fea1b2768a1a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188790
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This speeds up memset by copying a word at a time.
Ran the unit test on Peppy:
> runtest
...
Running test_memset... (speed gain: 141532 -> 32136 us) OK
...
Ran make buildall:
...
Running test_memset... (speed gain: 1338 -> 280 us) OK
...
TEST=Described above.
BUG=chrome-os-partner:23720
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: If34b06ad70f448d950535a4bea4f6556627a9b6f
Tested-by: Daisuke Nojiri <dnojiri@google.com>
Reviewed-on: https://chromium-review.googlesource.com/185936
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@google.com>
