| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
EFS2 boards need to call system_jumped_late in HOOK_INIT to avoid
running init code twice per boot.
system_jumped_to_this_image and system_jumped_late are functionally
equivalent for non EFS2 boards.
This patch will prevent system_jumped_to_this_image from being used
for EFS2 boards when code is copied from a past project.
BUG=chromium:1072743
BRANCH=none
TEST=buildall
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I73fb5cedc5325d1c80825f9346954013046ee1df
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2267685
Reviewed-by: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PDCMD task is only pulling interrupts from the TCPCs on most boards,
which is unnecessary since the PD_INT tasks handle this job now.
Remove it from any boards using the PD_INT command which are not using
the older CONFIG_HOSTCMD_PD functionality (ex. samus, oak).
Located boards using:
find -name "ec.tasklist" | xargs grep -l PD_INT | xargs grep PDCMD
BRANCH=None
BUG=b:154959596
TEST=make -j buildall
Signed-off-by: Diana Z <dzigterman@chromium.org>
Change-Id: I29be8ab1d7a2616603fb55236aed4329ed8654f5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2208221
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this is to add near future functionality to allow
not only the current PRESENT range check but to add
Save0V range checking as well, for platforms that
allow for this. This just lays the framework and
is functionally equivalent.
BUG=none
BRANCH=none
TEST=verify basic USB functionality
Signed-off-by: Denis Brockus <dbrockus@google.com>
Change-Id: I1eb3411bc3aa9b792c9b97799e1721e5cb229f64
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2199036
Tested-by: Denis Brockus <dbrockus@chromium.org>
Reviewed-by: Diana Z <dzigterman@chromium.org>
Commit-Queue: Denis Brockus <dbrockus@chromium.org>
Auto-Submit: Denis Brockus <dbrockus@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since all rt946x users do not customize usb_charger_set_switches(),
move this function into rt946x.c for the upcoming bc12 driver refactor.
A board can customize this function using the new bc12_drv if needed.
BUG=b:155611686
TEST=make buildall
BRANCH=none
Signed-off-by: Ting Shen <phoenixshen@google.com>
Change-Id: I8724af15c3508b54dc131a7c99004f3f4b2f893f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2187079
Tested-by: Ting Shen <phoenixshen@chromium.org>
Auto-Submit: Ting Shen <phoenixshen@chromium.org>
Reviewed-by: Eric Yilun Lin <yllin@chromium.org>
Commit-Queue: Eric Yilun Lin <yllin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With OCPC, one charger IC per Type-C port, there are now multiple
charger ICs present in the system. This commit adds the beginning of
OCPC support by adding the notion of an active charger IC. Charge
Manager will select the active charger IC based upon the charge port.
Boards must define this mapping in a board specific function.
Additionally, this commit adds chgnum as a parameter to
charger_set_input_current_limit().
BUG=b:148981052
BRANCH=None
TEST=With other patches, verify that the active charger IC is able to
be saved and retrieved.
Change-Id: Iba4a8958171ad6e1630b0ca3d07d128bc1f2c4dd
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2135963
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Diana Z <dzigterman@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace some macro of BMI160 to BMI version for common function of
BMI series.
Make board config include the accelgyro_bmi_common.h instead of
accel_gyro_bmi160.h.
BRANCH=None
BUG=b:146144827
TEST=make buildall -j
Change-Id: I043ff8a92f15295ead3fa5c1e292319e2b4fa21a
Signed-off-by: Ching-Kang Yen <chingkang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2156525
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes retimers appear as generic muxes. By allowing a
chain of muxes they can be stacked up to the new configurations
that zork requires and will continue to work as they did before
on configurations that only have a single mux.
The code used to have two different arrays, 1) muxes and 2)
retimers. On one of the zork configurations the processor
MUX stopped being the primary mux and the retimer took its
place. In a different configuration of that same platform
it left the primary and secondary alone but the mux_set
FLIP operation had to be ignored. Since the same
interfaces needed to be available for both it stopped making
sense to have two different structures and two different
methods of handling them. This consolodates the two into
one.
The platforms that do not have retimers, this change will
not make any difference. For platforms like zork, it will
remove the retimers and make them chained muxes. So
testing on trembyle makes sense to verify,
BUG=b:147593660
BRANCH=none
TEST=verify USB still works on trembyle
Change-Id: I286cf1e302f9bd3dd7e81098ec08514a2a009fe3
Signed-off-by: Denis Brockus <dbrockus@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2066794
Commit-Queue: Jett Rink <jettrink@chromium.org>
Reviewed-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current use of the PD Config Flags are a bit confusing and
has been changed to the following:
The CONFIG_USB_POWER_DELIVERY flag is used to enable and disable
the TCPMv1 and TCPMv2 stacks. And when CONFIG_USB_POWER_DELIVERY
is enabled, one of the following must be enabled:
CONFIG_USB_PD_TCPMV1 - legacy power delivery state machine
CONFIG_USB_PD_TCPMV2 - current power delivery state machine
BUG=b:149993808
BRANCH=none
TEST=make -j buildall
Change-Id: Ie3f8615a75b15b4f1c703f57f3db9e152a471238
Signed-off-by: Sam Hurst <shurst@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2068519
Reviewed-by: Diana Z <dzigterman@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit removes the temporary common charger chip configuration and
instead puts the configuration in each board.
BRANCH=none
BUG=b:147672225
TEST=builds, runs on waddledoo and octopus
Change-Id: If81aef31e48c65999a87e202494f286716114bbb
Signed-off-by: Diana Z <dzigterman@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2031855
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Required by Android CDD - Section 7.3.1 - Paragraph C.1.4
Modified mechanically with:
for i in $(grep -lr "\.default_range" board); do
sed -i '/.default_range =/s#\(.*\.default_range = \).* /\
\* g.*#\14, /* g, to meet CDD 7.3.1/C-1-4 reqs */#' $i
done
Manually reworked to only change the accelerometer that matters to
android:
The lid accelerometer or the base accelerometer if the base also hosts
the gyroscope.
This is only for future EC, no need to land the change on branches:
mems_setup will take care to set accelerometer ranges at 4g on startup.
BUG=b:144004449
BRANCH=none
TEST=compile
Change-Id: If8c14b2e928c9c70c0ce51451adcfcd674a9e73b
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1957375
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Reviewed-by: Alexandru M Stan <amstan@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a board specific usb_pd_policy.c file that contains a lot of
code for handling DisplayPort Alternate mode, Google Firmware Update
Alternate mode, as well as some PD policy functions such as deciding to
Accept or Reject a data role swap or a power role swap. Several boards
simply copy/paste this code from project to project as a lot of this
functionality is not actually board specific.
This commit tries to refactor this by pulling the functions that are not
mainly board specific into common code. The functions are made
overridable such that boards that truly do require a different
implementation may do so.
Additionally, this consolidation changes the policy behaviour for some
boards, but they should be for the better. Some examples include that
data swaps are always allowed if we are a UFP (no system image
requirement), power swaps are allowed to become a sink if we are no
longer dual role (e.g. - in suspend), and DisplayPort Alternate Mode is
not entered if the AP is off.
In order to facilitate this refactor, a couple CONFIG_* options were
introduced:
- CONFIG_USB_PD_DP_HPD_GPIO
/* HPD is sent to the GPU from the EC via a GPIO */
- CONFIG_USB_PD_CUSTOM_VDO
/*
* Define this if a board needs custom SNK and/or SRC PDOs.
*
* The default SRC PDO is a fixed 5V/1.5A with PDO_FIXED_FLAGS indicating
* Dual-Role power, USB Communication Capable, and Dual-Role data.
*
* The default SNK PDOs are:
* - Fixed 5V/500mA with the same PDO_FIXED_FLAGS
* - Variable (non-battery) min 4.75V, max PD_MAX_VOLTAGE_MV,
* operational current PD_MAX_CURRENT_MA,
* - Battery min 4.75V, max PD_MAX_VOLTAGE_MV, operational power
* PD_OPERATING_POWER_MW
*/
BUG=chromium:1021724,b:141458448
BRANCH=<as many as we can that are still supported>
TEST=`make -j buildall`
TEST=Flash a kohaku, verify that DP Alt Mode still works with a variety
of DP peripherals
TEST=Repeat above with a nocturne
TEST=Repeat above with an atlas
Change-Id: I18fd7e22dc77fe1dc6c21c38cd7f1bc53cae86cb
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1949052
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Reviewed-by: Diana Z <dzigterman@chromium.org>
Reviewed-by: Denis Brockus <dbrockus@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Certain SKUs of certain boards have lesser number of USB PD ports than
defined by CONFIG_USB_PD_PORT_COUNT. Hence rename
CONFIG_USB_PD_PORT_COUNT as CONFIG_USB_PD_PORT_MAX_COUNT.
BUG=b:140816510, b:143196487
BRANCH=octopus
TEST=make -j buildall; Boot to ChromeOS
Change-Id: I7c33b27150730a1a3b5813b7b4a72fd24ab73c6a
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1879337
Tested-by: Karthikeyan Ramasubramanian <kramasub@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Commit-Queue: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this changes the declaration and definitions of
typec_set_source_current_limit() to take an enum tcpc_rp_value instead
of int.
BRANCH=none
BUG=none
TEST=buildall passes
Change-Id: If633641a581eeb6085b94bc727e23fb57f7cd435
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1889117
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For all boards that defined CONFIG_CHARGER, CONFIG_CHARGER_V2 is also
defined. Remove references to CONFIG_CHARGER_V2 from board header files.
Replace CONFIG_CHARGER_V2 in common C modules with CONFIG_CHARGER when
appropriate.
BUG=b:139699769
BRANCH=none
TEST=make buildall -j
Change-Id: I6b54baf4ad2406bbed629b6b272dad9ea6a81280
Signed-off-by: Keith Short <keithshort@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1789420
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change allows us to use the IS_ENABLED condition to replace
the various ifdef guards around the CONFIG_ACCEL_FIFO
BUG=b:137758297,chromium:981990
BRANCH=None
TEST=buildall and CTS tests on Arcada
Change-Id: I65d36bac19855e51c830a33e6f3812575e8d15d9
Signed-off-by: Yuval Peress <peress@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1704164
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The extentions were added to make the compiler perform most
of the verification that the conversion was being done correctly
to remove 8bit addressing as the standard I2C/SPI address type.
Now that the compiler has verified the code, the extra
extentions are being removed
BUG=chromium:971296
BRANCH=none
TEST=make buildall -j
TEST=verify sensor functionality on arcada_ish
Change-Id: I36894f8bb9daefb5b31b5e91577708f6f9af2a4f
Signed-off-by: Denis Brockus <dbrockus@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1704792
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Opt for 7bit slave addresses in EC code. If 8bit is
expected by a driver, make it local and show this in
the naming.
Use __7b, __7bf and __8b as name extensions for i2c/spi
addresses used in the EC codebase. __7b indicates a
7bit address by itself. __7bf indicates a 7bit address
with optional flags attached. __8b indicates a 8bit
address by itself.
Allow space for 10bit addresses, even though this is
not currently being used by any of our attached
devices.
These extensions are for verification purposes only and
will be removed in the last pass of this ticket. I want
to make sure the variable names reflect the type to help
eliminate future 7/8/7-flags confusion.
BUG=chromium:971296
BRANCH=none
TEST=make buildall -j
Change-Id: I2fc3d1b52ce76184492b2aaff3060f486ca45f45
Signed-off-by: Denis Brockus <dbrockus@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1699893
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CONFIG_MKBP_WAKEUP_MASK is a bit confusing and is wrongly named. The
comment stated that "With this option, we can define the MKBP wakeup
events in this mask (as a white list) in board level, those evets allow
to interrupt AP during S3.". However, these events are NOT MKBP events
at all but are instead host events. This commit tries to clear things
up by renaming CONFIG_MKBP_WAKEUP_MASK to
CONFIG_MKBP_HOST_EVENT_WAKEUP_MASK to better show that these events are
in fact host events.
BUG=b:136282898
BRANCH=None
TEST=`make -j buildall`
Change-Id: I42beadec8217435fd30e679ccf52d784a8ef99a0
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1685784
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Alexandru M Stan <amstan@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, tcpc_config assumes TCPCs are on I2C bus. ITE's EC has an
embedded TCPC.
This patch adds bus_type field to struct tcpc_config_t so that a TCPC
location on other type of bus can be specified.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=none
BRANCH=none
TEST=buildall
Change-Id: Ieac733011700b351e6323f46070dcf46d9e1154b
Reviewed-on: https://chromium-review.googlesource.com/1640305
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes requires all boards to define the maximum number
of sensors they support. This will allow us to later create
static arrays with the appropriate length.
BUG=chromium:966506
BRANCH=None
TEST=make buildall
Change-Id: I5a2fa8f0fdcaef69065dfd4c2bfea4e3f371e986
Signed-off-by: Yuval Peress <peress@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1637414
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's simply a bad idea to describe a macro in multiple locations.
It'll make it hard to change. It'll be difficult to keep all
locations in sync.
This patch replaces the comment duplicated in all ec.tasklist with
a pointer to the CONFIG_TASK_LIST definition. The macro will be
described in a single place (just like all/most other macros).
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=none
BRANCH=none
TEST=buildall
Change-Id: Id658b9d68e742e4334c692b804d9c98c8de21313
Reviewed-on: https://chromium-review.googlesource.com/1551579
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Define macros to define custom events used by sensor interrupt handlers.
Remove CONFIG_ for activity events.
BUG=none
BRANCH=none
TEST=compile, sensors work on eve.
Change-Id: I08ef6ed2a004466ebc5f7650d6952a150b9de713
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1272189
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|