summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Clear OWNERS for factory/firmware branchfirmware-smaug-7900.BBrian Norris2021-09-102-10/+1
| | | | | | | | | | | | BUG=none TEST=none Change-Id: I0f03f432ada1064ffba9595be78ca7ab4d25ecd1 Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3155248 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Owners-Override: Jora Jacobi <jora@google.com> Tested-by: Jack Rosenthal <jrosenth@chromium.org>
* pd: support Rp/Rp debug accessoriesVincent Palatin2017-01-202-27/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Support Rp/Rp debug accessories in the USB PD state machine including detecting the polarity and the available type-C current. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:52592 TEST=manual, plug a Suzy-Q reworked with Rp3A0/Rp1A5 resistors on a Kevin, and see the PD state machine is going to PD_STATE_SNK_ACCESSORY (and leaving it on unplug). Re-verify a few existing accessories (Rd/Rd SuzyQ, legacy RpUSB cable, Rp3A0 power supply). Reviewed-on: https://chromium-review.googlesource.com/368700 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org> (cherry picked from commit 1b9096116c9a82d9ab0beb5d5d983f9f12a14274) Change-Id: I1fb578395876e5f723caf154ae2d66ca92c9c659 Reviewed-on: https://chromium-review.googlesource.com/430610 Reviewed-by: Shawn N <shawnn@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit c210b2e57454a30084b5484af7adf51871e2620c) Reviewed-on: https://chromium-review.googlesource.com/430633 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: Limit input current to 500mA on PD voltage transitionShawn Nematbakhsh2017-01-204-3/+46
| | | | | | | | | | | | | | | | | | | | | | | | Upon requesting a PD power contract at a new voltage, keep the input current limit at 500mA until PD_RDY is received. BUG=b:30744563,chrome-os-partner:59311,chrome-os-partner:44340 BRANCH=ryu, gru, glados TEST=Manual on kevin, set ilim to 5V through `chglim` console command, attach zinger. Set ilim to 20V through `chglim`, verify that ilim goes from 3A to 500mA to 3A. Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: I452f183cfb958780e336a9f99dc6398356de17a0 Reviewed-on: https://chromium-review.googlesource.com/399918 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/430245 (cherry picked from commit 92b3623dad47f47e06168bc5f4a04417254b7028) Reviewed-on: https://chromium-review.googlesource.com/430632 Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* ryu: increase CHARGER task stack sizeVincent Palatin2015-12-041-1/+1
| | | | | | | | | | | | | | | | | | | | | We got one report from the field of an EC panic due to a stack overflow in the CHARGER task. I was not able to reproduce it or find the code path, but as we have free RAM, we can try to increase it a bit. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=smaug BUG=b:25977066 TEST=run 'taskinfo' on Smaug and see '4 CHARGER 00000000 1.103620 408/640' Change-Id: I443dca4cb2247de5c01b22f30f1e25965376588d Reviewed-on: https://chromium-review.googlesource.com/315702 Reviewed-by: Alec Berg <alecaberg@chromium.org> Trybot-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* driver: si114x: Unlock the device if stuckGwendal Grignou2015-12-012-1/+27
| | | | | | | | | | | | | | | | | | | | | | It is possible for the ALS state machine and the chip to not agree: The EC thinks the device is busy making a measurement, while the chip is waiting for the IRQ status register to be written. It is not clear how it happened, an IRQ must have been lost. Reinitiliazed the chip is stuck for 10s. BRANCH=smaug BUG=chrome-os-partner:45627 TEST=With an extra patch that force the IRQ handler to not do anything every 100th, check the device recovers. Use andro sensor to monitor light/proximity outputs. Change-Id: I80d50bf92af127f85f82dc5c0ae318d4cfe06812 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/313668 (cherry picked from commit 53fa1d1f0938f7021727880207631f2c9b82e115) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/314958
* motion: Set interrupt interval properly for sensor in force modeGwendal Grignou2015-12-011-6/+22
| | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 70915b501249017e4e962316bf178fd00d09e696) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/314957
* device: si114x: Address overflow conditionGwendal Grignou2015-12-012-1/+2
| | | | | | | | | | | | | | | | | | | | If proximity overflow (daylight), we would still assume the data was valid and consider there is an object very very close. That would prevent the light to be measured. (cl/312982) Leave the value as max range for the HAL to handle. BRANCH=smaug BUG=b:25573958 TEST=Check in daylight that light is still measured Change-Id: I684e6f4a9aecd3fd6b338a9939f7ede26752ecb8 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/314921 Reviewed-by: Alec Berg <alecaberg@chromium.org> (cherry picked from commit 02ddede08eb66c752b868c86293eff8fed9e8160) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/314956
* motion: At shutdown, access sensors only if initialized.Gwendal Grignou2015-12-011-2/+9
| | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit cef0fdb90e17fae3fd9f035bb6ada17e2833369e) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/314955
* lightbar: on tap sequence, only get battery percentage onceAlec Berg2015-12-011-11/+11
| | | | | | | | | | | | | | | | | | | | Change tap sequence so that it only gets the battery percentage once. This means we won't dynamically change color and level if the battery percentage changes mid sequence, but that's ok. BUG=chrome-os-partner:45878 BRANCH=none TEST=run tap sequence Change-Id: I2183343b69d01f4835302e291a2e1a0a2c658b1e Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/302685 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit 1c2bbee5c7a779cb22519e8710213a641b43eeff) Reviewed-on: https://chromium-review.googlesource.com/315126 Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Commit-Queue: Gwendal Grignou <gwendal@chromium.org> Tested-by: Gwendal Grignou <gwendal@chromium.org>
* motion: Fix the number of sample to collect in motion taskGwendal Grignou2015-11-251-1/+10
| | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 708f81e3d1d222270c697b5643760b1ca361b9f9) Reviewed-on: https://chromium-review.googlesource.com/313738
* motion: fix ec_rate to be more accurateGwendal Grignou2015-11-251-3/+3
| | | | | | | | | | | | | | | | | 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> (cherry picked from commit 68502864c7db47b0dae250600dec5531c5f35619) Reviewed-on: https://chromium-review.googlesource.com/313648
* ryu: add protection against BQ25892 resetting the current limitVincent Palatin2015-11-241-5/+12
| | | | | | | | | | | | | | | | | | | | | When the BQ25892 is done doing its 'USB' detection, it will reset the input current limit to the value set by the GPIOs. At this point, we are getting a charger interrupt, so we set PSEL GPIO to '1' to limit the current to 100mA until we have time to send the i2c message to set again the proper current limit. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=smaug BUG=chrome-os-partner:47972 TEST=plug Apple Macbook Type-C charger and various other chargers and record the current consumed through Twinkie. Change-Id: I66f9ebdff5386ce8547bcc009e4ea4b12ae8669a Reviewed-on: https://chromium-review.googlesource.com/314127 Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* motion: improve readability by adding units to variable names.Gwendal Grignou2015-11-201-21/+22
| | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 87a60df71f24aca95a485662e30a94076c75b0e0) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/313482
* motion: wake up main task for all changes in EC parameter.Gwendal Grignou2015-11-202-11/+16
| | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 9d7f1674460ce8e1a9c2fab79909cfd3bc856807) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/313481
* motion: Alter ec_rate to prevent samples without dataGwendal Grignou2015-11-201-9/+40
| | | | | | | | | | | | | | | | | | 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> (cherry picked from commit d98999f3685ddbd27af86e1d96f2af030af9beab) Reviewed-on: https://chromium-review.googlesource.com/313348
* motion: fix spellingGwendal Grignou2015-11-184-16/+16
| | | | | | | | | | | | | | | | | | | | | 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, check only comments and one prinft are changed. 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> (cherry picked from commit c8844123923f8b65f38a7d16aaac3e9ce774ce2c) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/313152
* motion: Change units of ec_rate from us to ms.Gwendal Grignou2015-11-184-25/+25
| | | | | | | | | | | | | | | | To ease finer calculation of ec rate change units from ms to us. BRANCH=smaug BUG=b:24367625 TEST=compile, run run-motion_lid Change-Id: I52057c8ca1b1180a64b58d1ba0af9ec53f40b026 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/312984 (cherry picked from commit 420099f74976b3af1f4b24dc24b9fec461b1037b) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/313151
* motion: add config option to use the old accelerometer ref frameAlec Berg2015-11-1811-86/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | Add config option to use the old accelerometer reference frame, which is used on samus and products using 3.14 or earlier kernel. This fixes samus so that the lid angle calculation is correct again. This also moves the accel_orientation structure out of the board directory and into common code, since it purely is a function of the reference frame being used. BUG=chrome-os-partner:43494 BRANCH=none TEST=test on samus, verify lid angle calculation is correct once again. also, enable the motion_lid test and verify that it passes. Change-Id: I948a74a71964b54c68be66e828a030ddd0418947 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/300510 Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> (cherry picked from commit 5717b3150c8a8d43e07ce2dc8065c3515d3651f7) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/313150
* driver: si114x: Do not read light when proximty is lowGwendal Grignou2015-11-182-0/+16
| | | | | | | | | | | | | | | | | | | | If the proximity sensor indicates there is an object very close (<= 5cm), ignore light sensor readings. Otherwise, when someone put their finger on the sensor, the light sensor would most likely report dark condition and the screen brightness will be lowered unexpectedly. BUG=b:25573958 BRANCH=smaug TEST=check light report does not change when proximity sensor reports < 5cm, using androsensor apps. Change-Id: I16db40766a71a7925e28372ebb54ae43f60a4989 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/312982 (cherry picked from commit cfae64d5ded2b51fd6892dbd1084abda7f503c20) Reviewed-on: https://chromium-review.googlesource.com/312996
* motion: fix oversampling formulaGwendal Grignou2015-11-142-42/+33
| | | | | | | | | | | | | | | | | | 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> (cherry picked from commit ef094bdf65d5c04120a6b37fa4d678b478e520cd) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/312567
* ryu: disconnect usb switches until connection is debouncedAlec Berg2015-11-131-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Re-order logic in BC1.2 detection task so that we open the USB switches immediately upon detecting a connection, then debounce the connection, then reset the pericom and determine BC1.2 charger type. This fixes two problems: - Problem where host would enumerate ryu, detect disconnect, and then re-enumerate. - Problem where sometimes ryu would detect a host workstation as a proprietary charger because we weren't delaying long enough after opening USB switches before triggering pericom reset. BUG=chrome-os-partner:47219 BRANCH=smaug TEST=tested by connecting workstation to ryu (tested both pluggin in A side first and C side first). Without this patch, my workstation often see's disconnect and reconnect. With this change we only get one connect. Change-Id: Ib75a1905c528063316c6a4649d9cf1b71b059c6a Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/311853 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* motion: minium interval between motion task now a variableGwendal Grignou2015-11-134-8/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 66a72f0b6e379edc3a2a52fa2e9b0f66c557a447) Reviewed-on: https://chromium-review.googlesource.com/312700
* common: lightbar: update leds when neededGwendal Grignou2015-11-131-23/+32
| | | | | | | | | | | | | | | | | | In S0 state, update leds only when needed: add a variable in get_battery_level to indicate the colors need to be changed. BRANCH=smaug BUG=b:25510300 TEST=Check the traffic on the i2c bus notice less traffic coming from lightbar task in S0. Change-Id: I22dce35edd794424f6fbb607a0dbb495eb308897 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/311756 Reviewed-by: Alec Berg <alecaberg@chromium.org> (cherry picked from commit b59fa8ca68ca20c60c9fbe099209a5e38ee5b99e) Reviewed-on: https://chromium-review.googlesource.com/312466
* motion: cleanup include fileGwendal Grignou2015-11-133-8/+5
| | | | | | | | | | | | | | | | 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> (cherry picked from commit 0922cc81ce22204264a2b96cec4bf2195939e516) Reviewed-on: https://chromium-review.googlesource.com/312574
* ryu: increase USB_CHG task stack sizeVincent Palatin2015-11-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | the USB_CHG task is running dangerously close to its stack limit: commonly 352/384 bytes, when running sensor heavy code in parallel with USB plug/unplug : 368/384 bytes. As we have free RAM, let's increase the stack size from 384 to 488 bytes. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=smaug BUG=b:25510300 TEST=taskinfo after running sensor testing app and plugging/unplugging a zinger. Change-Id: Icb20a40add10b141362cf688680eaeedf975f4e8 Reviewed-on: https://chromium-review.googlesource.com/311300 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* tegra: use long press for power-onVincent Palatin2015-11-091-2/+29
| | | | | | | | | | | | | | | | | | Switch from using a short power button press to a long 2-second press to power-on the product. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=smaug BUG=b:25523378 TEST=manual: press the power button for various period and observe the EC console. Change-Id: Ib61f0a538986cfde6bfcd2f730be847c544874a5 Reviewed-on: https://chromium-review.googlesource.com/311720 Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* ryu: ensure bc1.2 suppliers get cleared on charger disconnectAlec Berg2015-11-031-23/+23
| | | | | | | | | | | | | | | Manually clear bc1.2 suppliers when VBUS transitions low to make sure the suppliers don't get stuck on. BUG=b:25209438 BRANCH=smaug TEST=make BOARD=smaug Change-Id: Ia5552213a3f2b6d539a5c8648117eec458115325 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/309918 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* driver: bmm150: Add ability to smooth data from compass.Gwendal Grignou2015-11-036-4/+99
| | | | | | | | | | | | | | | | | To fight the noise inside the device, implement a low bypass filter using the exponential moving average method. http://en.wikipedia.org/wiki/Moving_average#Exponential_moving_average Define only for axis that need it. BRANCH=smaug BUG=chrome-os-partner:45436 TEST=Using androsensor, check the data on the X and Z axis is smoother. Change-Id: I1724375d0ed92dfe9066db5d710ece30af56d578 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/309966 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* stm32f3: i2c: For Ryu, set all i2c port frequency to 48MHzShawn Nematbakhsh2015-11-032-26/+12
| | | | | | | | | | | | | | | | | | | | | *** Do not merge to master: revert with crbug.com/549286 changes. *** stm32f3 parts allow the i2c2 clock source to be selected from HSI or SCLK. It was set by default to HSI; on Ryu we could not get 1MBps speed between the AP and the EC. For Ryu, remove the logic to set the speed base on low power idle mode: low power mode implied using HSI clock with is not right. BUG=chrome-os-partner:39233 BRANCH=smaug TEST=Manual on Smaug: check the i2c clock is set correctly. Change-Id: I9db513afabf23f844f68c1edc7a4910833d1f886 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/309965 Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* stm32: i2c: Use correct timingr values based on clock sourceShawn Nematbakhsh2015-11-031-5/+5
| | | | | | | | | | | | | | | | | | | Previous change 813e56e10af4 broke this by interchanging the values. BUG=chrome-os-partner:46188 BRANCH=None TEST=`make buildall -j` Change-Id: I9a66949b66e0d6736c007773740b4f7431faa3cc Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/310057 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> (cherry picked from commit 792d00184ab5f50af52b64e9c60cd01bc1b01fc7) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/310259
* stm32f0: i2c: Set timing register values by port clock sourceShawn Nematbakhsh2015-11-032-31/+58
| | | | | | | | | | | | | | | | | | | | I2C1 may be clocked by HSI or SCLK. I2C2 is always clocked by PCLK. Therefore, apply different timing register values according to the selected clock source for a port. BUG=chrome-os-partner:46188 BRANCH=None TEST=Manual on glados_pd. Verify slave i2c communication is functional. Change-Id: Icd2306d25d5863b0fc3379e46885a227efb23cca Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/309781 Commit-Ready: Gwendal Grignou <gwendal@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> (cherry picked from commit 813e56e10af48dc010dc629cb6d0c37efcb995dd) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/309964
* stm32: i2c: Add timings for 8MHz i2cclkShawn Nematbakhsh2015-10-301-4/+18
| | | | | | | | | | | | | | | | | | | | | | Use the datasheet-specified 8MHz i2c timings, which are different from the 48MHz timings. BUG=chrome-os-partner:46188 BRANCH=None TEST=Probe glados_pd i2c signals, verify that clock isn't stretched ~2us on every bit received by slave. Change-Id: Id6a07bc364163c2efc61c3115043f48a79027010 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/305714 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> (cherry picked from commit db77cafb3e254e95139949d5931554dd4a4d9f0c) Reviewed-on: https://chromium-review.googlesource.com/310030 Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Commit-Queue: Gwendal Grignou <gwendal@chromium.org> Tested-by: Gwendal Grignou <gwendal@chromium.org>
* motion: Remove duplicate shutdown codeGwendal Grignou2015-10-294-18/+10
| | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 21c46e7b1300022fcee1e5997b3e9293c47c27ea) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/309597
* driver: si114x: Fail init of proximity sensor if light sensor fails.Gwendal Grignou2015-10-292-1/+4
| | | | | | | | | | | | | | | | | | | If init of the light sensor fails (for instance, the chip is not present on the i2c bus), we need to fail the init of the proximity sensor. Otherwise, the EC will report an unexistent sensor to the AP. BRANCH=smaug BUG=chrome-os-partner:46638 TEST=check the proximity sensor is not reported if sensor is disconnected from the main board. Change-Id: Ie6b1d74eaac4d6c38d52641626966b5d3ce63bd3 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/308560 Reviewed-by: Alec Berg <alecaberg@chromium.org> (cherry picked from commit 7253e57b3c5f415d53558d8e8266c70ff42975a7) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/309596
* driver: bmi160: Add magic sequence to unlockGwendal Grignou2015-10-291-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | If init() is interrupted while we are setting the link to the compass, the BMI160 may be in paging mode and will only answer to registers 7Eh and 7Fh. Other registers access will return 00h. To get out of this state, run the sequence to move back from the paging mode in the error handler. If successful, a subsequent call to init() will work. BRANCH=smaug BUG=chrome-os-partner:45722 TEST=use a special firmware that exists in the middle of the compass init sequence. Check that the FIFO and all other registers return 0. Issue 'accelinit 1' (to reset the Gyro): the command succeeds and the accelerometer is operational again (double tap works). Check the sequence can be issued after sysjump to RW/RO. Change-Id: I3455a8cbdcf1c88699ae90f7c09e4438e1268d47 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/308184 Reviewed-by: Alec Berg <alecaberg@chromium.org> (cherry picked from commit 8238dfa27d9c6c52dfd72b0328115e49b5c3496d) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/309595
* common: lightbar: Add histeresis to prevent flickeringGwendal Grignou2015-10-296-23/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 (cherry picked from commit 81d269dc004b6c7334e4e8eafbb2872e5b6fdcf1) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/309594
* board: ryu: Compass and Gyro stays up in S5Gwendal Grignou2015-10-291-2/+2
| | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 3fc374b7fd8b618d513db27d9f10c8200f603e15) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/309593
* common: Add lightbar dimming based on outside light.Gwendal Grignou2015-10-296-7/+96
| | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 7340e804a1e3ffba2f1ffb9bf826a33b8b5fb19c) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/309592
* lightbar: define primary colorsGwendal Grignou2015-10-291-9/+18
| | | | | | | | | | | | | | | | Use defines for color entries 4 - 7. BRANCH=smaug BUG=none TEST=compile Change-Id: I2fe9b286adbb4e2cc471320ccd3d0437b451a7cc Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/306787 Reviewed-by: Alec Berg <alecaberg@chromium.org> (cherry picked from commit fb6e6a4b410eff13961437d9a28fe86b222e3ef1) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/309591
* motion: fix manage_activity interfaceGwendal Grignou2015-10-293-3/+3
| | | | | | | | | | | | | | | | | 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> (cherry picked from commit fcfd32f04a58e1baf54b39d97c7b37eabb0770db) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/309590
* pd: fix PD polling in S5Vincent Palatin2015-10-281-2/+2
| | | | | | | | | | | | | | | | | | | | Fix the condition to decide the CC polling delay in the USB PD state machine. In S3, 'drp_state' is PD_DRP_TOGGLE_OFF (ie we do not toggle but still provide power to sink/UFP), while in S5 'drp_state' is PD_DRP_FORCE_SINK (never behaves as a source). We need to do slow polling in both of those cases. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=smaug BUG=none TEST=measure power consumption in S5 on Ryu. Change-Id: I4654a30f62d660e5a20ff27dca917f615e891996 Reviewed-on: https://chromium-review.googlesource.com/309604 Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* ryu: fix lid close detectionVincent Palatin2015-10-231-1/+1
| | | | | | | | | | | | | | | | | | | | | Now we are using LID_OPEN *and* BASE_PRES_L for lid close detection, we need an interrupt on both to debounce arbitrarily long delay between the transitions of the 2 GPIOs. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=smaug BUG=chrome-os-partner:46189 TEST=manual: activate manually LID_OPEN and BASE_PRES_L hall sensors in very slow sequences and see the proper "lid close"/"lid open" traces, whatever sequence I do. Change-Id: Id170c1a6a46d36aee658f6b01f974887c597ddf1 Reviewed-on: https://chromium-review.googlesource.com/308513 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>
* ryu: do not pull EN_PP3300Vincent Palatin2015-10-231-1/+1
| | | | | | | | | | | | | | | | | | | | | 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>
* motion: reenable double tap in S5.Gwendal Grignou2015-10-161-0/+23
| | | | | | | | | | | | | | | | Double TAP must be enabled in S5, but not while shipping. Unconditionnaly enable double tap in S5, but only when running RW image. BRANCH=smaug BUG=chrome-os-partner:46572 TEST=Check double tap is working after unit has been powered down. If the EC runs RO image, double tap not working when device powered down. Change-Id: Ia5bc095c6cb8e6fb4cea16238cff7f1c183432ea Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/306680 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* motion: Add timestamp in ODRGwendal Grignou2015-10-161-9/+17
| | | | | | | | | | | | | | | | | 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> (cherry picked from commit 0174b9a21d0764bf32243cf23a3f138bf44e5938) Reviewed-on: https://chromium-review.googlesource.com/306373
* driver: bmm150: Use Bosch recommend repetitionGwendal Grignou2015-10-162-2/+4
| | | | | | | | | | | | | | | | To minimize noise, instead of using recommend preset from the documentation, use specific repetition value. BRANCH=smaug BUG=chrome-os-partner:45436 TEST=Check the noise is somewhat reduced, still not great. Change-Id: I0ed3409dd907fa1e393d1eb77b6f23ff03763e53 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/305588 Reviewed-by: Alec Berg <alecaberg@chromium.org> (cherry picked from commit 50b1a9de02ab8149a43099abd0c68bcac0a420eb) Reviewed-on: https://chromium-review.googlesource.com/306187
* common: motion: Fix forced mode computationGwendal Grignou2015-10-163-15/+23
| | | | | | | | | | | | | | | | | | | | | | | | 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/306107
* Revert "driver: bmi160: Reenable FIFO when EC wants it."Gwendal Grignou2015-10-151-5/+2
| | | | | | | | | | | | | | | | | This change introduces unnecessary power consumption in S3/S5. Given the EC does not need the data by itself - except for debugging with accelinfo/accelread commands - do not setup the FIFO if the AP does not need the data. BUG=chrome-os-partner:44229 This reverts commit ebf3934dc62a8d9c391dd0abf4998da42b1192e9. Change-Id: I3a38645b88dd031b7580cc06fd5e31606f99e36a Reviewed-on: https://chromium-review.googlesource.com/306180 Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Gwendal Grignou <gwendal@chromium.org> Tested-by: Gwendal Grignou <gwendal@chromium.org>
* common: Add magnetometer online calibration.Gwendal Grignou2015-10-1418-19/+706
| | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 828b55a7358ad5ec8bc27552bfb280eb173dd453) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/305382
* smaug: fix mag orientation: Z is pointing downwardGwendal Grignou2015-10-141-3/+3
| | | | | | | | | | | | | | | | | 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> (cherry picked from commit 0647f66f81de880af603a7fb70f57159519782ac) Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/305381
View Lorry Controller Status