| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace them with charger_get_input_current_limit which is
aligned to the old usage, no funcional changes.
Keep OCPC charger_get_input_current uses as was, since it
is its intended use.
Also, implement
- isl923x_get_input_current, raa48900_get_input_current
- sm5803_get_input_current_limit
BUG=b:171853295
TEST=1. grep "\<charger_get_input_current\>"; only ocpc uses the function.
2. make buildall
3. test with CL:2569086 on waddledee(sm5803), waddledoo(raa489000),
hayato(isl923x), pompom(isl923x), and ensure the output
of `curr 0|1` equalts to the report of power meter.
BRANCH=none
Change-Id: I71aca33cbc88dda9b0238cb71b1609665a9c9a7f
Signed-off-by: Eric Yilun Lin <yllin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2569085
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
charger_set_input_current was actually sets the input current limit,
so renames it to charger_set_input_current_limit.
BUG=b:171853295
TEST=make buildall
TEST=not output from `grep -r "\<charger_set_input_current\>"`
BRANCH=none
Change-Id: Icf4e99f287a7d4fc2d9560e8502e46cc07bfc085
Signed-off-by: Eric Yilun Lin <yllin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2569083
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Casta needs to support 2 chargers(ISL9238 & BQ25710)
BUG=b:168122776
BRANCH=firmware-octopus-11297.B
TEST=None
Signed-off-by: YongBeum.Ha <ybha@samsung.corp-partner.google.com>
Change-Id: I18758acbd0920132c2958bf9d238b4eac3fb5b73
Signed-off-by: YongBeum.Ha <ybha@samsung.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2428354
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To support linking multiple bc12 drivers into ec binary, we have to
remove the common symbols in drivers.
This CL creates a bc12_drv structure to hold the original driver-specific
usb_charger_* functions, and implements common usb_charger_* functions
which whill dispatch the function call based on the information in
bc12_drv table.
Also add a CONFIG_BC12_SINGLE_DRIVER and enabled by default for
backward compatibility. If CONFIG_BC12_SINGLE_DRIVER is defined,
a default bc12_drv array with proper size and content will be created
for the board.
BUG=b:155611686
TEST=1) make buildall.
2) verify single driver mode on krane (rt946x) and juniper
(pi3usb9201).
3) verify multiple driver works on asurada, see CL:2189624 for
example usage.
4) verify single driver multi chip on blooglet.
BRANCH=none
Signed-off-by: Ting Shen <phoenixshen@google.com>
Change-Id: I8a96eda47c94aeb6cc150b498cfa1a6eefcc4a5b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2187080
Reviewed-by: Jett Rink <jettrink@chromium.org>
Commit-Queue: Ting Shen <phoenixshen@chromium.org>
Tested-by: Ting Shen <phoenixshen@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Type-C specification now prohibits proprietary methods for BC 1.2
to be used over Type-C. In effect, this limits the maximum current
for legacy chargers to be 1.5A. Technically, proprietary methods are
not allowed, however we'll continue to allow them but limiting their
maximum current to 1.5A.
This commit changes the maximum current of our BC 1.2 detectors to be
1.5A for all suppliers that would have reported higher capabilities.
For more information, see the USB Type-C Engineering Change Request
titled "Removal of Proprietary Charging Methods".
BUG=b:155337959
BRANCH=hatch,kukui,kevin
TEST=Build and flash waddledee, verify that legacy supplier is limited
to 1.5A.
TEST=`make -j buildall`
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: Ifb8dbde519cd2efe17a27197460291708bef125c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2172777
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The other driver structure members return an ec_error_list value and
fill in parameters to return data. This commit changes the
get_vbus_voltage call to follow that model.
BRANCH=None
BUG=b:147672225
TEST=builds
Change-Id: I7308502a9734274dd308b830762493c4d70d147a
Signed-off-by: Diana Z <dzigterman@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2015340
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With upcoming boards which use multiple charger chips, the EC codebase
needs to be changed to assume chargers may have different I2C ports.
This commit creates the driver structure and wrapper functions, which
for now are hard-coded to chip 0 for equivalent behavior with previous
code. A general charger config is created for all boards in charger.c
for now, which uses the build information to fill in the structure.
All boards will default to defining CONFIG_CHARGER_SINGLE_CHIP, which in
turn defines a CHARGER_SOLO which can be used by drivers which have code
that needs to determine charger numbers. For boards which have multiple
chips, they may undefine this config and should generate build errors if
their driver is still using the hardcoded charger reference of
CHARGER_SOLO. Older drivers may continue using CHARGER_SOLO in
non-static functions until they're needed in a multiple charger board.
For boards which may be supporting different I2C configurations for the
charger over board versions, they may define
CONFIG_CHARGER_RUNTIME_CONFIG to fill in these fields after boot.
BRANCH=none
BUG=b:147672225
TEST=builds, chargers on hatch and octopus work
Change-Id: I390ede494226252e512595c48099fa1288ffe93e
Signed-off-by: Diana Z <dzigterman@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2008451
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Certain SKUs of certain boards have less number of USB PD ports than
configured in CONFIG_USB_PD_PORT_MAX_COUNT. Hence define an overrideable
board specific helper to return the number of USB PD ports. This helps
to avoid initiating a PD firmware update in SKUs where there are less
number of USB PD ports. Also update charge manager to ensure that absent/
invalid PD ports are skipped during port initialization and management.
BUG=b:140816510, b:143196487
BRANCH=octopus
TEST=make -j buildall; Boot to ChromeOS in bobba(2A + 2C config) and
garg(2A + 1C + 1HDMI config).
Change-Id: Ie345cef470ad878ec443ddf4797e5d17cfe1f61e
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1879338
Tested-by: Karthikeyan Ramasubramanian <kramasub@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Commit-Queue: Karthikeyan Ramasubramanian <kramasub@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mechanical replacement of bit operation where operand is a constant.
More bit operation exist, but prone to errors.
Reveal a bug in npcx:
chip/npcx/system-npcx7.c:114:54: error: conversion from 'long unsigned int' to 'uint8_t' {aka 'volatile unsigned char'} changes value from '16777215' to '255' [-Werror=overflow]
BUG=None
BRANCH=None
TEST=None
Change-Id: I006614026143fa180702ac0d1cc2ceb1b3c6eeb0
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1518660
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, charge_manager_update_charge does not handle NULL pointer
for struct charge_port_info any differently. It's not sanity-checked
either (thus memory access violation can occur).
This patch will make charge_manager_update_charge accept NULL pointer
and set available current and voltage to zero.
This also helps callers' intentions be clear because callers can
explicitly specify NULL (instead of passing a pointer to chg = {0},
which is initialized somewhere else).
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=none
BRANCH=none
TEST=buildall
Change-Id: I518662ab6a3a07f93da5d34cf62a6f856884f67d
Reviewed-on: https://chromium-review.googlesource.com/1226125
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, available current is consistently set to zero when a supplier
is disconnected across BC 1.2 drivers, PD task, usb charger task but
voltage is set to zero only in some places.
This patch will set available voltage consistently to 0 on disconnected
ports.
This change should have no impact externally or internally because
currently ports are treated as a disconnected port as long as available
current is zero.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=chromium:841944
BRANCH=none
TEST=Verify ectool usbpdpower 1 return 'Port 1: Disconnected' and
'Port 1: SNK (not charging)' without and with a BJ adapter connected
respectively on Fizz.
Verify ectool usbpdpower prints 'Disconnected' and 'SNK Charger PD'
on Vayne without and with USB-C charger, respectively.
Verify ectool usbpdpower prints 'Disconnected' and 'SNK Charger Type-C'
on Vayne without and with a phone USB-C charger, respectively.
Change-Id: I9aca575a4a4240ec1f669c55437decaedf758a77
Reviewed-on: https://chromium-review.googlesource.com/1222092
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a charge port is selected and VBUS is 5V, the inrush current causes
VBUS to droop which could signal a sink disconnection.
To mitigate this problem, charge port selection is delayed until VBUS
is stable or 1s has passed. Before 1s has passed, PD will hopefully have
negotiated a VBUS voltage of at least 9V.
This CL is also a workaround for the issue outlined in b:74753447
Signed-off-by: Sam Hurst <shurst@chromium.org>
BUG=b:69439094
BRANCH=None
TEST=`make -j buildall`
Manual tested with Belkin Express Dock and Moshi audio adapter.
Test Belkin with following configuration:
PORT0: PORT1:
Belkin OPEN
OPEN Belkin
Belkin Blackcat
Blackcat Belkin
Belkin EC terminal output:
Port 0:
[654.645288 TCPC p0 Exit Low Power Mode]
C0 st14
C0 st15
C0 st17
C0 st18
C0 st19
Requested 5000 V 3000 mA (for 900/900 mA)
C0 st20
C0 st21
C0 st22
C0 st23
C0 st24
C0 st23
C0 st26
C0 st27
C0 st28
C0 st29
[655.375668 New chg p0]
C0 st5
[655.380708 Ramp reset: st1]
[655.381704 CL: p0 s8 i500 v5000]
[655.392598 New chg p0]
[655.393574 Ramp reset: st1]
[655.394504 CL: p0 s2 i3000 v5000]
C0 Req [4] 15000mV 3000mA
[655.512126 New chg p0]
[655.514456 Ramp reset: st1]
C0 st715219 CL: p0 s0 ]
C0 st8
[655.639762 Ramp reset: st1]
[655.640301 CL: p0 s0 i3000 v15000]
[656.688735 AC on]
[657.385539 Ramp p0 st5 3000mA 3000mA]
[657.471108 Battery 70% / 7h:36 to empty]
[659.721858 charge_request(8800mV, 5376mA)]
[660.973258 charge_request(8800mV, 3712mA)]
[697.506594 Battery 71% / 1h:1 to full]
Port 1:
[729.384242 TCPC p1 Exit Low Power Mode]
C1 st2
C1 st3
C1 st14
C1 st15
C1 st17
C1 st18
C1 st19
Requested 5000 V 3000 mA (for 900/900 mA)
C1 st20
C1 st21
C1 st22
C1 st23
C1 st24
C1 st23
C1 st26
C1 st27
C1 st28
C1 st29
[730.339719 New chg p1]
[730.340602 Ramp reset: st1]
[C1 st5
730.341457 CL: p1 s8 i500 v5000]
[730.356552 New chg p1]
[730.357311 Ramp reset: st1]
[730.358095 CL: p1 s2 i3000 v5000]
C1 Req [4] 15000mV 3000mA
[730.478577 New chg p1]
[730.480986 Ramp reset: st1]
[730.481829 CL:Cp1 s0 i500 v15]
C1 st8
[730.607116 Ramp reset: st1]
[730.607813 CL: p1 s0 i3000 v15000]
[731.654877 AC on]
[732.345420 Ramp p1 st5 3000mA 3000mA]
[732.589802 Battery 71% / 10h:28 to empty]
[734.340030 charge_request(8800mV, 5376mA)]
[735.091263 charge_request(8800mV, 3712mA)]
[767.879314 Battery 72% / 1h:1 to full]
Tested Moshi with followint configuration:
Port0: Port1:
Moshi-pwr OPEN
OPEN Moshi-pwr
Moshi-pwr Blackcat
Blackcat Moshi-pwr
Moshi-audio OPEN
OPEN Moshi-audio
Moshi-audio Blackcat
Blackcat Moshi-pwr
Moshi-pwr-audio OPEN
OPEN Moshi-pwr-audio
Moshi-pwr-audio Blackcat
Blackcat Moshi-pwr-audio
Moshi EC terminal output:
[2330.883267 TCPC p0 Low Power Mode]
[2330.883664 TCPC p0 reset!]
[2330.916049 TCPC p0 Low Power Mode]
[2330.916475 TCPC p0 reset!]
[2330.934010 TCPC p0 Exit Low Power Mode]
C0 st14
C0 st15
C0 st17
C0 st18
C0 st19
Requested 5000 V 3000 mA (for 3000/3000 mA)
C0 st20
C0 st21
C0 st22
C0 st23
C0 st24
C0 st23
C0 st26
C0 st23
C0 st27
C0 st28
C0 st29
[2332.398132 New chg p0]
[2332.398883 Ramp reset: st1]
[2332.399745 CL: p0 s8 i500 v5000]
C0 st5
[2332.476132 New chg p0]
[2332.476933 Ramp reset: st1]
[2332.477705 CL: p0 s2 i3000 v5000]
C0 Req [4] 15000mV 2970mA
[2332.493597 New cCg p0C0 st7
]
[2332[2332.5001C0 st8
[2332.674727 Ramp reset: st1]
[2332.675510 CL: p0 s0 i2970 v15000]
[2333.668216 AC on]
[2334.403481 Ramp p0 st5 2970mA 2970mA]
[2334.450155 Battery 80% / 11h:18 to empty]
[2335.448877 charge_request(8800mV, 5376mA)]
[2336.699875 charge_request(8800mV, 3712mA)]
[2356.466385 Battery 81% / 1h:1 to full]
Change-Id: Iba909c252094c0e5ca4cf974aabcfe1eaf002efd
Reviewed-on: https://chromium-review.googlesource.com/1130000
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds an optional console command that will dump the contents
of the battery charger IC registers. Currently, the only chargers
supported are the BD9995x as well as the ISL923x.
BUG=None
BRANCH=None
TEST=Enable on meowth; Flash; Verify that the command works without any
issues.
Change-Id: I2221efe0ed6e0f6063c97547e0da2d775bf4da45
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1016004
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
VSYS_PRIORITY in the register VIN_CTRL_SET is set during bd9995x
initialization to ensure VSYS remains up and stable during deeply
discharged battery conditions. However, outside of this case, this bit
should remain cleared.
If set, there the input current limit is disabled between the time
that the boost converter is enabled (USB_SUS = 0) and charging is
enabled (CHG_EN = 1). This can lead to too much current being drawn
which results in the connecting port shutting off VBUS due to its
overcurrent protection. This has been observed when attempting to
charge one DUT from another chromebook port, or with a Type C only
charger.
This CL adds a check in the bd99965x driver implementation of
charger_get_voltage() that compares the current battery voltage to
its minimum voltage. If it's higher, then it's not a deeply discharged
battery and VSYS_PRIORITY can be cleared.
BUG=chromium:69143827,71814128
BRANCH=coral,eve
TEST=Tested with 2 Coral DUTs. Verified that VSYS_PRIORITY gets
cleared when the charger state machine gets the charger
parameters. Also verified that I can repeatedly initated charging from
one Coral device to another. Without this fix, this would fail most of
the of the time. Also tested Eve with deeply discharged battery to
make sure the startup conditon still works.
Change-Id: I5230560fa98e5bf16921eb4f2c70802eb962e7f3
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/875178
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On ISL923x, PSYS output is always enabled when the AP is on
(provided CONFIG_CHARGER_PSYS is enabled).
We add support for charger_get_system_power function, reading PSYS
value, when CONFIG_CHARGER_PSYS_READ is defined. This will be used
by the charging algorithm on lux.
We also rename CONFIG_CMD_CHARGER_PSYS to CONFIG_CHARGER_PSYS_READ
as CONFIG_CHARGER_PSYS_READ provides both "psys" console command
and the new function. We also cleanup unneeded undefs in board
files.
Note that this does not implement the function on bd9995x, but this
could be done without too much effort.
BRANCH=none
BUG=b:71520677
TEST=On lux, without AC connected, check that "psys" output roughly
matches the output current from the battery.
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Change-Id: Ie1ce8e0ac103daacc5a08b8ccae604d1d83551b8
Reviewed-on: https://chromium-review.googlesource.com/848487
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order for BC1.2 detection to succeed, USB data switches must be
open. Previously we performed BC1.2 detection whenever VBUS transitioned
up to 5V, including on power swap. In fact, there is no need to do BC1.2
detection on a PD-capable port, since we will always charge using the
USB-C or PD negotiated ILIM. Skip BC1.2 detection on power swap (and
more generally when a partner port is known to speak PD) by manually
triggering BC1.2 detection. In addition, manage USB switch state
differently, so that "auto mode" is only enabled during BC1.2 detection.
BUG=chromium:780905
BRANCH=gru
TEST=Attach USB-PD phone capable of role swap. Verify USB 2.0 device is
enumerated on plug, and not re-enumerated through a series of
"pd # swap power" commands on the EC console. Also verify BC1.2 charging
and PD charging are still functional on kevin.
Change-Id: I1d7d4dee3bc8d2e7885e7adb49ded84b4f515ad5
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/755878
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bd9995x driver was written to allow any PD port # to be VBUS or VCC,
but the mapping is broken in a few places. Since all boards use VBUS =
port 0, remove the conversion entirely.
BUG=chromium:781849
BRANCH=kevin
TEST=Verify PD and BC1.2 charging still works on kevin.
Change-Id: I3687866835d1684342d9f746d91b3a6079ab5cc4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/755000
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The decision on whether to ramp (and how high) depends on the quirks of
charger identification, so move the decision out of board, into the
drivers that implement usb_charger.
Also, rename CONFIG_CHARGE_RAMP to CONFIG_CHARGE_RAMP_SW, to better
contrast with the existing CONFIG_CHARGE_RAMP_HW.
BUG=None
TEST=Manual on kevin, verify ramp occurs when port plugged into Z840
workstation.
BRANCH=None
Change-Id: I5b395274133837a18a4f4ac34b59b623287be175
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/702681
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=chromium:700933
BRANCH=None
TEST=`make buildall -j`
Change-Id: Id76fe93612fcd1ef924d7fa94479c45a52db046b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/648566
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Zero ITERM_SET to keep the charger out of topoff mode, since it has
undesirable side-effects related to dead / low battery charging.
BUG=b:35575421
BRANCH=reef
TEST=Previous testing on kevin with same register setting.
Change-Id: Ic1dd280e1069d410895498c0f72989654a6b8c63
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/636152
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tasks are defined inconsistently across the code base.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
TEST=make buildall -j, also verify kevin boots to OS
BUG=none
Change-Id: I19a076395a9a8ee1e457e67a89d80d2f70277c97
Reviewed-on: https://chromium-review.googlesource.com/602739
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the function bd9995x_battery_charging_profile_settings, the current
values for trickle, precharge, and fastcharge were being set. Fastcharge
current level was being set via
charger_set_current(PD_MAX_CURRENT_MA). By calling this function with
a non-zero parameter, charging will always be enabled. In addition,
PD_MAX_CURRENT_MA is an input current limit and doesn't neceassrily
apply to the fastcharge current level which would be read from the
fuel gauge. The other side effect is that by enabling charging, VSYS
is being set to battery->voltage_min which reverts VSYS being set to
battery->voltage_max in the init routine.
Per Rohm, all charging profile registers should be set prior to
enabling charging. On Coral, enabling charging at this point was
leading to VSYS collapse when no battery was connected or a fully
depleted battery case. I also believe that enabling charging here
exacerbates other issues we've been running into with low battery
startup cases.
BUG=b:64388515
BRANCH=eve
TEST=On Coral tested both no battery a fully depleted battery
cases. Verified that without the call to charger_set_current() that
VSYS consistently collapses and that after removing this call, the
start up was stable and the battery begins charging.
Change-Id: Ice20ed5d8147fe9ad8faa754286a2ec8a784f8d8
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/602493
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The initial value for input current limit is set to
CONFIG_CHARGER_INPUT_CURRENT which is typically 512 mA. In deeply
discharged battery cases (Vbat < 5.8V), the 512 mA input current limit
can cause VSYS to collapse which in turn causes the EC to
reset. Depending on how discharged the battery is, the EC may remain
off until the external charger is disconnected and reconnected again,
or it may undergo a number of reset cycles, each time charging the
battery just a little, until Vbat becomes > ~5.8V and the charger is
able to stabilize. When the charger type is determined, either from
BCD detection, or Type C/USB PD, the input current limit is set to the
appropriate level.
In order to avoid the issue described above, this CL sets a bit in the
VIN_CTRL_SET register which will disable the input current limit in cases
Where the VBAT is less than the VSYSREG_SET value.
BUG=b:35648317
BRANCH=none
TEST=Manually tested on Electro.
a. With Zinger attached DUT boots without the battery after
plugging in AC
b. DUT boots from cut-off battery
c. With Zinger attached DUT boots from cold-reset without the
battery
d. With no battery & DCP charger, anti-collapse occurs,
input current is limited to 512mA & the DUT is
power-up inhibited.
Tested also on Eve with signal wires attached to both PPVAR_VSYS,
PP3300_DSW, and Vbat. Verified that on certain boards (some board to
board variation) that PPVAT_VSYS would collapse when the input current
limit was set to CONFIG_CHARGER_INPUT_CURRENT. Then after adding this
CL, verifed on the scope that the collapse of PPVAR_VSYS no longer
occurred.
Change-Id: Ief9960550f988e69ab4637db85450e91c70d3b51
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/456049
Commit-Ready: Vijay Hiremath <vijay.p.hiremath@intel.corp-partner.google.com>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Vijay Hiremath <vijay.p.hiremath@intel.corp-partner.google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function bc12_detect was using a msleep(312) to allow for enough
time for the bd9995 to determine the charger type. Putting the USB_CHG
task to sleep for this period of time means that the USB_CHG task is
not able to process interrupts from the bd9995 during that time. This
is a particular problem when Try.SRC is enabled and a charger is
connected. VBUS will only remain present for ~40-50 msec, and
when it goes away, the discharge circuit should be engaged. However,
the USB_CHG task is still in the 312 mSec sleep from when VBUS was
detected. The result is that discharge circuit is not engaged. It was
observed that processing of charger interrupts could be delayed
upwards of 500 msec.
On Eve with the EVT charger, VBUS was not discharging without the
discharge circuit being enabled. This resulted in excessive connect
time as the Try.SRC cycle repeated many times until a case where the
discharge circuit was not disabled when VBUS detect occurred and this
finally allowed the charger to attach.
This CL modifies the USB_CHG task main loop so that a wait timer is
used when bc12_type needs to be read from the charger. There is a wait
timer mark per port. If the mark value is 0, then a wait timer is not
required and the task is put to sleep with -1. Each time the task is
woken, either from the interrupt or wait event timer, the current time
is checked against the timer mark for each port. The function that
reads the bc12_type will return a 1 if the type is still not available
and will return 0 if either VBUS is no longer present, or the
bc12_type was successfully determined.
With this change in place the discharge circuit is reliably
enabled/disabled within ~5-10 mSec of VBUS changes.
BUG=b:37292010
BRANCH=reef,gru
TEST=Manual
Added signal probe wires to VBUS, discharge control, and charger
interrupt signals. Connected eve EVT charger and verified that the
discharge circuit is consitently enabled when VBUS is removed
following the initial attach in Try.SRC. Verifed that the EVT charger
always connects on the first attempt.
Also tested with various different chargers on both Eve and Reef
platforms. In addition, temporarily changed the initial deferred time
to 100 mSec and validated the path where vbus_provided is not true and
that additional deferred calls were initiated until bc12_type is valid.
Change-Id: Idd066b5461ec4cbb77bb023519fed90c9e9f71db
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/487028
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If charging current is set to 0mA during charging, reference of
charge current feedback amp (VREF_CHG) is set to 0V. Hence the DCDC
stops switching (because of the EA offset). To eliminate this issue,
disable/enable charger depending on the charging current is zero
or non-zero respectively.
BUG=b:37413065
BRANCH=reef
TEST=test 'ectool chargecontrol normal/idle/discharge' are working
Change-Id: Id31876afe365a476fb906e059ab519b7a0c9a7c6
Signed-off-by: james_chao <james_chao@asus.com>
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/486101
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit 6da9ed8786e90ee91b39934180fe84e01ac30260)
Reviewed-on: https://chromium-review.googlesource.com/489812
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch disables IADP immediately after the EC boots. We
observed noise on IADP/RESET pin causing SEL_ILIM_VAL to
randomly change. This seems the cause of b:35648317.
We enabled IADP to fix b:35647661 initially and also followed
the vendor's recommendation. However, the issue is only
reproducible on the particular board which was used for power
measurement and we did not see the issue on other boards with
IADP disabled.
Also the vendor assumed our EC doesn't control IBUS_LIM_SET
and ICC_LIM_SET. (I think they assumed like other thier customers
our EC controls ILIM by DAC connected to IADP/RESET pin.) If ILIM
is not set by EC and IADP is disabled, the system would brownout
because ILIM stays at 128mA. Therefore, it was (mistakenly)
recommended that our EC should keep IADP enabled.
Cros EC configures IBUS_LIM_SET and ICC_LIM_SET dynamically thus
the above concern does not apply.
We also found that we have too much noise on IADP/RESET pin. The
noise is not big enough to cause the chip to reset but it's big
enough to cause ILIM to fall in 128mA zone. We think this is why
the boards fail to boot from battery cutoff or no battery.
(Contrary to the vendor's explanation, it seems IADP/RESET pin
continusouly affects ILIM not only in the early chip power-up
period.)
BUG=b:35648317
BRANCH=none
TEST=Booted two Electro and two Snappy from 1) dead battery 2) no
battery 3) battery cutoff.
Change-Id: Ic675f1354b9ef222ceec8ce112b19713812d2752
Reviewed-on: https://chromium-review.googlesource.com/458676
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the charging current is less than the BD9995X's minimum charging current
it is overwritten to BD9995X's minimum charging current. However in idle
mode we write the charging current which is known to the charger during
that time, which can be less than the BD9995X's charging current. Hence,
do not overwrite the charging current in idle mode.
BUG=b:35984679
BRANCH=none
TEST=Manually tested on Electro. In idle mode charge current is 0mA.
Change-Id: I2e605b63c8519383c6a62d76718bc52660e7270e
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/453999
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IADP monitoring bit was set to the default value for the devices
with an RO image which clears the bit (and causes the issue).
This patch removes the code so that we do not touch the IADP
monitoring bit since transitioning from 0->1 may cause other issues.
BUG=b:35647661
BRANCH=reef
TEST=none
Change-Id: I4413e0bd2de3f4e3912cbe6e73b8cad641ee9245
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/453400
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/453798
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
charge_ramp needs to make a decision based upon the VBUS level on one
specific port - the port that is ramping. The VBUS level on any other
charge ports (if present) is not relevant.
BUG=chrome-os-partner:54099
BRANCH=reef, gru
TEST=With subsequent patches, verify charge_ramp success with a variety
of BC1.2 chargers.
Change-Id: Ie0a51a577e2b7491222560cd08dd5321ff3b7975
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/435561
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Setting the VSYSREG_SET register as per Charge State Machine of
the BD9995X datasheet.
1. Set VSYSREG_SET <= VBAT so that the charger is in Fast-Charge
state when charging.
2. Set VSYSREG_SET > VBAT so that the charger is in Pre-Charge
state when not charging or discharging.
BUG=chrome-os-partner:55220
BRANCH=none
TEST=Manually tested on Reef. Observed 'Charger State Machine Status'
register value when charging it is in Fast-Charge state and
when not charging/discharging it is in Pre-Charge state.
Change-Id: I5cd5afa92384acb4fd9d69128a2a03ae6992dc5b
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/430880
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The nvdc voltage has a kind of deep, so that rarely observed
NVDC down at this point because of back-boosting.
Our sequence to enable charger bit and setting vsysreg
is correct but rohm introduce charger may need some more time
to be stable when between chg_en and vsys_set to start charge
BUG=chrome-os-partner:60380
BRANCH=gru
TEST=Manual on kevin, trigger battery disconnect, re-attach AC, verify
system boots cleanly. and see voltage probing on c54@60380
Change-Id: Ic05091379322ffaac16fe827a47345c76c85f3e5
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/434252
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(From CL 431233)
Limit battery charge voltage to prevent battery over-charge, due to
regulation inaccuracy. Since RO FW may charge > 8656 mV, ensure the
battery is not full before charging.
BUG=chrome-os-partner:61906
BRANCH=none
TEST=Manual on Electro, sysjump with battery @ 99%, verify battery
discharges, then re-charges to 100%, before discharging once again.
Change-Id: I28212c83057a442fd75e39f8ad51927a7a1f2817
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/432857
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Charger Operation Control Setting 1 (CHGOP_SET1) has separate bits to
disable input current limitation for DCP, SDP, others. If it is not
disabled, input current is automatically selected, which results in
hard resets on weak chargers hence disable the input current
limitation for all types of chargers.
BUG=chrome-os-partner:60722
BRANCH=none
TEST=Tested on Reef. Input current is not automatically set to all
types of chargers.
Change-Id: Ideb16ac2a40b403c94c28e85f254043ead7415e0
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/417234
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the battery is fully charged or not charging, upon removal of
the AC, discharge takes long time. To overcome this issue suspend
the DC-DC converter when discharging on AC.
BUG=chrome-os-partner:58969
BRANCH=none
TEST=Manually tested on reef. Discharge is in the permissible range.
'chgstate' console command prints correct values.
Change-Id: I64afa992e50b6e18daf43edf237fde8cf658a8a2
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/413153
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Charger BGATE is off on POR hence the voltage to the battery pack is
not applied immediately from the VBUS. To overcome this issue, BGATE
is turned on (CHG_EN) at charger initialization. If the voltage across
VBATT is high but I2C is still failing, battery is booting from ship
mode hence overwrite the battery as not present till I2C on battery
is success and INIT bit is set.
BUG=chrome-os-partner:59308
BRANCH=none
TEST=Reef can boot to OS from shipmode battery.
Change-Id: If1b212612e27fd65a822675a9609f0a8c03d8add
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Signed-off-by: Divya Sasidharan <divya.s.sasidharan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/411360
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added battery charging profile settings as given in the datasheet.
BUG=chrome-os-partner:58553
BRANCH=none
TEST=Manually verified on reef. VBAT is equal to battery voltage.
Previous/current Charge status is equal to the conditions given
in the datasheet.
Change-Id: Ie04619a122fe52d6768c03ff5156b368e3f2d340
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/398080
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=chrome-os-partner:54248
BRANCH=gru
TEST=Manual on kevin, high temperature chamber(60C),
battery will require 0 voltage because of high temp,
then check 'chgstate' vbat maintained at 8688 mV.
Change-Id: I3b5835701c42a0cd861400ba921b3d3797152bbd
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/400088
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'else' was missing in the for the check of
port == BD9995X_CHARGE_PORT_BOTH. So if it wasn't this port type then
it would always hit the panic.
BUG=chrome-os-partner:59189
BRANCH=none
TEST=Manual
Verfied the failure case using a type C to type A adapter. After
applying the fix verified that it no longer panics.
Change-Id: Ia5a16c39e226d5e648c20d0c8675d6433d083f22
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/405747
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Turn off the charger BGATE when the system is hibernated to
save maximum power.
BUG=chrome-os-partner:59001
BRANCH=none
TEST=Manually verified on the Reef.
System can boot from hibernate wake sources.
Following are the power measurement values at Battery
voltage = 8.3V & temperature = 23 deg C.
a. Normal operation 540uA, 3.500mW
b. BGATE OFF 80uA, 0.592mW
Change-Id: Ia30655ccefbf0dded623246150d53b2a815df2de
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/404685
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
POR has both VCC & VBUS enabled. If the port is sourcing VBUS it will
also act as sync and AC_OK pin gets enabled. Hence disable the input
to the port when sourcing.
BUG=chrome-os-partner:59020
BRANCH=none
TEST=Manually verified on Reef. Connected HoHo and AC_OK is not
enabled.
Change-Id: Ic51b81f45759d7dddb2c9744d1c24dbafd1e1293
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/404168
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If BD9995X_CMD_MAP_SET fails, the charger's internal map command set
may be the old set (if the charger failed to process the command) or the
new set (if the EC failed to receive the response). Therefore, reset the
EC's known map command state on failure, so that it will always be
re-set on the next transaction.
BUG=None
TEST=Build + boot kevin.
BRANCH=Kevin
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Id16273ccf2e39b5aae7776d626aae8863e713df5
Reviewed-on: https://chromium-review.googlesource.com/390318
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=chrome-os-partner:55771
BRANCH=none
TEST=make -j buildall
TEST=bd9995x r 0x0f 1; verify 0x00.
Change-Id: Ibfca44599b8a6d631215b2c9a50e810312559f3a
Reviewed-on: https://chromium-review.googlesource.com/388819
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added i2ctest console command to test the reliability of the I2C.
By reading/writing to the known registers this tests provides the
number of successful read and writes.
BUG=chrome-os-partner:57487
TEST=Enabled the i2ctest config on Reef and tested the
i2c read/writes.
BRANCH=none
Change-Id: I9e27ff96f2b85422933bc590d112a083990e2dfb
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/290427
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
Except the CHIP_ID and charger name code is common between BD99955
and BD99956. Hence renamed the code to BD9995X so that valid
output is printed from console commands.
BUG=chrome-os-partner:57519
BRANCH=none
TEST=Manually tested on Reef. 'charger' console command prints
charger name as 'bd99956'
Change-Id: I3c995757941bcc5a6a8026dd807d76a7a47c9911
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/387119
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
|