| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now we have two MKBP delivery methods:
1. define CONFIG_MKBP_USE_HOST_EVENT to notify via host event
2. undef CONFIG_MKBP_USE_HOST_EVENT to notify via GPIO interrupt
It may become more complicated if new notification methods introduced.
e.g.: mt_scp uses IPI, rather than host event and GPIO interrupt.
This CL does:
1. add CONFIG_MKBP_USE_GPIO to explicilty declare that MKBP event are
sent via GPIO interrupt.
2. CONFIG_MKBP_USE_CUSTOM for boards which have custmized methods.
3. Remove weak attribute in mkbp_set_host_active (which can be done
with CONFIG_MKBP_USE_CUSTOM now.
4. Removes mkbp_set_host_active function in board Nocturne. It only
deliver MKBP events through GPIO interrupt now.
BRANCH=None
BUG=b:120808999
TEST=grep -rn "CONFIG_MKBP_USE_GPIO\|EC_INT_L" board/ baseboard/ and
see the result is reasonable:
1. EC_INT_L must be 1-to-1 mapped to define CONFIG_MKBP_USE_GPIO in
every board, except that meep, yorp, ampton which are defined in
baseboard octopus.
2. undef CONFIG_MKBP_USE_GPIO in bip and casta, which use host
event, but also have baseboard octopus.
Change-Id: I4af6110e4fd3c009968075c3623ef2d91cbd770b
Signed-off-by: Yilun Lin <yllin@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1490794
Commit-Ready: Jett Rink <jettrink@chromium.org>
Tested-by: Yilun Lin <yllin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, board_critical_shutdown_check is used only in the context
of CONFIG_BATTERY_CRITICAL_SHUTDOWN_CUT_OFF. It returns true to cutoff
the battery or false to take no action.
This patch extends board_critical_shutdown_check to allow it to control
what actions to take on critical battery condition.
With this change, each board can also customize critical battery actions
with more granularity (per OEM, BOARD_VERSION, etc.).
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=b/123727148
BRANCH=nami
TEST=Verify a battery is cutoff at critical low charge on Scarlet and
DUT wakes up by AC plugin on cros/firmware-scarlet-10388.B.
Change-Id: Id49e860b05e21c3bfa4d75f27c48b55c2a3ad95f
Reviewed-on: https://chromium-review.googlesource.com/1487113
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/1431552
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: David Schneider <dnschneid@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the fix for:
"Stack overflow in PD_INT_C0 task!"
BUG=b:122085772
BRANCH=scarlet
TEST=Plug/Unplug AC w/o seeing stack overflow
Change-Id: I225b48c11030b9a472983260b71cdc0fa2642c7f
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1390946
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
TEST=buildall
Change-Id: I0784cecddd3911f057998eb21b8edb5c577431e5
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1337464
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Wai-Hong Tam <waihong@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tablet devices would normally only define CONFIG_TABLET_MODE_SWITCH,
and not CONFIG_TABLET_MODE, and define a tablet_get_mode function
which always returns 1.
Since 09a5e0a9398 "dptf: Get rid of CONFIG_DPTF_DEVICE_ORIENTATION",
tablet_mode.h, when CONFIG_TABLET_MODE is not set, would define an
_inline_ tablet_get_mode function which would always return 0,
causing tablets to always be in laptop mode.
Fix this by:
- Removing the inline in tablet_mode.h.
- Add CONFIG_TABLET_MODE to all our tablets (after removing the
inline, compilation fails if CONFIG_TABLET_MODE_SWITCH is set,
but not CONFIG_TABLET_MODE).
- Remove tablet_get_mode from board/*/board.c, as the default
mode is tablet, anyway.
BRANCH=none
BUG=b:120252451
TEST=Boot kukui, onscreen keyboard works
TEST=No code size increase:
build/kukui/RW/space_free_flash shrank by 36 bytes: (23968 to 23932)
build/kukui/RW/space_free_ram shrank by 4 bytes: (10356 to 10352)
build/rainier/RW/space_free_flash shrank by 36 bytes: (44296 to 44260)
build/rainier/RW/space_free_ram shrank by 4 bytes: (12948 to 12944)
build/scarlet/RW/space_free_flash shrank by 36 bytes: (28128 to 28092)
build/scarlet/RW/space_free_ram shrank by 4 bytes: (10532 to 10528)
Change-Id: Ifea0412bb32f1d701ad2040ad62a5c812705b14a
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1355645
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should be the last step to make all boards on ToT follow
go/usb-pd-slow-response-time. Theses boards all have the higher priority
tasks, but they aren't being used since the tcpc interrupt wasn't
scheduling calls on it.
BRANCH=none
BUG=b:112088135
TEST=builds
Change-Id: I2c39e661e804f88edd5b34636b93e6e63a5af57f
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1283452
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We do not need to set the port_addr variable most places because the
SS-MUX is also the TCPC and the tcpc_config_t information is used
instead.
Remove unused variable setting to avoid confusion.
BRANCH=none
BUG=none
TEST=buildall. phaser USB-C communication (and muxs) still work which is
a nominal case for all of these changes.
Change-Id: I72ee5da251956eb133091974e8dce5ac7f8787c6
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1200064
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Edward Hill <ecgh@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To all boards that have space, add the PD tasks that handle interrupts
in parallel. This is the last change for go/usb-pd-slow-response-time.
BRANCH=none
BUG=b:112088135
TEST=buildall. This works on grunt and octopus. This CL is more of a
clean up for ToT to ensure that newly copied boards use the correct
paradigm.
Below is the space taken up by this change:
build/atlas/RW/space_free_flash shrank by 212 bytes: (64796 to 64584)
build/atlas/RW/space_free_ram shrank by 1408 bytes: (33568 to 32160)
build/cheza/RW/space_free_flash shrank by 200 bytes: (205716 to 205516)
build/cheza/RW/space_free_ram shrank by 1408 bytes: (38208 to 36800)
build/coral/RW/space_free_flash shrank by 212 bytes: (87980 to 87768)
build/coral/RW/space_free_ram shrank by 1400 bytes: (2564 to 1164)
build/dragonegg/RW/space_free_flash shrank by 276 bytes: (142136 to 141860)
build/dragonegg/RW/space_free_ram shrank by 1640 bytes: (24704 to 23064)
build/elm/RW/space_free_flash shrank by 204 bytes: (24644 to 24440)
build/elm/RW/space_free_ram shrank by 528 bytes: (8972 to 8444)
build/eve/RW/space_free_flash shrank by 216 bytes: (83748 to 83532)
build/eve/RW/space_free_ram shrank by 1408 bytes: (1824 to 416)
build/fizz/RW/space_free_flash shrank by 184 bytes: (17576 to 17392)
build/fizz/RW/space_free_ram shrank by 736 bytes: (11648 to 10912)
build/glkrvp/RW/space_free_flash shrank by 248 bytes: (92432 to 92184)
build/glkrvp/RW/space_free_ram shrank by 1408 bytes: (45088 to 43680)
build/kukui/RW/space_free_flash shrank by 160 bytes: (32364 to 32204)
build/kukui/RW/space_free_ram shrank by 520 bytes: (11260 to 10740)
build/meowth/RW/space_free_flash shrank by 240 bytes: (72232 to 71992)
build/meowth/RW/space_free_ram shrank by 1408 bytes: (34496 to 33088)
build/nami/RW/space_free_flash shrank by 360 bytes: (82016 to 81656)
build/nami/RW/space_free_ram shrank by 1408 bytes: (2656 to 1248)
build/nocturne/RW/space_free_flash shrank by 216 bytes: (62756 to 62540)
build/nocturne/RW/space_free_ram shrank by 1408 bytes: (34368 to 32960)
build/rainier/RW/space_free_flash shrank by 180 bytes: (45468 to 45288)
build/rainier/RW/space_free_ram shrank by 528 bytes: (13516 to 12988)
build/rammus/RW/space_free_flash shrank by 200 bytes: (91284 to 91084)
build/rammus/RW/space_free_ram shrank by 1408 bytes: (1920 to 512)
build/reef_mchp/RW/space_free_flash shrank by 212 bytes: (51048 to 50836)
build/reef_mchp/RW/space_free_ram shrank by 2120 bytes: (27420 to 25300)
build/reef/RW/space_free_flash shrank by 224 bytes: (84564 to 84340)
build/reef/RW/space_free_ram shrank by 1408 bytes: (2208 to 800)
build/rowan/RW/space_free_flash shrank by 204 bytes: (29668 to 29464)
build/rowan/RW/space_free_ram shrank by 528 bytes: (9300 to 8772)
build/scarlet/RW/space_free_flash shrank by 156 bytes: (29464 to 29308)
build/scarlet/RW/space_free_ram shrank by 520 bytes: (11100 to 10580)
build/zoombini/RW/space_free_flash shrank by 276 bytes: (66816 to 66540)
build/zoombini/RW/space_free_ram shrank by 2112 bytes: (37376 to 35264)
Compared 208 of 208 files.
38 files changed.
Total size change: -27484 bytes.
Average size change: -723 bytes.
Change-Id: Ifbea67ee4d460fb197a1601d0951169f2f2b5b3b
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1220667
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Naming of many vector types and matrix types are not clear enough.
For example, we have:
vector_3_t, which is a vector of three int.
vec3_t, which is a vector of three float.
size4_t, which is a vector of four size_t.
mat33_t, which is a 3x3 matrix of float.
matrix_3x3_t, which is a 3x3 matrix of fixed point.
Besides, we have types like int8_t, uint16_t types.
To clearly distinguished types, the CL propose to,
For vector types, naming should be `$type + 'v' + $num + '_t'`:
vector_3_t becomes intv3_t
vec3_t becomes floatv3_t
vector 4 of uint16_t becomes uint16v4_t (which doesn't exist yet)
For matrix types, naming should be `mat$N$N_` + $type + '_t', where $N is the
matrix size:
matrix_3x3_t becomes mat33_fp_t # fp: fixed point
mat33_t becomes mat33_float_t
TEST=make buildall -j
BUG=b:114662791
Change-Id: I51d88d44252184e4b7b3564236833b0b892edc39
Signed-off-by: Yilun Lin <yllin@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1215449
Commit-Ready: Yilun Lin <yllin@chromium.org>
Tested-by: Yilun Lin <yllin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The alert line for TCPC will stay asserted as long as there are RX
messages for the TCPM (i.e. EC) to pull from the TCPC. We should clear
all of the RX messages we know about during a single alert handling
session.
This CL can stand on its own, but it is a part of a CL stack that will
tighten the critical section of time between received messages from the
TCPC and sending follow up message out through the TCPC.
See go/usb-pd-slow-response-time for more details.
BRANCH=none
BUG=b:112088135,b:112344286,b:111909282,b:112848644,b:113124761
BUG=b:113057273,b:112825261
TEST=Reduces reset issue in most cases for phaser, bobba. Does not seem to
adversely affect state machine negotiation. Full CL stack consistently
sends a REQUEST at 18ms after a SRC_CAP GoodCRC, which is well below the
24 ms threshold we need to be under for USB PD spec compliance.
Also testing pd_suspend scenario manually and EC was responsive after
port 1 suspend because of "bad behavior"
Change-Id: I1654b46400e9881f2927a5f6d6ace589edd182de
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1185727
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support to configure dualrole setting
per port, so that servo v4 can adjust charge and
dut port separately.
servo will detect charge capability on CHG port
and choose source or sink as appropriate.
Fix null dereference bug in genvif duel to dynamic src_pdo.
"cc" command allows src, snk, srcdts, snkdts configurations.
BRANCH=None
BUG=b:72557427
TEST=charge through and also passive hub. Note Dru doesn't accept DTS hub.
TEST=make buildall -j
Change-Id: I19f1d1a5c37647fec72202191faa4821c06fb460
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1096654
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Scarlet uses the charger RT9467 to measure the VBUS.
In the board.h, it has CONFIG_CHARGER_RT9467, which implies
CONFIG_USB_PD_VBUS_MEASURE_CHARGER.
BRANCH=none
BUG=b:112204765
TEST=make buildall -j; BOARD=scarlet make tests -j
Change-Id: I4e6afa38e58ed09de7bb5de2de1de38b06ceed90
Signed-off-by: Wai-Hong Tam <waihong@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1171669
Reviewed-by: Philip Chen <philipchen@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some boards still define ADC_VBUS -1. It seems to be an old convention
for the case no vbus adc channel, before the change:
https://chromium-review.googlesource.com/charge_manager.c
It causes reading the adc channel -1 if
CONFIG_USB_PD_VBUS_MEASURE_NOT_PRESENT not defined. This is an
out-of-bounds array access and sometime it causes a "Divide by 0"
exception.
BRANCH=none
BUG=b:112204765
TEST=make buildall -j
TEST=Booted cheza and didn't see "Divide by 0" exception.
Change-Id: Ic44c3e89023f580d499ed52dc38bef0a3a12a0cf
Signed-off-by: Wai-Hong Tam <waihong@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1162883
Reviewed-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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=make buildall -j
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>
(cherry picked from commit 91171747b4ca01ac929186c96d4d6aa3489c60ab)
Reviewed-on: https://chromium-review.googlesource.com/1140795
Commit-Ready: Philip Chen <philipchen@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/1152524
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Provides a new EC host command 'uptime info' which gathers up some
information which may be useful for debugging spurious resets on the AP
(was the EC reset recently? Why was the EC reset? If the EC reset the
AP, why did it do so?, etc.). Provide ectool support for the same.
Example results of `ectool uptimeinfo`:
```
localhost ~ # ectool uptimeinfo
EC uptime: 475.368 seconds
AP resets since EC boot: 2
Most recent AP reset causes:
315.903: reset: console command
363.507: reset: keyboard warm reboot
EC reset flags at last EC boot: reset-pin | sysjump
```
BRANCH=none
TEST=Perform some `apreset` commands from the EC console and observe
their side-effects via the `ectool uptimeinfo` command on the AP side.
Test sequences include no-resets through 5 resets, observing that the
ring buffer handling was correct.
BUG=b:110788201, b:79529789
Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
Change-Id: I0bf29d69de471c64f905ee8aa070b15b4f34f2ba
Reviewed-on: https://chromium-review.googlesource.com/1139028
Commit-Ready: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
Tested-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code to remap DMA channels on STM32F09x is a little obscure,
let's try to make it a bit clearer by using simpler masks.
A more proper fix might be to setup better macros, or use the
existing dma_select_channel function, but this already improves
readability.
BRANCH=none
BUG=b:80159522
TEST=Flash kukui, see that UART and eMMC emulation work.
TEST=Compare binaries for elm kukui oak rainier rowan scarlet
before and after this change, and see that resulting binaries
are identical.
Change-Id: Id4d2b9cfec86230b2329fa04a4c1992ec13be4e1
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1146128
Reviewed-by: Yilun Lin <yllin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On kukui, we fell into a copy-pasta trap, and didn't realize that
CONFIG_STM32_CLOCK_LSE meant that we needed an external 32.768 kHz
clock source.
With this option set (and no external source), the EC gets stuck
on boot, without printing anything on console at all, which is
very confusing during early bringup.
BRANCH=none
BUG=b:80159522
TEST=make buildall -j
Change-Id: I65434e5628a4e8102d56ad225aa378bcbe5c299f
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1146126
Reviewed-by: Yilun Lin <yllin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CONFIG_MPU does not make sense anyway on STM32F0 with Cortex-M0
core.
BRANCH=none
BUG=none
TEST=make buildall -j
Change-Id: I6e338cbbf783babd4e2c9dbe0a3188a086b54807
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1143108
Reviewed-by: Yilun Lin <yllin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/1137474
Reviewed-by: Philip Chen <philipchen@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
(cherry picked from commit 8746200bb7c71bdee057580447c78ffb53520fae)
Reviewed-on: https://chromium-review.googlesource.com/1079732
Commit-Ready: Philip Chen <philipchen@chromium.org>
Reviewed-by: Philip Chen <philipchen@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
(cherry picked from commit 37168486d3f5543b5dd7a8e5d819c68c4c68c5b0)
Reviewed-on: https://chromium-review.googlesource.com/1076709
Commit-Ready: Philip Chen <philipchen@chromium.org>
Reviewed-by: Philip Chen <philipchen@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:73050145
BRANCH=scarlet
TEST=manually test on scarlet together with CL:1064983
Change-Id: Ic5bcc0e4432b2f8ac03fcfa872388ff07d240a7b
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1064985
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: David Schneider <dnschneid@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After we set TE (CL:958295), rt946x terminates charging when
the charge current is below IEOC in constant-voltage mode.
When AC is plugged and rt946x terminates, we see cases that
battery SOC falls below BATTERY_LEVEL_NEAR_FULL but rt946x doesn't
re-enable charging yet, which leads to amber LED. The Chrome OS UI
might also show battery is not full in this case.
Let's clamp the reported battery SOC in this scenario to
avoid user confusion.
BUG=b:77870927
BRANCH=scarlet
TEST=When AC is on, charge terminates, and BATTERY_LEVEL_NEAR_FULL
is hit, confirm battery SOC is overwritten.
Change-Id: I4575e562873d149d6f349ddb578334d107e21776
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1055194
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
(cherry picked from commit 10050b1ebbcea44fe11b917eb14e8ec84f297949)
Reviewed-on: https://chromium-review.googlesource.com/1055269
Commit-Ready: Philip Chen <philipchen@chromium.org>
Reviewed-by: Philip Chen <philipchen@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:74321682
BRANCH=scarlet
TEST=manually test on scarlet together with CL:994188
Change-Id: I831ca9941248835f98a1c5ea69e751f3f7413ed7
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1043454
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/1054121
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Philip Chen <philipchen@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that board version can come from CBI, we can have a real error
reading it. We should pass that error to the console or to the
AP on the host command and let the AP firmware (or user) decided how to
handle that error case
Also update the CONFIG_BOARD_VERSION to be derived instead of needed
in most cases.
BRANCH=none
BUG=b:77972120
TEST=Error reported on EC console and AP console when CBI is
invalid on yorp
Change-Id: Ib8d80f610ea226265a61e68b61965150cdc9bb04
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1015776
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pd_custom_vdm is called in common/usb_pd_protocol no
matter you have this defined or not. No where else I see
pd_vdm being used. So we should not have to deal with this
CONFIG_USB_PD_CUSTOM_VDM.
BUG=None
BRANCH=None
TEST=make buildall -j
Change-Id: I4e8b710240ee27b12625d797e7824f29044e6462
Signed-off-by: Divya Sasidharan <divya.s.sasidharan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/998520
Commit-Ready: Divya S Sasidharan <divya.s.sasidharan@intel.com>
Tested-by: Divya S Sasidharan <divya.s.sasidharan@intel.com>
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Majority of the chipsets do not have a dedicated GPIO to trigger
AP cold reset. Current code either ignores cold reset or does a warm
reset instead or have a work around to put AP in S5 and then bring
back to S0. In order to avoid the confusion, removed the cold reset
logic and only apreset is used hence forth.
BUG=b:72426192
BRANCH=none
TEST=make buildall -j
Manually tested on GLKRVP, apreset EC command can reset AP.
Change-Id: Ie32d34f2f327ff1b61b32a4d874250dce024cf35
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/991052
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we enable charge termination when booting w/o battery,
charge termination would trigger and cut the power for max17055.
BUG=b:72697658
BRANCH=scarlet
TEST=Read rt946x reg 0x02, confirm charge termination is
disabled when booting w/o battery, and enabled otherwise.
Change-Id: I5780196ad993299ddfb37621bee5e941aa9b0d14
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/989314
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Philip Chen <philipchen@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:74399717
BRANCH=scarlet
TEST=Plug in a charger with 5V/9V/15V PD profiles, confirm
scarlet picks 5V
Change-Id: I58ee110d110d873b7221695bf4a182d6d04b65e1
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/982555
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Alexandru M Stan <amstan@chromium.org>
|
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=Compile
BRANCH=none
Change-Id: I86ccc26d7fb6d482dca3275a4365729ff8644777
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/969626
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The CLs supporting BC 1.2 with rt946x have been merged.
It's time to enable BC 1.2 on Scarlet!
BUG=b:65446459
BRANCH=none
TEST=Charge Scarlet rev4 with SDP (500mA), DCP (1500mA),
PD charger, and Type-C charger (3000mA).
Change-Id: Ia3c7a700586bc15d94c4ef104fbd5afc8be9b0af
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/905934
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Assignment to 0 are no necessary.
BUG=none
TEST=compile, check nami.
BRANCH=none
Change-Id: I1bc11efcff31cbfe2947580e7b8db0d5ba72d444
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/959502
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:67743747
TEST=With kernel driver, turn on camera and see interrupt here for every
frame.
BRANCH=master
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're prioritizing lower voltages for efficiency.
BUG=b:74399717
BRANCH=scarlet
TEST=build scarlet
Change-Id: I85090f75f4dae2be269957ffc3745eb54c446f7a
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/956355
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: David Schneider <dnschneid@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can turn off ADC after the first successful read for board version.
A few milliwatts saved is important when Scarlet is in S3.
BUG=b:72160379
BRANCH=scarlet
TEST=Try 'version' command a few times on EC console and see
correct board version.
Change-Id: Id2bef415f161431ed895f49db30d50347479176d
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/942377
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Derek Basehore <dbasehore@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Simplo update battery spec again -
the maximal charging current can be 4A now.
BUG=b:70820167
BRANCH=scarlet
TEST=build scarlet
Change-Id: I52e295b83563240aed73944107b00649c9b422b1
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/942370
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-by: David Schneider <dnschneid@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fuel gauge (max17055) on Scarlet is powered by VBAT.
To use max17055 to detect batttery presence, we want to keep
it alive even if battery is disconnected.
BUG=b:72697658
BRANCH=scarlet
TEST=boot scarlet rev3 w/o battery on AC and don't see VBAT drops
Change-Id: Ice27384ded257be75ee29a28c0ada9f73b173f6c
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/930572
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-by: David Schneider <dnschneid@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:69634899
BRANCH=scarlet
TEST='battery' command shows the full cap is updated to 8734 mAh
Change-Id: I090d80e7c889c044ba2dfbdf02527a0791419320
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/933861
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CONFIG_USB_PD_DISCHARGE is now defined automatically if you specify one of
the specified options such as CONFIG_USB_PD_DISCHARGE_TCPC
BRANCH=none
BUG=none
TEST=grunt still discharges using PPC
Change-Id: I94086cfc58bebce9c62ad6aa52b7740b25276d89
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/894676
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The macros were added for debug and not used anymore.
Let clean it up.
BUG=none
BRANCH=none
TEST=make BOARD=scarlet
Change-Id: I859fd3ddf2d5271ba26d23696013c83dec98a966
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/891547
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Alexandru M Stan <amstan@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To support CR50 deep sleep mode:
In up-sequence, SYS_RST_L needs to remain asserted on the transition
to S5 and then deasserted on the transition to S0;
In down-sequence, SYS_RST_L needs to be asserted on the transition to S5.
This only affects Scarlet.
BUG=b:35647982
BRANCH=none
TEST=minitor SYS_RST_L pin to confirm it is toggled right
Change-Id: Ic73d39c531f9d28b2087a23d58613e98ec80dbd2
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/866115
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: David Schneider <dnschneid@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To detect the board version correctly, ADC must output mV.
BUG=b:72233188
BRANCH=none
TEST='version' command shows correct board version.
Change-Id: I68889092719240394f03cb9b21cb0844feb315e5
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/879491
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Simplo updated the datesheet and limited the charging current to 3A.
BUG=b:70820167
BRANCH=none
TEST=none
Change-Id: I88b9e0ac3ebba401530e2bb6ae08438c56d8506e
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/875145
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After VBUS is up, there is a delay of ~500ms for rt946x to determine
'VBUS is ready'.
But we need charger_task to detect AC presence and then set a proper
sleep time immediately.
When using fusb302 to detect VBUS, I almost don't see any delay.
BUG=b:71520398
BRANCH=none
TEST=Confirm BATTERY LED turns on immediately when AC is
plugged in a Scarlet in G3.
Change-Id: If1d6d40081b5822eeb9e012115f8deef172def37
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/869420
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|