The previous boards that used double tap both used lightbar
sequence. Eve, also needs double tap, but doens't have lightbar. Added
a board specific call when processing the double tap event to allow
more flexibility.
BUG=b:35584895
BRANCH=none
TEST=Manual tested double tap and verified it was detected based on
the console print.
Change-Id: I73d8669803e7dcbbbac00de09822f4a286965fce
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/516546
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Adds min_frequency and max_frequency to struct motion_sensor_t.
New attributes min_frequency and max_frequency are now returned in
ectool's MOTIONSENSE_CMD_INFO response.
Incremented ectool's MOTIONSENSE_CMD_INFO version to version 3.
Add constants for MIN_FREQUENCY and MAX_FREQUENCY to each sensor's
header file.
BRANCH=none
BUG=chromium:615059
TEST=build/boot and verify MOTIONSENSE_CMD_INFO response on kevin,
make buildall -j passes.
Change-Id: I66db9715c122ef6bb4665ad5d086a9ecc9c7c93a
Signed-off-by: Nick Vaccaro <nvaccaro@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/482703
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Servo_v4 requires the ability to have a different default state per
port. In previous devices, the assumption was that each supported port
had the same default usb pd state and power role. This CL moves the
by the default power role which in turn is derived from
CONFIG_USB_PD_DUAL_ROLE. In addiiton to moving the location, it now
uses 'port' as argument so it can be port specific if required.
PD_DEFAULT_STATE was a board.h specific config, but in practice each
instance used to date was set to PD_STATE_SNK_DISCONNECTED if
CONFIG_USB_PD_DUAL_ROLE was defined and set to
PD_STATE_SRC_DISCONNECTED otherwise.
BUG=chrome-os-partner:61878
BRANCH=servo
TEST=Manual run 'make -j buildall' to verify that all instances of
PD_DEFAULT_STATE were removed.
Change-Id: Iaf40718668732f525485ed7942ee7fc246d3f75d
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/431787
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
sensor private structure for bmi160 and bmp280 were defined
in the drivers themselves. It worked because there was only one
instance of each sensors on a board. However, this is an error it
should be in board files, as it was done for other sensors like the kionix.
BUG=none
TEST=buildall.
BRANCH=kevin,reef
Change-Id: Ica3aba358d141a7df9a3e97251d4c1e520cbf2c8
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/424218
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If battery is not present, input current is set to PD_MAX_CURRENT_MA.
If the input power set is greater than the maximum allowed system power,
system might get damaged. Hence, limit the input current to meet maximum
allowed input system power.
BUG=chrome-os-partner:58498
BRANCH=none
TEST=Manually tested on Reef. Removed the battery & using 'charger'
console command observed the following.
With Zinger charger at 20V - Input current is set to 2.25A
With Type-C & other chargers - Input current is set to 3A
Change-Id: Ife8686f322e095aa74b740a7c469bfe87107fb9a
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/397865
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
charge_manager may request a charge current limit less than the
capability of the supply in certain cases (eg. during PD voltage
transition, to make an effort to comply with reduced load spec).
Depending on the battery / system state, setting a reduced charge
current limit may result in brownout.
Pass the uncapped / max negotiated current to board_set_charge_limit()
so that boards may use it instead of the requested limit in such
circumstances.
BUG=chrome-os-partner:56139
BRANCH=gru
TEST=Manual on kevin with subsequent commit, boot system with zinger +
low-charge battery, verify devices powers up to OS without brownout.
Change-Id: I2b8e0d44edcf57ffe4ee0fdec1a1ed35c6becbbd
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/383732
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Before P3 (long time ago), the PI3USB9281 has an I2C requiring a
workaround using the GPIO C15.
The workaround has been removed when we switched to PI3USB9281A
on P3 and the GPIO has been re-used since.
Remove the old GPIO definition to avoid conflicts with its new usage.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=smaug
BUG=chrome-os-partner:31526
TEST=make BOARD=ryu
Change-Id: Ieb7071b7ca27f3e9a4719592441b6a0b4c455b27
Reviewed-on: https://chromium-review.googlesource.com/380555
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When the charger is detached, the host event would sometimes be
sent before the charge info was updated, resulting in the host
thinking that the charger was still connected.
BUG=chrome-os-partner:55584
BRANCH=none
TEST=Connected charger to kevin 15 times and verified that the
icon was removed in 2-seconds or less.
Change-Id: I1a4e4e0f7cc23010210570fc261da8308d8e8070
Reviewed-on: https://chromium-review.googlesource.com/367809
Commit-Ready: Wonjoon Lee <woojoo.lee@samsung.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Since pretty much always, we've declared console commands to take
a "longhelp" argument with detailed explanations of what the
command does. But since almost as long, we've never actually used
that argument for anything - we just silently throw it away in
the macro. There's only one command (usbchargemode) that even
thinks it defines that argument.
We're never going to use this, let's just get rid of it.
BUG=none
BRANCH=none
CQ-DEPEND=CL:*279060
CQ-DEPEND=CL:*279158
CQ-DEPEND=CL:*279037
TEST=make buildall; tested on Cr50 hardware
Everything builds. Since we never used this arg anyway, there had
better not be any difference in the result.
Change-Id: Id3f71a53d02e3dc625cfcc12aa71ecb50e35eb9f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374163
Reviewed-by: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This feature is inconsistent. Not all boards have such a symlink
(for a obvious reason).
This feature is fragile. It's most likely not tested and going to be
broken if not already. Developers won't like it if they have to test
two different ways to build boards before submitting patches.
This feature is not necessary. If you build EC in the standard way
(e.g. make BOARD=samus), these symlinks are not needed.
This feature is wasteful. Extra disk spaces are used and extra lines
are added to Makefile (increasing code complexity slightly).
BUG=chromium:626776
BRANCH=none
TEST=make buildall
Change-Id: Id5444284d773cb0e9225f39abd877441b8f61440
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/359321
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously CONFIG_USB_PD_TCPM_VBUS had two uses which were independent:
- When operating as a TCPC, it indicated that the VBUS level should be
tracked (through GPIO inputs) and sent to the external TCPM when
appropriate.
- When operating as a TCPM, it indicated that the VBUS level should be
obtained by querying the TCPC.
These two independent uses have been split into
CONFIG_USB_PD_TCPC_TRACK_VBUS and CONFIG_USB_PD_VBUS_DETECT_TCPC, which
sould be more clear.
In addition, CONFIG_USB_PD_VBUS_DETECT_* CONFIGs have been added for
other means of VBUS detection.
BUG=chromium:616580
BRANCH=None
TEST=Verify kevin continues to boot + charge.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I936821481d6577e17e3e9c61ff97c037574d6923
Reviewed-on: https://chromium-review.googlesource.com/348950
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Previously the maximum number of deferred routines was specified by the
the default maximum number of deferred routines you had to override
this, and if you wanted fewer, you still payed the price of having the
defer_until array statically allocated to be the maximum size.
This change removes that define and instead creates the RAM state of
the deferred routine (the time to wait until to call the deferred) when
the deferred is declared.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
manually test on discovery-stm32f072
Change-Id: Id3db84ee1795226b7818c57f68c1f637567831dc
Reviewed-on: https://chromium-review.googlesource.com/335597
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Previously calls to hook_call_deferred were passed the function to call,
which was then looked up in the .rodata.deferred section with a linear
search. This linear search can be replaced with a subtract by passing
the pointer to the deferred_data object created when DECLARE_DEFERRED
was invoked.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
CQ-DEPEND=CL:*255812
TEST=make buildall -j
Change-Id: I951dd1541302875b102dd086154cf05591694440
Reviewed-on: https://chromium-review.googlesource.com/334315
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
With commit e9883124ff, a GPIO_INT macro was added. That change
also required that all instances of GPIO_INT in a board's
gpio.inc file come before any GPIO macros, or the interrupt
handler wouldn't work properly.
This CL just adds a warning comment about requirement to all
gpio.inc files.
BUG=chromium:471331
BRANCH=none
TEST=make buildall, test image on Cr50
This is a change to comments only. There is no new behavior to
verify, although I did run try out one new image just to be sure
nothing stupid happened.
Change-Id: I83f7819929a53bce3a8bae04d15b3ee3bda11738
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329334
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
On Ryu EVT2, where sensors share a 100kb i2c bus with other device,
when the sensors set to their maximal frequency and sampling interval
set to 5ms, the power management task would wait forever for the i2c
lock.
Increase the minimal amount of time the task can wait from 3ms to 8ms in
that case.
This is not an issue for Ryu PVT where the sensors are on a separate SPI
bus. However, on EVT, when setting the accelerometer/gyro over 125Hz, EC
won't be able to deliver the data in non-batched mode.
BRANCH=smaug
BUG=b:25510300
TEST=Without this change, an evt2 board would crash when plugging/unplugging
the charger while the sensors are set with:
echo 200000 > iio:device0/frequency # Accel
echo 5 > iio:device0/sampling_frequency
echo 200000 > iio:device1/frequency # Gyro
echo 25000 > iio:device2/frequency # Mag
Change-Id: Idb30da9ab8da61284388db73365c37be3a250dec
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311755
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Some chips previously defined CONFIG_I2C and others didn't. Standardize
the usage by removing CONFIG_I2C from all config_chip files and force it
to be defined at the board level. Also, make boards define
CONFIG_I2C_MASTER and/or CONFIG_I2C_SLAVE based on the I2C interfaces
they will use - this will assist with some later cleanup.
BUG=chromium:550206
TEST=`make buildall -j`
BRANCH=None
Change-Id: I2f0970e494ea49611abc315587c7c9aa0bc2d14a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/310070
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Modify the former workaround for board revisions missing an external
pull-up to 1.8V on EN_PP3300 :
the 100kOhm resistor between GPE13 and EN_PP3300 is still stuffed even
on boards which don't need the workaround, so tri-state the pin to avoid
driving the net.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=smaug
BUG=chrome-os-partner:46799
TEST=probed EN_3300 voltage level.
Change-Id: I48f2b2fa9a716cdbe07fbc8a006ba4d3fcfaa63d
Reviewed-on: https://chromium-review.googlesource.com/307868
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 53e49d6d6541183349bb7267fa5ec2b1db250d99)
Reviewed-on: https://chromium-review.googlesource.com/308514
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
When ALS is enabled, if light is around one threshold (say 40 lux),
the lightbar will flicker between readings.
Add a histeresis to prevent the flickering.
The current setting is:
setting ^
(dim) 2 | ------+---->---+
1 | +----<---+--->---+
(bright) 0 | +---<---+---------
+-------+--------+-------+--------> lux
20 40 60
BRANCH=smaug
BUG=chrome-os-partner:44400
TEST=check in a dark room (30~40 lux) there is no flickering.
Add unit test.
Change-Id: I4018e2c2ed764abf9c9ed28e2d50a3e94a7d5f75
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/308205
Gyro and compass is suspended but still powered on.
Therefore they don't need to be reinitialized.
Note that their init() does not do much, most is done when
initializing the accelerometer part of the BMI160.
BRANCH=smaug
BUG=none
TEST=Check that Gyro: MS Done Init... message are not present
when powering up the system in a loop.
Change-Id: If92727830c32407df49213db46b1d5f1cb0369af
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/308204
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Unless the lid is closed, the ALS is used for lightbar dimming.
Change the google colors depending on the light sensor result.
BUG=chrome-os-partner:44400
BRANCH=smaug
TEST=Check all 3 levels of brightness of the lightbar.
Check value using "adb shell ectool lightbar"
Check double tap color are not affected and is using full brightness.
Change-Id: I7b5e2890c3557f1dd3ae719f5f82ffb5fe7b24fb
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/301216
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When the sensor is defined to be used in forced mode, ec rate was not
calculated properly: if the AP rate was rounded up, ec_rate requested by
the AP would always be 0. If the EC rate is 0, the sensor may potientally
never be queried.
Also, when the sensor was disable for a long time, the last timestamp of
collection may appear to be in the future, so collection was not
initiated. (long time more than 35 minutes, less than 71 minutes).
We still see instance where the sensor seems locked up.
accelinit would not help because the state machine was not reseted, fix
that.
BRANCH=smaug
BUG=chrome-os-partner:45627
TEST=With accelerate 3/4, check the value is now correct.
Check proximity sensor is not stuck 45 minutes after last collection.
Change-Id: Ia6805b75f67b048cb0b42c0f91a73dfaf94a254f
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305823
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Remove duplicate code for checking request message, but keep
a board specific check of the request message for custom checks
needed on zinger and plankton.
BUG=chrome-os-partner:42490
BRANCH=none
TEST=make -j buildall. run on samus and connect a hoho, make
sure we successfully negotiate a contract.
Change-Id: I7398953a158d340e3e113f5a816b55445a857711
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305374
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Code for hard iron calibration: Every seconds (or faster if enough
samples), find a sphere that fit the compass data.
Based on Android code.
BRANCH=smaug
BUG=chrome-os-partner:39900
TEST=Check hard-iron bias is removed. Works better outside.
Change-Id: Iab479d5113b6560b4f01b0fd87373d2eecdb9b54
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/299583
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Rereading BMM150 spec, Z axis is pointing downward, so we should set
the rotation matrix accordingly.
BRANCH=smaug
BUG=chrome-os-partner:39900
TEST=Check value from sensor. TBD
Change-Id: Ib5d224fd7c84cdeaaeac06b683d554a373550e22
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/299581
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Export the board version through the usual EC_CMD_GET_BOARD_VERSION.
Add an option to use the board-specific board_get_version() callback
rather than doing the generic GPIO binary decoding since here the
version is ternary encoded.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=smaug
BUG=none
TEST=execute 'ectool boardversion' on the AP and see the right number.
Change-Id: I89c328573d09be02232756797ba3fdd5979b0292
Reviewed-on: https://chromium-review.googlesource.com/303368
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 6c620c51e5ab812b4e6751e4c630da2e6bee4b74)
Reviewed-on: https://chromium-review.googlesource.com/303803
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Some sensors are in forced mode, motion sense must be scheduled at
their ODR. However the host may not want the data right away,
so motion task may not wake up the host that often.
Add a new variable motion_int_interval that defines the maximum interval
between FIFO host event.
BRANCH=smaug
BUG=chrome-os-partner:43800
TEST=Check that light sensor is polled at ODR frequency.
Check that when AP does not want any event, no FIFO host event are
requested.
Check CTS tests work as before.
Reenable motion_lid unit test.
Change-Id: Ie25e6cbe28fed899073856057855ffa03c0cd9fd
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/301134
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Increase the change of false positive, but make double feels like Samus:
- increase time beetwen tap to 500ms
- decrease tap threshold to 100mg (actually 62.5mg)
- increase ODR during TAP.
BRANCH=smaug
BUG=b:24440423
TEST=check Ryu and Samus side by side, their tap behavior is more
similar.
run cts -c android.hardware.cts.SingleSensorTests
Change-Id: I260ad95136cb2be71ef4d71efc4bee0b28afa8e0
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302627
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Similar to i2c_xfer: allow access to a SPI device registers.
We assume the protocol use is set MSB bit to the offset for read
operation.
id is the index of the device in spi_devices.
BRANCH=smaug
TEST=Read/Write SPI registers.
BUG=none
Change-Id: Id4aaffbb6f514fd47086aee240b556ea23298d33
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/289857
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
spi_devices array needs the SPI master port used.
It is defined as CONFIG_, use it.
BUG=none
BRANCH=smaug
TEST=Check the sensors still work.
Change-Id: I6ce978caa32f4135dced59417a81ae280777fe57
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302021
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In S0, allow the host to enable/disable double tap.
Set S0 accel frequency to 100Hz to track double tap event.
BRANCH=smaug
BUG=chrome-os-partner:44754
TEST=check CTS results are identical to previous runs.
Check we can enable/disable double tap from the host.
Change-Id: Ic36bdd77005a1152fd413fb3869c8a77ef680117
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/298685
The current largest task size is not big enough,
we get stack overflow after one or several calibration requests.
BRANCH=smaug
BUG=chrome-os-partner:45570
TEST=After the change a loop of calibrate does not crash the EC.
Change-Id: I9681a890eddf274ab496e8ca6249c7ebca5edab5
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/301215
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Set USB communications capable flag in source/sink
capabilities PDO on boards that support USB. This
signals to other side that we are capable of
communication over D+/D- or SS Tx/Rx.
BUG=chrome-os-partner:34982
BRANCH=samus,smaug
TEST=load on samus, use twinkie to sniff traffic,
verify that USB comms capable bit is set in source
cap packet
Change-Id: I0f49cf19eb141512298c3439a4708c53101d674f
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/300637
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Enable charging from other dual-role devices by default.
BUG=chrome-os-partner:44958
BRANCH=smaug
TEST=tested on ryu with samus and a third party true dual-role
device.
Change-Id: I6540d00c33394eb66185bc4b5c27cf7c6b405ae8
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/297807
Reviewed-by: Shawn N <shawnn@chromium.org>
When a debug accessory is connected to the type-C port while the write
protection is enabled, put the case closed debugging in "partial" mode
rather than "full".
Update the "partial" mode to provide read-only access to the AP and EC
consoles.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=smaug
BUG=chrome-os-partner:44700
TEST=check the EC console input/output over USB is still working with SuzyQ
on a write-protected system, verify that the console input is disabled.
Change-Id: I5baa03d6e738d06437c45469f46b286e76a755a4
Reviewed-on: https://chromium-review.googlesource.com/297141
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Instead of returning the amount of light returned,
convert the data into distance (cm). It can be adjust via range.
BRANCH=smaug
BUG=chrome-os-partner:42526
TEST=check the data is usable by HAL.
Change-Id: I97510246ce054af4e61325d7e295ca09cc536457
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/296472
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Add config settings for ODR and EC rate per requestor and
per power state (1 for the AP, 3 for the EC).
This way we can finely set ec rate and ODR depending on usage.
On chromeos, AP is not setting frequency, so EC sets for different power
state. On some platform, sensors can now be suspended in S3/S5.
Allow EC oversampling when AP is only looking for a few samples.
It is useful for double tap detection where high accelerator ODR is
required.
BRANCH=ryu
TEST=Tested on Ryu
BUG=chromium:513458
Change-Id: Ic3888a749699f07b10c5da3bc07204afd4de70da
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295637
Good rule of thumb for charger current is that it should be set
between C/20 & C/50 for the battery of the device.
For ryu its presently set at 64mA which may explain why we see
charger's status as charging even when battery is full. In any case
its well below recommendation so lets change it to something within
that.
Sampled data (see issue tracker) indicates charging current is ~256mA
when battery reaches 100% charged. Setting to 192mA (3 * 64) to error
on the side of charging slightly longer. This number is still within
termination current recommendation:
C/20 > term_current >= C/50
Note, also changing bq2589x default termination to match its POR value
of 256 as no other board uses this charger presently.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=smaug
BUG=chrome-os-partner:42848
TEST=manual, read charger IC termination register and see termination
current set to 192mA
Change-Id: I60dbb9326c3abb8091fd9ab18eda08b9eabb197b
Reviewed-on: https://chromium-review.googlesource.com/293096
Commit-Ready: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry-pick back to ToT)
FAFT needs these buttons (VolUp and VolDown) be controllable
such that it can automate the firmware mode switching flows.
It is done by EC overwriting the GPIO values such that AP can
see the results.
BRANCH=ToT,smaug
BUG=None
TEST=AP boots into the firmware menu screen. Run the following commands
in EC console:
> btnpress voldown 1
> btnpress voldown 0 # See the next option selected, like a real button pressed
> btnpress volup 1
> btnpress volup 0 # Boot in the selected option, like a real button pressed
> btnpress volup
Button volup pressed = 0
Change-Id: I5e0b514d9986b8e5729ffd3560560d650669e0b7
Signed-off-by: Vic Yang <victoryang@google.com>
Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/294882
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 77291b156d10f31dd059a4662aa249a8f8ea762e)
Reviewed-on: https://chromium-review.googlesource.com/295162
