summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* virtual_battery: bug fix in reading SB_AVERAGE_CURRENTfirmware-scarlet-10388.BIkjoon Jang2021-09-113-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | Fix a bug from CL:2747559, virtual battery returns an error for SB_AVERAGE_CURRENT. virtual battery handler should call battery_get_avg_current(), not battery_get_avg_voltage(). BRANCH=none BUG=b:170921599 TEST=read current_avg knob in kukui Signed-off-by: Ikjoon Jang <ikjn@chromium.org> Change-Id: I90c26a8e1d4fa6faccc0166b9f7b63fca9baef51 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2751320 Reviewed-by: Ting Shen <phoenixshen@chromium.org> (cherry picked from commit ffbc67dcac2d03bc5967627ebd9dba37e7013e5a) Conflicts: include/battery.h [skip over the bit for missing BATT_FLAG_IMBALANCED_CELL] Change-Id: I98f2e9d8c6004abf148da78bb6e965a4f9f66964 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3154566 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Commit-Queue: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org>
* virtual_battery: add a few more propertiesIkjoon Jang2021-09-111-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recent version of kernel sbs-battery driver has properties currently unsupported by EC.This patch adds 4 more properties to remove annoying error messages from console: "power_supply sbs-12-000b: driver failed to report xxx" in kernel, "[3927380.033752 Unhandled VB reg 1b" in EC console. New properties added : - SB_AVERAGE_CURRENT(0xb): involves i2c transaction - SB_MAX_ERROR(0xc): returns a constant 3% - SB_CHARGING_CURRENT(0x14), SB_CHARGING_VOLTAGE(0x15): returns existing battery params BRANCH=none BUG=b:170921599 TEST=read properties from sbs sysfs knobs (current_avg capacity_error_margin constant_charge_current_max constant_charge_voltage_max) Change-Id: I681006899969da8466730eda155df935af22994f Signed-off-by: Ikjoon Jang <ikjn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2747559 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> (cherry picked from commit ed5f46d3a7d931f6f2aed9ccfc2edbb4f0fb6576) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3153586 Commit-Queue: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org>
* virtual_battery: support reading DeviceChemistryIkjoon Jang2021-09-111-0/+3
| | | | | | | | | | | | | | | BUG=b:170921599, b:197184697 TEST=check sbs-battery from host side BRANCH=None Signed-off-by: Ikjoon Jang <ikjn@chromium.org> Change-Id: I1cae097f8056569c00a284cfbff56483a7ba4387 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2491589 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> (cherry picked from commit db27b92f6221b02dfd95aa17f06b6b9339352a6e) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3153631 Commit-Queue: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org>
* virtual_battery: support reading SpecificationInfoIkjoon Jang2021-09-111-0/+5
| | | | | | | | | | | | | | | | BUG=b:170921599, b:197184697 TEST=check sbs-battery from host side BRANCH=None Signed-off-by: Ikjoon Jang <ikjn@chromium.org> Change-Id: I0308fda8d34a0920782dd1de8d43ffc90f059a49 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2491588 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-by: Diana Z <dzigterman@chromium.org> (cherry picked from commit 0516b73d8a01243767a0615deffd272a2843bcff) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3153632 Commit-Queue: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org>
* virtual_battery: Return manufacture dateDouglas Anderson2021-09-111-0/+15
| | | | | | | | | | | | | | | | | | | | | Newer kernels seem to request the date and if we don't have something here we get constant spam on the EC console saying "Unhandled VB reg 1b". Let's return the manufacture date in the Smart Battery Spec format, or 0 on error. BUG=b:160784792 TEST=No more spam. BRANCH=none Change-Id: I38e75d467d722b7f14ec74ec38ec68cebe6c8ed9 Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2300459 (cherry picked from commit 771b693157b92049820f5161a0bf74d19de14e0b) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3154565 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Commit-Queue: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org>
* battery: Expose battery_manufacture_date() as APIWai-Hong Tam2021-09-114-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The newer kernels request this data. Add the battery_manufacture_date() as a new API. Checked the TRMs of the following batteries. They don't have any way to query the manufacture date, so return EC_ERROR_UNIMPLEMENTED. * bq27541 * bq27621_g1 * max17055 * mm8013 BRANCH=None BUG=b:160784792 TEST=Hacked to print the manufacture date, on both battery present and not. Change-Id: I1deefb64f6cc594828d6c10c42fa7107dadd7559 Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2300689 Commit-Queue: Douglas Anderson <dianders@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> (cherry picked from commit 0b48d88cc8cf085ece95dc9ebf66b8a07eb72696) Conflicts: driver/battery/mm8013.c [missing in scarlet branch] Change-Id: I92fa46c4ded590d5286ef28f4c0209b72eb9b223 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3154564 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Commit-Queue: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org>
* battery: Fix obtaining battery manufacture dateWai-Hong Tam2021-09-112-6/+6
| | | | | | | | | | | | | | | | | | | | * Fix the typo: should be SB_MANUFACTURE_DATE (manufacture without r) * Fix the register, i.e. SB_MANUFACTURE_DATE, not SB_SPECIFICATION_INFO * Fix the format parsing. The LSB of year is bit-9, not bit-8. BRANCH=None BUG=b:160784792 TEST=With the later CL, checked the manufacture date. Change-Id: I5b5f2bfefec4bbe700bb1ec0d9d6048123f4ad16 Signed-off-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2300688 Reviewed-by: Douglas Anderson <dianders@chromium.org> (cherry picked from commit a5a82418126ee6cadff69d9487c43edc1ccea097) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3154563 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Commit-Queue: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org>
* virtual_battery: return errors on bad battery flagsTing Shen2021-09-111-0/+18
| | | | | | | | | | | | | | | | | | | | | Stop virtual_battery_handler from sending random values to host and make userland programs panic. BUG=b:144195782 TEST=UI never shows incorrect battery level. BRANCH=kukui Change-Id: Ia1ce4d6806db70cd3b189acdf1df4f865e5f8076 Signed-off-by: Ting Shen <phoenixshen@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1972161 Reviewed-by: Eric Yilun Lin <yllin@chromium.org> Commit-Queue: Ting Shen <phoenixshen@chromium.org> Tested-by: Ting Shen <phoenixshen@chromium.org> (cherry picked from commit 29ef57b1bc1b5dd7713f6ab42edb4646f2be756d) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3154562 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Commit-Queue: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org>
* Clear OWNERS for factory/firmware branchBrian 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/+/3155239 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Owners-Override: Jora Jacobi <jora@google.com> Tested-by: Jack Rosenthal <jrosenth@chromium.org>
* stm32: Fix manual interrupt clearing functionCraig Hesling2020-03-171-1/+3
| | | | | | | | | | | | | | | | | | | | | This fixes a bug in gpio_clear_pending_interrupt, where all pending interrupts are unintentionally cleared. This is not in the code path for normal gpio interrupt handlers, since the normal interrupt clearing occurs in gpio_interrupt (right below this function). BRANCH=none BUG=chromium:1059520 TEST=none Signed-off-by: Craig Hesling <hesling@chromium.org> Change-Id: I4d6fe7947f4d76cf3b57dfbf3bb926e41851c80c Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2101208 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> (cherry picked from commit c2c2c083fef813e3e3c70f8c13a1418717ba682d) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2107662
* Scarlet: Battery swelling potectionBen Chen2019-02-131-0/+47
| | | | | | | | | | | | | | | | | | | | Change charge voltage for aged battery (based on cycle count) Change charge voltage for long duration charging (AC-IN > 48 hrs) BRANCH=scarlet BUG=b:118799175 TEST=modify cycle count manually as 300/600/1000: the charge voltages match the table: 4376/4320/4300mV. TEST=plug in AC for longer than 48hrs: the charge voltage is 4.25V. Change-Id: I27660d0efff9724657e9fcfaee8edee1bf619eb8 Signed-off-by: Ben Chen <ben.chen2@quanta.corp-partner.google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1442392 Reviewed-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Philip Chen <philipchen@chromium.org>
* bmi160: Keep timestamp and FIFO synchronizedEnrico Granata2019-02-081-9/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The BMI160 will clear the FIFO watermark/full interrupt when the FIFO crosses the threshold condition - which happens upon reading from it in load_fifo(). As a result of this, and the fact that the soft IRQ handler for the BMI160 tries to loop until it has finished serving all interrupt causes, there are possibilities for a race condition such as the following to occur: read timestamp, value is t0 read interrupt cause: it's a watermark interrupt load fifo(t0): this clears the interrupt, allowing a new one to happen read timestamp, value is still t0 a watermark interrupt happens at t1 read interrupt cause: watermark load fifo(t0) At this point, the fifo will process events at t1 as-if they had happened at t0, which is bad and causes incorrect timestamps on the AP side. This changes moves reading the timestamp value as close as possible to load_fifo, and in a relative order where a new watermark interrupt cannot happen, which ensures the timestamp and the FIFO data for it are synchronized BUG=b:120508077 TEST=on Bobba and Nocturne, observe that no events happen where an identical "a" time matches two distinct (b,c) times BRANCH=nocturne,bobba Change-Id: I454b257366bccf2b9e4d78df5dc005a8ad7313a0 Signed-off-by: Enrico Granata <egranata@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1367013 Reviewed-by: Alexandru M Stan <amstan@chromium.org> Reviewed-by: Diana Z <dzigterman@chromium.org> (cherry picked from commit e5fc358df19e1c4147d35749b6ddf91e22cebbf2) Reviewed-on: https://chromium-review.googlesource.com/c/1380711 Reviewed-by: Gwendal Grignou <gwendal@google.com> Reviewed-by: Philip Chen <philipchen@chromium.org>
* scarlet: Lower the charging voltagePhilip Chen2019-01-241-2/+2
| | | | | | | | | | | | | | | | | | | The battery spec states the maximal charging voltage is 4.42V. Considering +-1% of voltage accuracy from rt9467, we should lower the charging voltage to ensure it never hits 4.42V. BUG=b:118799175 BRANCH=scarlet TEST=make BOARD=scarlet Change-Id: I8a2f01d64ccb0750b1d5e4d4af586faf307d7b9d Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1432916 Reviewed-by: Philip Chen <philipchen@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Philip Chen <philipchen@chromium.org>
* chip/stm32/clock: Cleanly clear pending RTC alarm IRQPhilip Chen2019-01-111-0/+3
| | | | | | | | | | | | | | | | | | | | We want to reset RTC alarm and clear pending IRQ when EC wakes up from deep sleep mode. Unfortunately, RTC alarm IRQ is still latched and pending in NVIC unless we explicitly clear the flag in ICPR register. BUG=chromium:769503 BRANCH=scarlet TEST=confirm RTC alarm irq is not fired after EC exits deep sleep mode Change-Id: If6b9815337fbd24a0337116ef9c5fa1521671a93 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1392408 Reviewed-by: Philip Chen <philipchen@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Philip Chen <philipchen@chromium.org>
* chip/stm32/clock: Enable STOP mode when the host sets wake alarmPhilip Chen2019-01-114-42/+121
| | | | | | | | | | | | | | | | | | | | | | BUG=chromium:769503 BRANCH=scarlet TEST=make buildall -j TEST=On scarlet: 1) 'powerd_dbus_suspend --wakeup_timeout=10' on AP console. 2) When AP is in S3, confirm ec enters STOP mode by 'idlestat'. 3) Confirm AP still wakes up at the right time. Change-Id: I0ce60cc6c33cb475b3311de83c35fe73ff92641b Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/706537 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> (cherry picked from commit 2d4116498333af946497ef9445f721d8a3e82e9e) Reviewed-on: https://chromium-review.googlesource.com/c/1407231 Reviewed-by: Philip Chen <philipchen@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Trybot-Ready: Philip Chen <philipchen@chromium.org>
* Revert "Reland "scarlet: Limit the maximal acceptable VBUS to 5.5V""Philip Chen2019-01-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 5b27eb1ae048f0fbfeb152c2b9bd1f1da2015ef7. Reason for revert: b:78792296 Original change's description: > Reland "scarlet: Limit the maximal acceptable VBUS to 5.5V" > > This reverts commit b86950f867d97834f9e800e835921d57d391f883. > > Reason for revert: b:78792296 > > Original change's description: > > Revert "scarlet: Limit the maximal acceptable VBUS to 5.5V" > > > > This reverts commit c4e728e6f991537b5e0f715c4f9e946b029d5bd8. > > > > BUG=b:78792296 > > BRANCH=scarlet > > TEST=none > > > > Change-Id: I4dc73e85cc7883ef4b2ab83da4d671a7709d9fd3 > > Signed-off-by: Philip Chen <philipchen@google.com> > > Reviewed-on: https://chromium-review.googlesource.com/1034105 > > Reviewed-by: Brian Norris <briannorris@chromium.org> > > Commit-Queue: Philip Chen <philipchen@chromium.org> > > Tested-by: Philip Chen <philipchen@chromium.org> > > Trybot-Ready: Philip Chen <philipchen@chromium.org> > > Bug: b:78792296 > Change-Id: I848fbb1027916b265e5d6531c33404a163c1364e > Reviewed-on: https://chromium-review.googlesource.com/c/1379731 > Reviewed-by: Philip Chen <philipchen@chromium.org> > Commit-Queue: Philip Chen <philipchen@chromium.org> > Tested-by: Philip Chen <philipchen@chromium.org> > Trybot-Ready: Philip Chen <philipchen@chromium.org> Bug: b:78792296 Change-Id: I9e7b5cff36ffc0bc3a16a96f221e4da04b7c375c Reviewed-on: https://chromium-review.googlesource.com/c/1383272 Reviewed-by: Philip Chen <philipchen@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Philip Chen <philipchen@chromium.org>
* Reland "scarlet: Limit the maximal acceptable VBUS to 5.5V"Philip Chen2018-12-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit b86950f867d97834f9e800e835921d57d391f883. Reason for revert: b:78792296 Original change's description: > Revert "scarlet: Limit the maximal acceptable VBUS to 5.5V" > > This reverts commit c4e728e6f991537b5e0f715c4f9e946b029d5bd8. > > BUG=b:78792296 > BRANCH=scarlet > TEST=none > > Change-Id: I4dc73e85cc7883ef4b2ab83da4d671a7709d9fd3 > Signed-off-by: Philip Chen <philipchen@google.com> > Reviewed-on: https://chromium-review.googlesource.com/1034105 > Reviewed-by: Brian Norris <briannorris@chromium.org> > Commit-Queue: Philip Chen <philipchen@chromium.org> > Tested-by: Philip Chen <philipchen@chromium.org> > Trybot-Ready: Philip Chen <philipchen@chromium.org> Bug: b:78792296 Change-Id: I848fbb1027916b265e5d6531c33404a163c1364e Reviewed-on: https://chromium-review.googlesource.com/c/1379731 Reviewed-by: Philip Chen <philipchen@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Philip Chen <philipchen@chromium.org>
* scarlet: Throttle PD voltage regardless of power statePhilip Chen2018-12-141-15/+2
| | | | | | | | | | | | | | | BUG=b:78792296 BRANCH=scarlet TEST=manually on dru Change-Id: Ic5f20cdbeee113a4e1609d7eb9d1b2c1b2c07f25 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1378765 Reviewed-by: David Schneider <dnschneid@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Philip Chen <philipchen@chromium.org>
* chipset: Provide default chipset_in_or_transitioning_to_statePhilip Chen2018-11-211-0/+5
| | | | | | | | | | | | | | | | | | | If HAS_TASK_CHIPSET is not defined, common/power.c is not compiled. So provide a default implementation which indicates the chipset is always off. BUG=b:119846880 BRANCH=scarlet TEST=emerge-scarlet chromeos-ec Change-Id: Ieb123bb27f088b3ec6b138b56db39a0d46016718 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1345914 Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Philip Chen <philipchen@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* scarlet: Limit PD voltage when battery SOC > 85%Philip Chen2018-11-201-1/+1
| | | | | | | | | | | | | | | BUG=b:78792296 BRANCH=scarlet TEST=manually on dru Change-Id: I6d9dc55128f0d59da207d6377a101f41f492e0af Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1344799 Reviewed-by: David Schneider <dnschneid@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Philip Chen <philipchen@chromium.org>
* power/rk3399: Remove unused power_seq_versionPhilip Chen2018-11-202-18/+12
| | | | | | | | | | | | | | | | | | The current power_seq_version 1 is only for Scarlet rev0, which is not supported anymore. BUG=b:119617491 BRANCH=scarlet TEST=manually test on dru, confirm S5->S0->S5 and S0->S3->S0 still work fine Change-Id: I0784cecddd3911f057998eb21b8edb5c577431e5 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1344797 Reviewed-by: Philip Chen <philipchen@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Philip Chen <philipchen@chromium.org>
* scarlet: Consider power state transition when throttling PDPhilip Chen2018-11-201-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When battery level changes or board suspend/resume, we call a hook function, board_pd_voltage(), to check the chipset power status and battery level. If the device is in S3 or S5 and the battery SOC > 90%, we limit PD voltage to 5V. However, during S0->S3 transition, there is a delay of 40+ milliseconds between hook_notify(HOOK_CHIPSET_SUSPEND) and the chipset power status really turning into S3. Assuming the battery SOC = 95% and the device is in S0, here is what can happen: (1) Scarlet wants to suspend (S0->S3). (2) board_pd_voltage() is called and checked chipset power status. (3) Scarlet decides to not limit PD voltage because it finds the power status is still S0S3. (4) Scarlet finally enters S3, but PD voltage doesn't get limited, even though all conditions meet. So we should go ahead to limit PD voltage when the battery SOC > 90% and the power state is S0S3. BUG=b:78792296 BRANCH=scarlet TEST=Put a dru in S0 with full battery power: (1) Do S0->S5->S0, see PD voltage do 9V->5V->9V. (2) Do S0->S3->S0, see PD voltage go 9V->5V->9V. Change-Id: I1c2b823a3ac6dd7d6938ef7a76cf26931a50dea0 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1338601 Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Philip Chen <philipchen@chromium.org>
* Revert "max17055: Invalidate all batt info when batt not present."Philip Chen2018-11-201-13/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 319ae8c6240f698574163388a197b0b24b9d66db. Reason for revert: It's probably not a good ideas to clear battery params every time battery_get_params() is called. Otherwise funky things may happen - see the bug links. BUG=b:119322063, b:73347743 Original change's description: > max17055: Invalidate all batt info when batt not present. > > BUG=b:117061273 > TEST=on kukui, remove batt, connect pd, see battery output in console > > battery > Status: 0x0000 > Param flags:000007fc > Temp: 0x0000 = 0.0 K (-273.1 C) > V: 0x0000 = 0 mV > V-desired: 0x0000 = 0 mV > I: 0x0000 = 0 mA > I-desired: 0x0000 = 0 mA > Charging: Not Allowed > Charge: 0 % > Manuf: <unkn> > Device: <BATT> > Chem: <unkn> > Serial: 0xffffffff > V-design: 0x0f14 = 3860 mV > Mode: (unsupported) > Abs charge:(unsupported) > Remaining: 6334 mAh > Cap-full: 6910 mAh > Design: 6910 mAh > Time-full: 0h:0 > Empty: 102h:23 > TEST=on connect batt, connect pd, see battery output in console > BRANCH=None > > Change-Id: Ied338266fa0f7713da408438460bc97d4db01e6f > Signed-off-by: Yilun Lin <yllin@google.com> > Reviewed-on: https://chromium-review.googlesource.com/1253372 > Commit-Ready: Yilun Lin <yllin@chromium.org> > Tested-by: Yilun Lin <yllin@chromium.org> > Reviewed-by: Philip Chen <philipchen@chromium.org> > Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> > (cherry picked from commit fbb47e2bc63c1b84e1509b50e2169018a2701364) > Reviewed-on: https://chromium-review.googlesource.com/c/1311513 > Commit-Queue: Philip Chen <philipchen@chromium.org> > Tested-by: Philip Chen <philipchen@chromium.org> > Trybot-Ready: Philip Chen <philipchen@chromium.org> Bug: b:117061273 Change-Id: I0750cc43ff7de1940675b969c9243ce55fe3ba46 Reviewed-on: https://chromium-review.googlesource.com/c/1342735 Reviewed-by: Philip Chen <philipchen@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Philip Chen <philipchen@chromium.org>
* power/rk3399: Do not boot until power button is releasedPhilip Chen2018-11-201-2/+15
| | | | | | | | | | | | | | | | | | | | | | This is the expected behavior for tablet/detachable. BUG=b:119508214 BRANCH=scarlet TEST=When a dru is off, press VolUP + VolDN + Pwr buttons for 10 secs without seeing dru boots, and then release those buttons, confirm dru enters recovery mode. Change-Id: Ib8d018da2af23a80a644f75808f9ed391b35d0f0 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/1336739 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Wai-Hong Tam <waihong@google.com> (cherry picked from commit c86e5363b920984b9310057ad12b9447cce6e4e5) Reviewed-on: https://chromium-review.googlesource.com/c/1342734 Reviewed-by: Philip Chen <philipchen@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Trybot-Ready: Philip Chen <philipchen@chromium.org>
* power: add chipset_in_or_transitioning_to_stateJett Rink2018-11-202-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need a method that we can call from the chipset notify hooks that can clearly distinguish which state you are about to be in. This is made evident by the child CL for putting a MUX into low power mode in S5. Without this method, we have to put chipset state into the PD task variable and use that instead (since chipset_in_state won't work because we are in the S3S5 state) BRANCH=none BUG=b:112136208,b:111196155,chromium:736508 TEST=On Phaser the 3300_pd_a drops from 92mW to 32 mW when the charger is plugged into C1 and the SoC is in S5. The rail also says at 32mW after removing and plugging the power back in while the SoC is in S5. Also ensured that power is low upon first insertion and AP does not come on automatically. Change-Id: I93cce2aa319c9689efce222919e5389471001a00 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1211368 Reviewed-by: Justin TerAvest <teravest@chromium.org> (cherry picked from commit 74e613842277cf0d13af3fbad6105055bc039a04) Reviewed-on: https://chromium-review.googlesource.com/c/1342733 Reviewed-by: Philip Chen <philipchen@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Philip Chen <philipchen@chromium.org>
* scarlet: Throttle PD voltage based on battery levelPhilip Chen2018-11-011-18/+34
| | | | | | | | | | | | | | | | | | | | | BUG=b:78792296 BRANCH=scarlet TEST=Sequentially test on Dru: 1)When SOC < BAT_LEVEL_PD_LIMIT, plug in AC and confirm PD voltage == 9V in S0/S3/S5. 2)Leave Dru off (S5) and plugged in, when SOC crosses BAT_LEVEL_PD_LIMIT, confirm PD voltage drops from 9V to 5V. 3)When SOC > BAT_LEVEL_PD_LIMIT, plug in AC and confirm PD voltage == 9V in S0 and PD voltage == 5V in S3/S5 Change-Id: I770dc385efd8cab5e715f391ec49325446c9d43e Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1311753 Reviewed-by: David Schneider <dnschneid@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Philip Chen <philipchen@chromium.org>
* max17055: Invalidate all batt info when batt not present.Yilun Lin2018-10-311-11/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BUG=b:117061273 TEST=on kukui, remove batt, connect pd, see battery output in console > battery Status: 0x0000 Param flags:000007fc Temp: 0x0000 = 0.0 K (-273.1 C) V: 0x0000 = 0 mV V-desired: 0x0000 = 0 mV I: 0x0000 = 0 mA I-desired: 0x0000 = 0 mA Charging: Not Allowed Charge: 0 % Manuf: <unkn> Device: <BATT> Chem: <unkn> Serial: 0xffffffff V-design: 0x0f14 = 3860 mV Mode: (unsupported) Abs charge:(unsupported) Remaining: 6334 mAh Cap-full: 6910 mAh Design: 6910 mAh Time-full: 0h:0 Empty: 102h:23 TEST=on connect batt, connect pd, see battery output in console BRANCH=None Change-Id: Ied338266fa0f7713da408438460bc97d4db01e6f Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1253372 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> (cherry picked from commit fbb47e2bc63c1b84e1509b50e2169018a2701364) Reviewed-on: https://chromium-review.googlesource.com/c/1311513 Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Philip Chen <philipchen@chromium.org>
* scarlet: Limit PD max voltage in a special casePhilip Chen2018-09-191-5/+21
| | | | | | | | | | | | | | | BUG=b:78792296 BRANCH=scarlet TEST=See PD voltage locked to 5V and back to normal (9V in my case) when rt946x enters/exits charge termination. Change-Id: I0889badcaf4a8d435dc53f6fa986b3d6e06c285b Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/1200416 Reviewed-by: David Schneider <dnschneid@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org>
* scarlet: Bump the hard-coded battery currentPhilip Chen2018-07-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | For scarlet, the battery desired current is always overridden by charger_profile_override(). As scarlet has a dumb battery, we just need a hard-coded placeholder for the fuel gauge. 'firmware_ECCharging' test doesn't expect charger target current to go higher than battery desired current, so we need to bump this hard-coded battery desired current to pass the test. BUG=b:111837457 BRANCH=scarlet TEST=battery command shows I-desired is 4000mA TEST=firmware_ECCharging passes when battery is not full Change-Id: Ife29c6f1c65da09df8647ae9b6987ae5df8a3745 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/1154467 Reviewed-by: Philip Chen <philipchen@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Philip Chen <philipchen@chromium.org>
* scarlet: Cut off battery in a custom battery conditionPhilip Chen2018-07-173-12/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | We want to shut down AP when the battery charge drops below BATTERY_LEVEL_SHUTDOWN. Then we want to cut off the battery to protect the battery from over-discharging. But we don't want to cut off the battery right after the battery charge drops below BATTERY_LEVEL_SHUTDOWN so that we can retain the RTC timestamp for functionality reasons. So let's add a custom check before we move on to cut off the battery in shutdown_on_critical_battery(). BUG=b:68723854 BRANCH=scarlet TEST=keep the battery discharging, see AP shut down when battery charge hits 2% and later EC cut off battery when battery voltage hits 3.2V Change-Id: I9950cf32558c11a2f55ee6ca64c157146d449110 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/1121593 Reviewed-by: Alexandru M Stan <amstan@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Philip Chen <philipchen@chromium.org>
* scarlet: Change FIFO settingsAlexandru M Stan2018-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Similar to CL:1134494 Reduce the amount of datum to trigger a FIFO interruption. To improve timestamping in the kernel, we need to send a continuous stream of data to the host. In case of CTS batch test, we may not send anything for x100ms; the filter will not have any data to estimate the drift and may output invalid timestamps. Change the FIFO threshold to try to have more than ~10 samples in a singe batch. We still need a long FIFO when the EC is busy and can not process events from the sensor. BUG=b:73551961 BRANCH=scarlet TEST=in CtsHardwareTestCases, tests SensorBatchingTests pass more reliably. Change-Id: I254230498fcf270dfa303cf5eacec5d8abdd1225 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1137454 Reviewed-by: Philip Chen <philipchen@chromium.org>
* driver: bmi160: Preserve the timestamp before releasing interruptGwendal Grignou2018-07-161-7/+13
| | | | | | | | | | | | | | | | | | | | Collect timestamp before resetting the interrupt line: After reading, it is possible for the timestamp to change, before we can process the FIFO. BUG=b:67743747 BRANCH=scarlet TEST=CtsHardwareTestCases Change-Id: I283f8efb1098a38c76caf326b6416a386ab221cd Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1137443 Commit-Queue: Alexandru M Stan <amstan@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Alexandru M Stan <amstan@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Alexandru M Stan <amstan@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org>
* driver: bmi160: harden interrupt and fifo processingGwendal Grignou2018-07-161-45/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During cts test with CL:938146, the BMI160 would not send any interrupts and FIFO got un processed. - Latch IRQ events forever: the motion_sense task will kick in and read the interrupt source sometimes, even after 5ms. - Retest irq bits in irq_handler. If more events are posted, we will collect them right away, avoiding a task wake up round trip. We assume the BMI160 adds events too fast and force the motion task into a infinite loop. BUG=b:73557414,b:80284952 BRANCH=scarlet,poppy TEST=Without that code, BMI160 would get unprocessed: android.hardware.cts.SensorIntegrationTests#testSensorsWithSeveralClients fail: ... Iteration 0 failed: "WaitForEvents |i sensor='CrosEC Accelerometer', samplingPeriod=0us, maxReportLatency=0us | requested=100, received=0, With it, the 25 iterations pass. Change-Id: I0f94b811ac0dbf60dcfa24c899682a2b5eb69de7 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1137442 Commit-Queue: Alexandru M Stan <amstan@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Alexandru M Stan <amstan@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Alexandru M Stan <amstan@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org>
* Reland "scarlet: shutdown PP900_S0 power rail when S3"Derek Basehore2018-07-111-2/+2
| | | | | | | | | | | | | | This reverts commit 2902efcbc72fac0fb7a39f150ca0477b96928dd3. BUG=b:74047620 BRANCH=scarlet TEST=suspend_stress_test on dru Change-Id: I7776f15e9d5e213d2b59d5fec9800a7b36b486b9 Signed-off-by: Derek Basehore <dbasehore@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1132520 Reviewed-by: Alexandru M Stan <amstan@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
* sensor: Add flag for tight timestampingGwendal Grignou2018-07-062-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | Kernel needs to be aware of the the new timestamp code to apply proper filtering/spreading. This flag set means that timestamps are always after every sensor sample, and both timestamps (sensor sample and fifo info) are recorded with minimal latency and jitter. Conflicts: common/ec_features.c include/ec_commands.h Fixed them by only declaring the new flag. TEST=Add 'dev_err(dev, "feature 36 = %d\n", cros_ec_check_features(ec, 36));' in kernel/drivers/platform/chrome/cros_ec_dev.c See the bit set (16, not 0) in dmesg. BUG=b/111079027, b/109786990 Change-Id: Ia71703e035d7a6eac1e0a483caa62b7c75e5cb2a Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1125272
* Reland "scarlet: Limit the maximal acceptable VBUS to 9.5V"Philip Chen2018-05-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 10050b1ebbcea44fe11b917eb14e8ec84f297949. Reason for revert: see the bug link BUG=b:78792296 Original change's description: > Revert "scarlet: Limit the maximal acceptable VBUS to 9.5V" > > This reverts commit 73686dafb0177e44582586b614234eb2e053b5d4. > > BUG=b:78792296 > BRANCH=scarlet > TEST=none > > Change-Id: If36f7b1a470c8476d80e4c0d0ffad49cfdc36e5b > Signed-off-by: Philip Chen <philipchen@google.com> > Reviewed-on: https://chromium-review.googlesource.com/1034106 > Reviewed-by: Brian Norris <briannorris@chromium.org> > Commit-Queue: Philip Chen <philipchen@chromium.org> > Tested-by: Philip Chen <philipchen@chromium.org> > Trybot-Ready: Philip Chen <philipchen@chromium.org> Bug: b:78792296 Change-Id: I36cd181a4a876abf502ef6afab4aeb19ab308466 Reviewed-on: https://chromium-review.googlesource.com/1079947 Reviewed-by: Philip Chen <philipchen@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org>
* scarlet: Don't disable idle mode in S3Philip Chen2018-05-301-2/+1
| | | | | | | | | | | | | | | | | I heard we only want to disable idle mode in S5, when battery is full. BUG=b:78792296 BRANCH=scarlet TEST=manually test on scarlet, and confirm when battery is full, idle mode is disabled in S5 but not in S3. Change-Id: I5809da581dd3fc3d382f606168a88263740256c0 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/1077496 Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: David Schneider <dnschneid@chromium.org> Reviewed-by: Alexandru M Stan <amstan@chromium.org>
* charge_state_v2: Add a hysteresis for under-voltage throttlingPhilip Chen2018-05-301-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | There is a potential loop: (1) We throttle AP when we see under-voltage. (2) VBAT bumps because throttling starts. From our experiment, AP throttling saves ~1A, and thus VBAT increases by ~80mV. (3) VBAT hasn't hit BAT_LOW_VOLTAGE_THRESH for BAT_UVP_TIMEOUT_US, so we stop throttling. (4) VBAT again drops below BAT_LOW_VOLTAGE_THRESH. (5) Go back to (1). So let's introduce a hysteresis to under-voltage throttling. We stop throttling only when we are confident that even if we stop throttling, the battery voltage will stay above BAT_LOW_VOLTAGE_THRESH. BUG=b:73050145, chromium:838754 BRANCH=scarlet TEST=manually test on scarlet Change-Id: Ic0c17a7d37d5d6ee38c7b19f9b65d17421e55cbc Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/1077687 Reviewed-by: Philip Chen <philipchen@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org>
* sensors: Make sync driver more robustAlexandru M Stan2018-05-302-23/+41
| | | | | | | | | | | | | | | | | | | | | | | | | Use a queue now for sync events, this will allow multiple interrupts to be called before the motion sense task executes. The events (including timestamps) get stored in a small queue. 8 events for the queue size should be plenty, most applications will have latency concerns anyway once we get a couple of queued up events. Also changed the init function to be a little bit more robust to race conditions. Added count argument to the "sync" simulation command to test the queue behavior. BRANCH=master BUG=b:73551961, b:67743747 TEST="sync 4" yields 4 events on the AP, whereas before it would only give the AP the last event. Change-Id: I9fcb1fb8b35eb5f8ffcc21afbfcb0f0d9bc33804 Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1065149 Reviewed-by: Gwendal Grignou <gwendal@chromium.org> (cherry picked from commit b317d2d65dafc48634087485c0671bbc2e47ebb3) Reviewed-on: https://chromium-review.googlesource.com/1077559 Reviewed-by: Philip Chen <philipchen@chromium.org>
* motion_sense: Lower jitter of EC->AP timestampAlexandru M Stan2018-05-304-2/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | When the EC sends an interrupt to the AP notifying it of new accelerometer data we need to make sure the spot we record the timestamp of the event is virtually identical to the spot the AP records the same point in time. Therefore a better spot for that is right next to the gpio toggling of the interrupt line. BUG=b:67743747 TEST=In the kernel, fifo_info->info.timestamp still has sane values. TEST=CTS should still pass BRANCH=master Change-Id: Ic77101a045123e779f576c46b401c765304976fd Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/802976 Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 1d518fb85cd7163a2fc390871046d8d6c398ed57) Reviewed-on: https://chromium-review.googlesource.com/1077558 Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org>
* scarlet: Hookup the vsync pin and the sync driverAlexandru M Stan2018-05-303-2/+46
| | | | | | | | | | | | | | | | | | | | | | BUG=b:67743747 TEST=With kernel driver, turn on camera and see interrupt here for every frame. BRANCH=master Conflicts: board/scarlet/gpio.inc Change-Id: I447f753cb2224bf78442fbd15c5fa2d2c713a9e7 Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/802832 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> (cherry picked from commit 2cc7923423f95949a7e4f769ec8e3c8b02177d93) Reviewed-on: https://chromium-review.googlesource.com/1077557 Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org>
* sensors: Add driver for SYNCAlexandru M Stan2018-05-304-0/+151
| | | | | | | | | | | | | | | | | | | | | | Useful for recording the exact time a gpio interrupt happened in the context of sensors. Adding it for camera vsync purposes. BUG=b:67743747 TEST=With next patch see it work on scarlet. BRANCH=master Change-Id: Ic8e8fb444e08200e5d8daded8b4a5920b13431ac Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/850580 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> (cherry picked from commit 4a1d2e3daf005766dc523216b8c3639fcd9595a2) Reviewed-on: https://chromium-review.googlesource.com/1077556 Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org>
* motion: Lower jitter of Sensor->EC timestampAlexandru M Stan2018-05-305-23/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit b63595258df33b0c31effe979feb4bfe884cc9fb) Reviewed-on: https://chromium-review.googlesource.com/1077555 Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org>
* motion: remove load_fifoGwendal Grignou2018-05-306-227/+234
| | | | | | | | | | | | | | | | | | | | | | | | | | | | To prevent invalid timestamping, call load_fifo only when we get a FIFO interrupt. In consequence, remove load_fifo entry point and only process fifo inside the IRQ. Add helper function to know when we are in forced mode (the EC needs to periodically read sensor data or interrupt driven). BUG=b:73557414 BRANCH=master TEST=compile Change-Id: I959e476f3f7215be95424c07223f7421e8b13da1 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/938146 Commit-Ready: Alexandru M Stan <amstan@chromium.org> Tested-by: Alexandru M Stan <amstan@chromium.org> Reviewed-by: Alexandru M Stan <amstan@chromium.org> (cherry picked from commit bc766130becff13136baa53070749899dce687f6) Reviewed-on: https://chromium-review.googlesource.com/1077554 Commit-Queue: Alexandru M Stan <amstan@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Alexandru M Stan <amstan@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org>
* motion: driver: Fix activity inclusion in accelgyro.hGwendal Grignou2018-05-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | list/add_activities should be include even when FIFO support is not compiled it, when the host is not asking for them, as it is needed for double tap support. BUG=b:73546254 BRANCH=master TEST=Compile when just CONFIG_GESTURE_DETECTION is defined. Change-Id: Icec7ccec7fd8463ea40afbe05ce1e177ae7d609d Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/924404 Commit-Ready: Gwendal Grignou <gwendal@google.com> Tested-by: Gwendal Grignou <gwendal@google.com> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@google.com> (cherry picked from commit eb50aaded727acfaf6b8521bde325976f374a3a2) Reviewed-on: https://chromium-review.googlesource.com/1077553 Commit-Queue: Alexandru M Stan <amstan@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Alexandru M Stan <amstan@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Trybot-Ready: Alexandru M Stan <amstan@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org>
* sensor: bmi160: Don't batch data on the sensorAlexandru M Stan2018-05-291-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | Set the sensor side fifo watermark to interrupt the EC as soon as there's any data in there, that way we get more frequent accelerometer interrupts (which is handy when you want to mark down the time of each sample accuratelly). BUG=b:67743747 TEST=Sensor should still be working normally, the ec will probably start recieving sensor interrupts (before this was probably not the case). BRANCH=master Change-Id: I726550e68447a74bbfed88b703d2f68b6967ac93 Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/956626 Commit-Ready: Gwendal Grignou <gwendal@chromium.org> Tested-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> (cherry picked from commit f31dcc649a40b1dae010898c4613be81a3075a95) Reviewed-on: https://chromium-review.googlesource.com/1077552 Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org>
* scarlet: set accelerometer default range to +/- 4gAlexandru M Stan2018-05-291-1/+1
| | | | | | | | | | | | | | | | | | | | BUG=b:67743747 BRANCH=master TEST=sensor should still work, ARC++ apps should see bigger range Change-Id: I81a5399711bd6a5311b8b486978a398388554222 Suggested-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/956878 Commit-Ready: Gwendal Grignou <gwendal@chromium.org> Tested-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> (cherry picked from commit 99cc9435a01f4083a4676aa25fbfb959d02e4688) Reviewed-on: https://chromium-review.googlesource.com/1077551 Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org>
* scarlet: gyro should be off by defaultAlexandru M Stan2018-05-291-1/+1
| | | | | | | | | | | | | | | | | | | | | Things that need it will request it to turn on. The only reason accel is on by default is because we need to be able to poll it from time to time. TEST=Motion related things still work BUG=While looking at b/67743747 BRANCH=master Change-Id: I08ea487058fb93ce6ff5fcc9054243d83e189e21 Suggested-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/887947 Reviewed-by: Gwendal Grignou <gwendal@chromium.org> (cherry picked from commit 000f5301b8b9d7ef7e2398b5ee269f30ceb614d0) Reviewed-on: https://chromium-review.googlesource.com/1077550 Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org>
* scarlet: Disable idle mode in a special casePhilip Chen2018-05-252-1/+20
| | | | | | | | | | | | | | | | | | | When AC is plugged, battery is full and AP is off, there is a small chance that rt946x would be damaged. I'm told that consuming more current in this case would mitigate the issue. So let's disable idle mode in this case. BUG=b:78792296 BRANCH=scarlet TEST=manually test on scarlet and confirm idle mode is disabled in the described special case Change-Id: Idc3a3165ebaa2f99bdd5df56675c3945eaeae9fa Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/1071124 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org>
* system: Enable/Disable low power idle in run timePhilip Chen2018-05-254-0/+40
| | | | | | | | | | | | | | | | | | | | | We have enable_sleep()/disable_sleep() to enable/disable EC deep sleep mode in runtime. Here we introduce similar interfaces to enable/disable EC idle (sleep) mode. BUG=b:78792296 BRANCH=scarlet TEST=Confirm idle mode is enabled/disabled when enable_idle() and disable_idle() are called. Change-Id: I2484f08a066523441064968da99c47de9342ecf0 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://chromium-review.googlesource.com/1072370 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org>
View Lorry Controller Status