Prevents a null pointer dereference when the AP asks the EC
for nonexistent settings of a sensor.
BUG=chromium:761758
TEST="ectool motionsense offset ${ID of baro_bmp280 sensor}"
And see no null pointer dereference, but an invalid command error
BRANCH=master
Change-Id: I3050feaa3c9752abebc30237dac1befa4e5775cc
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/850639
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
The size of empty structs (and unions) varies between C and C++. When
including in C++ code our external API in ec_commands.h header with
extern "C". clang will complain (correctly) for all empty structs:
error: empty struct has size 0 in C, size 1 in C++
[-Werror,-Wextern-c-compat]
Remove them from the ec_commands.h header file.
ectool.c has some ugly macros which assume subcommands have both
requests and responses. Change those macros so they only reference
the non-empty sub-structs. The macros are still ugly, but generate
identical output, and don't rely upon zero-length structs.
BUG=chromium:792408
BRANCH=none
TEST=manual
1) Compile the following using 'clang -Wall -Werror':
#include <stdint.h>
extern "C" {
#include "include/ec_commands.h"
}
int main(void) { return 0; }
It compiles without error.
2) Copy the lb_command_paramcount, ms_command_sizes, and
cs_paramcount globals from ectool.c to a dummy .c file and
compile with 'gcc -S' to generate assembly. Do the same
after applying this patch.
Confirm the arrays have the same contents.
Change-Id: Iad76f10315b97205b42118ce070463071fe97128
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/820649
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
At the end of the sensor initialization, all _init sensor routines set
the range to the default value from board.c file.
Put all the code in a single place, move it from sensor_common.c to
motion_sense.c.
BUG=none
BRANCH=none
TEST=compile
Change-Id: If89cf27c6438e0f215c193d68a480e027110174c
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/767610
Reviewed-by: Shawn N <shawnn@chromium.org>
LPC area for sensors support 3 sensors:
up to 2 accelerometers and 1 gyro.
If only 1 accelerometer is present, only the first accelerometer slot is
populated.
If there is no gyro, the gyro slot is not populated.
Add tests and remove assumption in the code to be sure the rules above
are enforced.
BRANCH=none
BUG=b:64232053
TEST=compile, check eve is still working.
On soraka:
ectool motionsense odr 2 10000
ectool motionsense
output matches:
grep . /sys/bus/iio/devices/*/in_*_raw
Change-Id: Ifd791a6fa89d94bf91ad1a65b8987f69bada801e
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/639319
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
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>
Use the motion sensor to manage ALS as well.
The current interface (via memmap) is preserved, but
we can also access the sensor via cros ec sensor stack and
send the ALS information to ARC++.
BUG=chrome-os-partner:59423
BRANCH=reef
CQ-DEPEND=CL:424217
TEST=Check the sensor is working via ACPI sensor and
cros ec sensor. Check ARC++ sees the sensors.
Change-Id: Iaf608370454ad582691b72b471ea87b511863a78
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/424323
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Shorten certain long prints and reduce the precision of timestamp prints
when CONFIG_CONSOLE_VERBOSE is undef'd.
BUG=chromium:688743
BRANCH=gru
TEST=On kevin, cold reset the EC, boot to OS, and verify cros_ec.log
contains all data since sysjump and is < 2K bytes (~1500 bytes).
Change-Id: Ia9390867788d0ab3087f827b0296107b4e9d4bca
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/438932
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
During shutdown sequence sensor rails can be powered down asynchronously
to the EC hence EC cannot interlock the sensor states with the power down
states. To avoid this issue, defer switching the sensors rate with a
configurable delay if in S3. By the time deferred function is serviced,
if the chipset is in S5 we can back out from switching the sensor rate.
BUG=chrome-os-partner:61489
BRANCH=none
TEST=Manually tested on Electro. Put the device in S5 and observed
no I2C errors printed on EC the console.
Change-Id: I40b75ebbf0d05fafffdfd535962423c3960fafbf
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/433338
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This commit adds a "spoof" mode feature to the motionsense stack. It
allows the user to arbitrarily set the outputs of the sensor in order to
"spoof" the readings of the sensor. This can be useful in emulating
tablet mode or device rotations. A command is available from the EC
console named `accelspoof` and there is a corresponding motionsense
command in ectool called `spoof`.
The usage is as follows:
- EC console
> accelspoof [id] [on/off] [X Y Z]
- ectool
# ectool motionsense spoof -- [id] [0/1] [X Y Z]
If on or off(or 0/1) is not specified, the current spoof mode status of
the sensor is returned. If on is specified, but no components are
provided, the sensor will lock the current values and provide those as
the spoofed values. If the components are provided, those will be used
as the spoofed values.
BUG=chromium:675263
BRANCH=cyan,glados,gru,oak
TEST=Flash a DUT with accels. From AP console, run `ectool motionsense
lid_angle` in a loop, use 'accelspoof' EC console command to set spoofed
values. Verify that the angle is fixed regardless of the actual angle
of the DUT.
TEST=Flash a DUT with accels. From AP console, use `ectool motionsense
spoof` to spoof values and verify that `ectool motionsense` reflects the
spoofed values. Test with both provided component values and no
component values.
Change-Id: Ie30688d22f38054e7243b1af493a3092b2cdfb72
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/421280
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
We need 2 accelerometer for tablet mode. If one of them is not working,
disable tablet mode. We will stay in clamshell mode, lid angle will be
always unreliable.
BUG=chrome-os-partner:61141
TEST=On kevin with a single sensor. Check we are in clamshell mode
when rebooting the EC.
BRANCH=kevin
Change-Id: I7bf6cdc9d85370fce20e5183622b4bc18f4f5f99
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/424184
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
last_collection is used for sensor in forced mode to be sure we are not
calling the read routine too often. We should update last_collection even
when the reading fails, and not on the interrupt path.
For sensors that support interrupt, the new timing diagram is:
/-------- data rate period ---------\
--------------+------------------------------------+-----------------> t
| /\
read (sample request) |
| Interrupt (sample available)
\/ |
sensor
BUG=chrome-os-partner:59423
BRANCH=reef
TEST=Check the ALS read is not called too often even when the sensor
reports an error because the read value is not changed.
Change-Id: I2def7bbd5227cf373c1f613c9b70bc6215861008
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/424222
Reviewed-by: Randall Spangler <rspangler@chromium.org>
CL/385081 was incorrect, MAX should be used instead of MIN when calculating
the oversampling factor, to be sure it can't be 0.
BUG=b:27849483,chrome-os-partner:59423
BRANCH=reef
TEST=Using a special firmware on Reef reporting the ALS in motionsense,
check that oversampling is 1 when requested frequency is 5Hz while the
maximal frequency supported is 1Hz.
Check the ALS sensor reports information to ARC++.
Change-Id: I3c2d447bbc3a9ca0a5963aa86d5a24ee87ca6ab6
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/424221
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Simple API to set/get the tablet mode. It can be set via lid angle
calculation or if a board has a dedicated HAL sensor/GPIO.
Merged from glados branch, add MKBP switch support.
BUG=chromium:606718
BRANCH=gru
TEST=Check with Cave that both mode works.
Reviewed-on: https://chromium-review.googlesource.com/402089
Reviewed-by: Shawn N <shawnn@chromium.org>
(cherry picked from commit c940f36ceabcf2425284001298f03ebdb4c3079e)
Change-Id: I2ee5130f3e0a1307ec3ea543f7a32d66bc32b31d
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/404915
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
In case the AP is asking for a ODR frequency the sensor can not achieve
(for instance over 76Hz for BMP280), be sure we do not set oversampling
to 0.
Otherwise, no sensor data will be sent to the AP.
BUG=b:27849483
BRANCH=reef
TEST=Check Androsensor reports presure information even when frequency
is set at 100Hz.
Change-Id: Idb849782daa96531cc33d21ea6780fd7f1f299d5
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/385081
Commit-Ready: Gwendal Grignou <gwendal@google.com>
Tested-by: Gwendal Grignou <gwendal@google.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
User of sensor data can use tablet mode to rotate the sensor datums
along the X axis.
This is useful on Kevin where we gather base data.
When the base is behind the lid, the datums needs to be rotated by 180
to be in the lid referential.
BUG=b:27849483
BRANCH=none
TEST=check the sensors changes when kevin is in tablet mode.
Change-Id: I60147600f534df0770a44b5158ef8afe87d9dd9d
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/380413
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
No need to do set_range in motion_sense_shutdown(), already done at init.
Besides, this is an error if the sensor is not powered in S5.
BUG=b:27849483
BRANCH=cyan, minnie, samus
TEST=Check sensor range is set correctly.
(cherry picked from commit 1018eac30db86dd1d78d5b84b7651edd6aca9225)
Reviewed-on: https://chromium-review.googlesource.com/379097
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Change-Id: Id0b9c2e4988ffc8b55b21258f60b1efa26156dbb
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/379542
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>
If wait_us < 0, comparison against motion_min_interval actually fails,
and this negative wait_us causes task_wait_event() never returns if we
are not using any motion task event except the timer. The motion task
will then stop running and sensor data stay unchanged.
BRANCH=none
BUG=chrome-os-partner:54092
TEST=hardcode wait_us to a negative value before motion_min_interval check,
and see motion task is still running by EC console cmd timerinfo
Change-Id: Ic1e7ffeeb9d2ec1f5c5beb4387294014298123af
Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/358332
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Currently, it is assumed the host will sooner or later retrieve the
events from the sensor ring: It is only used by Android and the sensor
HAL is enabling the ring buffer at boot.
But if nobody processes the ring, and the ring is almost full, the EC will
generate interrupt for every new events.
This can happen with ARC, where events generated for ChromeOS
will be in the ring but nobody will process them until Android is
started.
Add a command to allow sending ring MKBP events. It will be used when
the IIO ring buffer is enabled / disabled.
It also can be used for preventing raising interrupt when the device is
about to go to sleep.
BRANCH=ryu,cyan
BUG=b:25425420,b:27849483
TEST=Check with fiforead that no events are queued when IIO ring
buffer is disabled.
Check with ectool and androsensor that interrupt generation stops.
Change-Id: Ibc85eed2e0eae3a9ec07d191e692118bc2fd0dab
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356689
cl/301134 has a bug. If the AP wants a forced sensor (i.e. light) at
100Hz but a sampling frequency at 1s, we would still wake it up every
.1s instead of 1s.
Take in account force mode only when calculating the sampling frequency
not the interrupt interval.
BRANCH=smaug
BUG=b:25425420
TEST=Check the device goes to suspend even with 40Hz light sampling
rate:
echo 0 > /sys/bus/iio/devices/iio:device0/frequency
echo 40000 > /sys/bus/iio/devices/iio:device3/frequency
echo mem >/sys/power/state
Before it would resume just after suspend/while suspending.
Change-Id: Ie4fe36268cb1b04bc8f01ec885af84fad9e8b282
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314315
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When sensor_shutdown() is called, the sensors may already been powered
off, or will be soon.
In that case, do not attempts to access them.
Check their state before setting range or disabling activities.
BRANCH=smaug
BUG=chromium:557966
TEST=compile
Change-Id: I60640b120a23f9aab393a93c4c67ef17222ced4e
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314382
Reviewed-by: Alec Berg <alecaberg@chromium.org>
In case the actual ODR rate is way higher that the AP asked for,
we don't have to settle to a slower EC rate if
EC rate == AP requested ODR rate.
BRANCH=smaug
BUG=none
TEST=Run android.hardware.cts.SingleSensorTests
Change-Id: I437f47bd942a16694c7efcdbc00201352f0480a6
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313641
Reviewed-by: Alec Berg <alecaberg@chromium.org>
AP could collect samples while motion task was still adding timestamp.
A data stream not ending with a timestamp can lead to timestamp error in
the kernel.
This is espcially true if the motion task interrupt the AP back to back,
when sensor ODR changes for instance.
BRANCH=smaug
BUG=b:24367625
TEST=Run android.hardware.cts.SingleSensorTests
Change-Id: I5820216a2cfc0a869db7dc5ef75d4be126a53b4f
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313640
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Throughout the code, there are comparison between frequency (in mHz) and
period (in us). To improve readability, append units (_mhz, _us) after
variable names.
BRANCH=smaug
BUG=none
TEST=compile.
Change-Id: Icc9c66d9f06c526fc3b74fd85ca9759b702ee416
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313221
Reviewed-by: Alec Berg <alecaberg@chromium.org>
We need to wake up the main task, even if we disable a sensor. It will
force sending the sensors samples in the FIFO and put a timestamp behind
them.
Also, reduce the interrupt period by 10us to be sure we fire interrupt
to the AP even if there are some variation in the timing calculation.
BUG=b:24367625
BRANCH=smaug
TEST=Run ts.SingleSensorTests overnight.
Change-Id: I6d966d52b5cbb72ba5eb936bc2fad6c06c7d8605
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312986
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If EC sampling rate is close to sensor rate, decrease sampling frequency
by 5% to prevent samples by the EC without data.
It can happen when the clocks are slightly different and get
unsynchronized.
BRANCH=smaug
BUG=b:24367625
TEST=Ran cts.SingleSensorTests overnight without error.
Change-Id: Iab5e578763171411eb474e1e717167c8e1ef7ecf
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312985
Reviewed-by: Alec Berg <alecaberg@chromium.org>
To ease finer calculation of ec rate change units from
ms to us.
BRANCH=smaug
BUG=b:24367625
TEST=compile
Change-Id: I52057c8ca1b1180a64b58d1ba0af9ec53f40b026
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312984
Overly complex previous formula could lead the EC to throw all samples
between 2 timestamps and put 2 event within one timestamp.
That would confuse the kernel. If the motion sense task is delayed while
this happen, the delta between the 2 samples could be so long that
CTS test cts.SingleSensorTests would fail.
BRANCH=smaug
BUG=b:24367625
TEST=Loops of cts.SingleSensorTests pass.
Change-Id: I29e6bf354ccb7ecf741a91116854d6abe07558dc
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312364
Reviewed-by: Vincent Palatin <vpalatin@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>
Use test_export_static for static variable/function that needs to by
used by tests/motion_lid.c
BRANCH=smaug
BUG=none
TEST=Compile, make buildall -j
Change-Id: I2f3eb72ce319622842885be9125b91e58f47133a
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311754
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Call shutdown() entry point at init() and remove duplicate code.
shutdown would init the sensor so they would be ready if needed.
Set S5 flag to include G3 (hard off) state, not only S5 (soft off).
BUG=chrome-os-partner:45722
BRANCH=smaug
TEST=When doing a RO->RW transition while AP is in G3, check the sensors
are initialized properly. This issue was found while testng the magic
sequence code.
Change-Id: I647f83580240bf5ba0c340fca3184220abe4c12e
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/308561
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Double TAP must be enabled in S5, even if it has been disabled by the
AP, otherwise we would not be able to check the battery level if the AP
did not shutdown properly or does not reenable double tap on shutdown.
BRANCH=none
BUG=chrome-os-partner:46572
TEST=Check double tap is working after unit has been powered down.
Change-Id: Ic798399a3e4ae4d87c6e80eab4cf1fd680f99585
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/306697
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Declare optional parameters are const structure.
These parameters, when used, are just read by the sensor driver.
BRANCH=smaug
BUG=None
TEST=compile
Change-Id: I8f2a9291e1908922831fb5e2a524bb6edd0e0f65
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/306696
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>
Before setting a new frequency, put a timestamp in the FIFO.
In case there was a long silence, the sample timestamp will be anchored
on that timestamp instead of the last timestamp the AP collected.
BRANCH=smaug
BUG=chrome-os-partner:43811
TEST=Check SingleSensorTests pass.
Change-Id: Ie40ebd9d856abdeeeccf4b636351560bb8a6305c
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305571
Reviewed-by: Alec Berg <alecaberg@chromium.org>
cl:302176 did not fully fix the issue:
- sampling rate would be unnecessary truncated to integer.
- Because the sensor can slightly oversample (15Hz -> 25Hz, 10Hz ->
12.5Hz), we would skip samples for long period of time.
In both cases we skip samples in low speed tests, noticed by CTS tests.
BUG=b:24367625
BRANCH=smaug
TEST=Before we would fail some
android.hardware.cts.SingleSensorTests#testMagneticField_X,
Now pass.
Change-Id: Ic555e2add47ba89a0a0657f5eb492a5e7ca441d5
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/303010
Reviewed-by: Alec Berg <alecaberg@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>
Sandwich wake up event between timestamp.
Otherwise HAL will think the event came from a long time ago.
With two timestamp, the wake event timestamp will be - more - accurantly
set at the time it occurs.
BRANCH=smaug
BUG=chrome-os-partner:45704
TEST=Pass com.android.cts.verifier.sensors.SignificantMotionTestActivity
Change-Id: I6be76820d71d2571d069542564f569a623001190
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302642
Reviewed-by: Alec Berg <alecaberg@chromium.org>
cl/296213 had another bug that prevent Significant motion gesture to be
set: In set_activity, activity is a number, not a bitfield.
BRANCH=smaug
BUG=chrome-os-partner:45704
TEST=With ectool motionsense set_activity and list_activity,
check we can set/reset the significant motion activity.
Change-Id: Iff921f3f5edcee74ed3540139f13da301f149173
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302641
Reviewed-by: Alec Berg <alecaberg@chromium.org>
cl:298688 was wrong and oversampling calculation, used to drop
events that AP does not want was incorrect.
We were comparing mHz with Hz.
BUG=b:24367625
BRANCH=smaug
TEST=Before, we would fail all
android.hardware.cts.SingleSensorTests#testAccelerometer tests where
frequency was lower than 100Hz. After, we pass thoses tests.
Change-Id: I487feb4e235a21f78d367397b5890ebcc5864b22
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302176
Reviewed-by: Alec Berg <alecaberg@chromium.org>
1. ret always evaluated to INVALID_PARAM and so SET_ACTIVITY bailed out
early and returned an error to host command.
2. No need to verify sensor id since SET_ACTIVITY / LIST_ACTIVITIES
identify the correct sensor to operate on.
BUG=chrome-os-partner:45710
BRANCH=None
TEST=Compiles successfully. Disable double-tap works as expected.
Change-Id: I58ae9cd5009fadedb3ea78a4eec0452124747707
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/301990
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 2a3a120c8f7cca1e032f4be2a198748f0e8b5fb1)
Reviewed-on: https://chromium-review.googlesource.com/302409
Commit-Ready: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
