summaryrefslogtreecommitdiff
path: root/include/motion_sense.h
Commit message (Collapse)AuthorAgeFilesLines
* type: Rename matrix_3x3_t to mat33_fp_tYilun Lin2018-09-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Naming of many vector types and matrix types are not clear enough. For example, we have: vector_3_t, which is a vector of three int. vec3_t, which is a vector of three float. size4_t, which is a vector of four size_t. mat33_t, which is a 3x3 matrix of float. matrix_3x3_t, which is a 3x3 matrix of fixed point. Besides, we have types like int8_t, uint16_t types. To clearly distinguished types, the CL propose to, For vector types, naming should be `$type + 'v' + $num + '_t'`: vector_3_t becomes intv3_t vec3_t becomes floatv3_t vector 4 of uint16_t becomes uint16v4_t (which doesn't exist yet) For matrix types, naming should be `mat$N$N_` + $type + '_t', where $N is the matrix size: matrix_3x3_t becomes mat33_fp_t # fp: fixed point mat33_t becomes mat33_float_t TEST=make buildall -j BUG=b:114662791 Change-Id: I51d88d44252184e4b7b3564236833b0b892edc39 Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1215449 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* type: Rename vector_3_t to intv3_t.Yilun Lin2018-09-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Naming of many vector types and matrix types are not clear enough. For example, we have: vector_3_t, which is a vector of three int. vec3_t, which is a vector of three float. size4_t, which is a vector of four size_t. mat33_t, which is a 3x3 matrix of float. matrix_3x3_t, which is a 3x3 matrix of fixed point. Besides, we have types like int8_t, uint16_t types. To clearly distinguished types, the CL propose to, For vector types, naming should be `$type + 'v' + $num + '_t'`: vector_3_t becomes intv3_t vec3_t becomes floatv3_t vector 4 of uint16_t becomes uint16v4_t (which doesn't exist yet) For matrix types, naming should be `mat$N$N_` + $type + '_t', where $N is the matrix size: matrix_3x3_t becomes mat33_fp_t # fp: fixed point mat33_t becomes mat33_float_t TEST=make buildall -j BUG=b:114662791 Change-Id: I865aa3ecbab6cb97f8585a081a679adf00febe1d Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1215442 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* motion: Lower jitter of Sensor->EC timestampAlexandru M Stan2018-03-141-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead getting the time for each sample in the task code, we should be getting it as soon as the sensor reported it added it to its fifo (so sensor just finished integration). Because of that each sensor should provide the time when it provides a sample, ideally from an accurate spot like an interrupt. Deprecate motion_sense_fifo_add_unit (without a timestamp) in favour of motion_sense_fifo_add_data (which adds the timestamps). Update all relevant sensors to use the new api. Note: for now I focused on the BMI160, where I actually made it get the time in the interrupt. The other sensors were made to use the new api, but still don't record the time in the right place (though it's not any worse than before). BUG=b:67743747 TEST=In the kernel, fifo_info->info.timestamp still has sane values. TEST=CTS should still pass BRANCH=master Change-Id: I9829343f8702e00cc19f9c88134fa1f258c9e1e9 Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/807331 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
* motion_sense: Fix indentation in headerAlexandru M Stan2018-01-021-5/+5
| | | | | | | | | | BUG=None, while looking at b/67743747 TEST=None Change-Id: I8799c66e236c697c570bfb123531696483ef6db8 Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/807330 Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
* chipset: Introduce CHIPSET_STATE_ANY_SUSPENDFurquan Shaikh2017-11-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | There are two different types of suspend states that are supported on x86 platforms -- S3 and S0ix. When AP enters S3, the chipset state is identified as CHIPSET_STATE_SUSPEND. On the other hand, when AP enters S0ix, the chipset state is identified as CHIPSET_STATE_STANDBY. There are several components within the EC e.g. charger state machine, usb pd task, motion sense task that take actions based on the chipset suspend state (and checked only for CHIPSET_STATE_SUSPEND until now). In order to ensure that different EC components do not have to worry about checking for all the different types of suspend states that are supported, introduce a new combination CHIPSET_STATE_ANY_SUSPEND which is a combination of CHIPSET_STATE_SUSPEND(S3) and CHIPSET_STATE_STANDBY(S0ix). BUG=b:69690699 BRANCH=None TEST=make -j buildall. Ruben verified that with this change, EC power consumption in S0ix drops from 7.85mW to 6.59mW on Soraka. Change-Id: I599a0ea2fe2f39132764a6068fa77c3aea02affa Signed-off-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/786919 Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* motion_sense: Put set_range in common codeGwendal Grignou2017-11-171-4/+4
| | | | | | | | | | | | | | | | 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>
* motion_sense: Add CONFIG_DYNAMIC_MOTION_SENSOR_COUNT config optionScott Collyer2017-10-111-0/+4
| | | | | | | | | | | | | | | | | | | | | Some projects, such as Coral use a common image to support different SKUs. In this case the number of motion sensors supported may need to be determined at runtime. CONFIG_DYNAMIC_MOTION_SENSOR_COUNT removes the const assumption for the global variable motion_sensor_count. Based on CL https://chromium-review.googlesource.com/444587 BUG=b:38271876 BRANCH=None TEST=make -j buildall Change-Id: I4dd3384d245641136f3329b60d1d941927366387 Signed-off-by: Scott Collyer <scollyer@google.com> Reviewed-on: https://chromium-review.googlesource.com/711194 Commit-Ready: Scott Collyer <scollyer@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
* sensors: add bmi160 & kionix orientation driverNick Vaccaro2017-08-081-1/+7
| | | | | | | | | | | | | BRANCH=none BUG=chromium:718919 TEST=make buildall -j works, orientation works when enabled on gru and scarlet. Change-Id: I16dcfa5d9dea39c082d98190fa1bb6e496168b17 Signed-off-by: Nick Vaccaro <nvaccaro@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/540124 Tested-by: Nick Vaccaro <nvaccaro@google.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
* sensor: Add board specific function for double tap eventScott Collyer2017-06-011-0/+6
| | | | | | | | | | | | | | | | | | | 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>
* common: sensors: add extra sensor attributesNick Vaccaro2017-05-181-0/+12
| | | | | | | | | | | | | | | | | | | | | | 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>
* motion: Add opt3001 as a motion sensorGwendal Grignou2017-02-161-0/+4
| | | | | | | | | | | | | | | | | | 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>
* console: Add non-verbose print config optionShawn Nematbakhsh2017-02-111-0/+9
| | | | | | | | | | | | | | | | | 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>
* motion_sense: Add "spoof" modeAseda Aboagye2017-01-071-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* motion: remove accel_int_xxx, dead codeGwendal Grignou2016-09-091-16/+0
| | | | | | | | | | | | | Remove code to set interrupt threshold, unused and broken. BUG=chromium:426659 BRANCH=kevin TEST=compile Change-Id: I11362d3f7131bfe9849be26edeaeb768463c0c7f Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/382675 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* sensor: update sensor driver to use I2C port from motion_sensor_tKevin K Wong2016-03-311-0/+4
| | | | | | | | | | | | | this allow motion sensor devices to be locate on different I2C port BUG=none BRANCH=none TEST=make buildall Change-Id: Ia7ba2f5729ebb19561768ec87fdb267e79aafb6a Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com> Reviewed-on: https://chromium-review.googlesource.com/334269 Reviewed-by: Shawn N <shawnn@chromium.org>
* motion: improve readability by adding units to variable names.Gwendal Grignou2015-11-191-1/+1
| | | | | | | | | | | | | | | 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>
* motion: wake up main task for all changes in EC parameter.Gwendal Grignou2015-11-191-1/+3
| | | | | | | | | | | | | | | | | 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>
* motion: Change units of ec_rate from us to ms.Gwendal Grignou2015-11-181-4/+4
| | | | | | | | | | | | | 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
* motion: fix oversampling formulaGwendal Grignou2015-11-151-1/+4
| | | | | | | | | | | | | | | | | 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>
* motion: minium interval between motion task now a variableGwendal Grignou2015-11-131-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* motion: cleanup include fileGwendal Grignou2015-11-121-5/+0
| | | | | | | | | | | | | | 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>
* motion: Remove duplicate shutdown codeGwendal Grignou2015-10-281-1/+1
| | | | | | | | | | | | | | | | | 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>
* common: lightbar: Add histeresis to prevent flickeringGwendal Grignou2015-10-231-0/+5
| | | | | | | | | | | | | | | | | | | | | | | 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
* common: Add lightbar dimming based on outside light.Gwendal Grignou2015-10-201-0/+4
| | | | | | | | | | | | | | | | 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>
* motion: fix spellingGwendal Grignou2015-10-151-5/+5
| | | | | | | | | | | | | | | | | | Fix various spelling errors. Command used: spell include/motion_sense.h | sort | uniq -c | \ grep -v -f ~/tmp/known_words | sort -n > /tmp/checking_spell Appended /tmp/checking_spell to ~/tmp/known_words to avoid C code. BRANCH=smaug TEST=compile BUG=none Change-Id: I39acfeaefef51d142a587940bccb02db86e87068 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/305570 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* common: motion: Separate motion task interval from AP configurationGwendal Grignou2015-09-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | 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>
* motion: Add Gesture InterfaceGwendal Grignou2015-09-181-0/+8
| | | | | | | | | | | | | | | Add an interface with the host to set up gesture recognition. Today, only significant motion is supported. Add a virtual sensor for concentrating gesture support from host. BRANCH=smaug BUG=b:23570481 TEST=On ryu, enable significant motion from host. Change-Id: I906fa2d2d7b4ca2771ea2f58b91de8d97bf4e2e3 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/296213
* driver: bmi160: Prevent crash when FIFO is not validGwendal Grignou2015-09-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | When all BMI160 sensors are suspended, FIFO is invalid. Put the test to check if all sensors are disable within the processing loop: otherwise, the FIFO can become invalid while we are processing it. Add printf to be sure we are not processing invalid FIFO. Add a macro around ODR to really check the ODR rate, excluding the roundup flag. BRANCH=smaug BUG=chrome-os-partner:44381 TEST=Using a special patch (see 44381#14) add delay to simulate a loaded EC (like at resume). Using a script flip-flop sensors frequency (to simulate suspend/resume). Check that: - we are not crashing anymore (we were before this patch) - the driver is not hitting invalid FIFO content. Change-Id: I7c9e86f5dcfc231ab89472a6ea03af22e2c2ac32 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/297178 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* samus: Use new config, fix gestureGwendal Grignou2015-08-291-9/+0
| | | | | | | | | | | | | | Use new config table. Move ODR setting in motion sense, fix variable names. BRANCH=samus BUG=chromium:513458 TEST=Test accelerator and double tap on Samus Change-Id: I341add11a18de8e4cc97c57da29f9114bd2014cf Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/295638 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* motion_sense: Add more complex EC/AP sensor rate support.Gwendal Grignou2015-08-291-12/+46
| | | | | | | | | | | | | | | | | | | | | 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
* motion_sense: calculate threshold properlyGwendal Grignou2015-08-241-1/+1
| | | | | | | | | | | | | | | | Working on light sensor, sensor were read on every time, SENSOR_EC_THRES was not taken into account. Fix 64/32 conversions and add a function for dealing with rollover. TEST=Set light sensor probe at 1s. Set accel sensor at 100Hz to fill fifo often; verify that light sensor is queried every second only. BRANCH=smaug BUG=chrome-os-partner:39900 Change-Id: If1df53c1a9a304c992f8e517f5d516210118a437 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/291992 Reviewed-by: Sheng-liang Song <ssl@chromium.org>
* motion_sense: Allow multiple IRQ based sensorsGwendal Grignou2015-08-221-4/+13
| | | | | | | | | | | | | | | Add a mask of custom events reserved for IRQ based sensors. Copy data from raw_xzy to xyz while filling the FIFO when FIFO is enabled. BRANCH=smaug TEST=Test with si1141 driver, check irq works for both driver. BUG=chrome-os-partner:32829 Change-Id: I5e106df0c121e3bf1385f635195717395235ccc3 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/291334 Reviewed-by: Sheng-liang Song <ssl@chromium.org>
* accel: mechanical changes from i2c_addr to addrGwendal Grignou2015-07-301-1/+2
| | | | | | | | | | | | | | | Encode both the I2C address and SPI GPIO CS in addr field. Mechanical change to rename i2c_addr into addr. BRANCH=smaug TEST=compile BUG=chrome-os-partner:42304 Change-Id: I1c7435398deacb27211445afa27a08716d224c06 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/288513 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: David James <davidjames@chromium.org>
* motion_sense: Fix init routinesGwendal Grignou2015-07-271-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | active state is global, remove it from motion_sensor structure. Reinit sensors when entering RW, fix regression introduced by CL:284616. Improve EC polling rate calculation by excluding suspended sensors. Wake up sensor thread in case the motion task was in deep sleep. Do not send sense interrupt while suspened. Will revisit once wakeup sensors are implemented. BRANCH=smaug TEST=Check when in RW the sensors are exposed. Check EC rate are correct in different power state. Check when jumping from RO to RW and back, after setting the frequencies parameters via sysfs properly, AndroSensor acquires the data properly. BUG=chrome-os-partner:43132,chrome-os-partner:40741 Change-Id: Ie70732b135a432d64935eead4200ddc0e1a7c0b4 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/288201 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* motion: Add sample frequency per sensorGwendal Grignou2015-07-151-7/+40
| | | | | | | | | | | | | | | | | | | | | Store at which frequency each sensor should be sampled. This frequency is different from the sensor frequency: - sensor frequency: frequency at which the sensor produce information. - sensor sampling frequency: frequency at the which the EC gater information. If 2 sensors must be sampled at very different frequency, we don't want to oversample the slow one, and filling the software FIFO unnecessarily. BRANCH=smaug TEST=Unit test. Check that frequency is correct when sensor frequencies change from IIO driver. BUG=chrome-os-partner:39900 Change-Id: I4272963413f53d4ca004e26639dc7a2affd317eb Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/284616 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* motion: FIFO: add lost per vector typeGwendal Grignou2015-07-151-0/+10
| | | | | | | | | | | | | | | | | | When FIFO overfills, keep track of the number of lost vectors per vector types. This way, when we calculate timestamps in user space, we can evaluate the number of empty slots to skip per vector type. This is important when different types are samples at very different frequencies. BRANCH=smaug TEST=Check that when we drop events, the timestamp are better than without. BUG=chrome-os-partner:39900 Change-Id: Ib9cb994ada38373e5a49dd4ba2123ca7534a169e Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/284615 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* driver: bmi160: Add FIFO and interrupt supportGwendal Grignou2015-07-101-0/+16
| | | | | | | | | | | | | | | | | | | Add FIFO support, where bmi160 hardware FIFO is copied in local fifo. Add rudimentary support for single/double tap and lift detection. BUG=chrome-os-partner:39900 BRANCH=smaug TEST=Check on F411 that FIFO data is retrieved and correct. Check on Smaug as well, with proper kernel the collect the FIFO: - check that increasing sampling_frequency we are collecting the FIFO less often - check no frames are lost. - check tap/lift interrupts are working - if latency is less than 100ms, check we are collecting much faster. Change-Id: Ic2317c27fad0ef31dacd6e18cd5f71ccd2cec807 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/274227
* driver: Use common data structure to store default accel valuesGwendal Grignou2015-05-121-4/+7
| | | | | | | | | | | | | | | Move structure used by lms6ds0 to motion_sense.h, so that bosh driver can use the same mechanism. Use code to avoid reading chip range when reading data. BUG=none BRANCH=none TEST=Check Bosh driver is working as expected. Change-Id: Id8b5bb8735e479a122ef32ab9a400fba189d7488 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/270453 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* motion: Add decoding for MOTION_CMD_DUMP v1 commandGwendal Grignou2014-11-181-19/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Samus: Split motion sense and lid angleGwendal Grignou2014-10-291-62/+17
| | | | | | | | | | | | | | | 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>
* Samus: move gesture to commonGwendal Grignou2014-10-291-0/+6
| | | | | | | | | | | | | | | | Move gesture to common directory, 1st step to be reused by other board. Cleanup motion_sense shutdown path. BUG=chrome-os-partner:33102 TEST=Double tap still works on Samus BRANCH=ToT Change-Id: I0a3b38c4a7dbe95c27dcdebff04c1176aaf932d1 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/225235 Reviewed-by: Sheng-liang Song <ssl@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org>
* samus: support sensor at different power state.Sheng-Liang Song2014-10-081-6/+18
| | | | | | | | | | | | | | | | | | | | | 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>
* [common]: Remove accelerator calibration code.Gwendal Grignou2014-09-251-22/+1
| | | | | | | | | | | | | | | | This code is used to find the orientation of the sensor. Given sensor are aligned with the edges of the device, it is not too dificult to find manually. BRANCH=ToT BUG=None TEST=Check ACCEL_CALIBRATE is not used anymore. Check 'make buildall -j' works. Change-Id: I81ffcb4f6b01c530ef16baf13113a5942f615092 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/219527 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* samus: added gyro support for lsm6ds0Sheng-Liang Song2014-08-261-4/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Refactor accel / gyro driver to accomodate various configurationsShawn Nematbakhsh2014-08-191-0/+16
| | | | | | | | | | | | | | | | | | | 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>
* accel: Add host cmd for setting lid angle threshold for disabling keyboard wakeAlec Berg2014-04-111-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* rambi: glimmer: Disable key scanning in suspend when lid is openAlec Berg2014-03-271-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* accel: clapper: glimmer: Add support for accelerometer interrupt.stabilize-5696.BAlec Berg2014-03-261-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | Adding in support for accelerometer interrupt for use currently in clapper and glimmer. This is disabled by default and can be enabled with CONFIG_ACCEL_INTERRUPTS. BUG=none BRANCH=rambi TEST=Manual test on a glimmer using accelint console command. On console enter: accelint 0 32 When you tap the lid, it should fire the interrupt and print msg to console. accelint 1 32 Tap the base and it will fire another interrupt. Change-Id: Iaab324945e34d527140399ec4f06efd812a62840 Original-Change-Id: I0329112fdcae3c8adc0ca07e74fef7a591d4b9a1 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/190099 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/191549
* rambi: Rotate accelerometer data into standard reference frameAlec Berg2014-03-011-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Added rotation of accelerometer data into a standard reference frame so that the host does not have to know about the orientation of the sensors. Also added a calibration routine to calibrate the rotation matrix to get to the standard reference frame. Cleanup up calibration in the process to make it more user friendly. Changed the default accelerometer sampling rate to 100Hz. BUG=chrome-os-partner:25599 BRANCH=rambi TEST=Tested the full calibration routine on a glimmer at my desk. Used 'taskinfo' and verified that the higher sampling rate does not bog down the EC. I found that the motion sense task is running for about 200ms every 10 seconds, so about 2% CPU load. Change-Id: I9ca1a4252f62a54016009c7d5e43b4cb1adf7e1d Original-Change-Id: Id554511f7cc9549dfc9ed2d6337216bfa639359d Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/187172 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/188385
* rambi: Add motion sense task to track motionAlec Berg2014-02-221-0/+71
Added motion sense task to Clapper and Glimmer. This task samples the accelerometers and calculate a lid angle. Note that as the machine is rotated towards the hinge angle aligning with gravity, the lid calculation becomes less trustworthy. Added a math_util file to hold various mathematical functions useful for calculating lid angle that may be helpful in other places. For each board with accelerometers we need to define some orientation specific data in board.c. There is a calibration procedure through the EC console that can be enabled by defining CONFIG_ACCEL_CALIBRATE. The calibration procedure can help determine the orientation data required. For debugging purposes there is a console command to regularly print to the EC console the accelerometer data and derived lid angle. The console command can be enabled by defining CONFIG_CMD_LID_ANGLE. BUG=none Original-BUG=chrome-os-partner:24703 BRANCH=rambi TEST=Ran the calibration procedure on a Glimmer unit, and then rotated the machine in space. Verified that the lid angle calculated roughly matched actual lid angle. Original-Change-Id: I63a5e384b7f6b628b4ea01de49843355fb8d6ebe Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/184783 Reviewed-by: Randall Spangler <rspangler@chromium.org> Signed-off-by: Alec Berg <alecaberg@chromium.org> (cherry picked from commit efb07945a5159fa0e7a746c666b2519ebdca9c22) Conflicts: board/clapper/board.c board/clapper/ec.tasklist board/glimmer/board.c board/glimmer/ec.tasklist Change-Id: Ibc492ef5c11e7084e87f01338c4d7775f9a08c18 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/187433 Reviewed-by: Randall Spangler <rspangler@chromium.org>
View Lorry Controller Status