To avoid issues where adapter would drive against OTG of lid or
base, and to make sure that we do not over-current the adapter,
we disconnect the base/lid power transfer whenever a new
adapter is connected.
We reenable power transfer as needed.
We also separate out base current control as a new function,
that allows us to record the previous base current only when
the base charge control command is successful, and ignore
errors until the base is responsive for the first time.
Finally, we make sure that
charge_allocate_input_current_limit is only called from a
single location in charger_task.
BRANCH=none
BUG=b:71881017
TEST=Plug/unplug base, reset lux EC, connect charger.
Base is detected, power allocation works as expected.
Change-Id: I8b206d5b0fbcf0fe868b56a0336745aebe2a6dc2
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/880021
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The logic of drawing as much current as possible when no battery
is connected (on the lid), and system unlocked, makes sense during
early bringup.
However, it will not work when the base is also connected, as we
did not implement the required no-battery logic in the base/lid
power allocation algorithm (nor do we plan to, as it is only
required during very early bringup, when we should not expect
power transfer between lid and base to work properly).
Also, we need to record input_voltage in
charge_set_input_current_limit, even when lid battery is not
present (yet), otherwise the algorithm gets confused and believes
no power is available.
BRANCH=none
BUG=b:71881017
TEST=Boot lux from dead battery and base connected, lux does not
attempt to drive OTG to the base.
Change-Id: I0cdd0956a82a724dbbf9c010760dcb956a58c1bf
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/874982
Reviewed-by: Shawn N <shawnn@chromium.org>
Instead of fetching static battery information all the time, we
first fetch the dynamic information, and see if the flags changed.
If they did, refetch the static information.
This also covers the cases when the base is disconnected/reconnected.
BRANCH=none
BUG=b:71881017
TEST=ectool battery 1 shows correct static battery information after
plug/unplug.
Change-Id: I936983fc0fdc4dae0494e8a24f890927e30555dc
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/872813
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
First version of the algorithm, some TODOs are left in the code
but this, generally, works reasonably well.
When charging, we allocate input current in this general order:
- Base system (fixed, low, number)
- Lid system (based on PSYS)
- Lid battery (estimating how much current the battery actually
requires)
- Base battery (similar estimation)
- Provide everything else to lid
When discharging, we generally:
- First discharge the base battery
- Then discharge the lid battery
BRANCH=none
BUG=b:71881017
TEST=Flash lux and wand, EC-EC communication works, adapter power
is split in a sensible way, and discharging works fine.
Change-Id: I8a4f87963962fc5466b2fedf1347eb4dadd35740
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/659460
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BRANCH=none
BUG=b:65697962
TEST=On wand, battery information is quickly updated after
(un)pluging AC on lid (otherwise we might have to wait up to
60 seconds).
Change-Id: I2bd457ba4d38aa4c99638a2576a4132406416de2
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/859401
Reviewed-by: Shawn N <shawnn@chromium.org>
pwr_avg provides an average voltage, current, and power over the last
1 minute. It's up to the battery drivers to implement this
functionality.
This change allows us to have better power tracking while minimizing
the power impact on the EC, because
- the pwr_avg command only needs to be called once every minute, and is
short, thus less expensive to parse on ECs without a UART buffer
- the work done to keep the avg is partially done by the batteries
already and it's just a question of retrieving it.
undefined on wheatley since no power debugging planned on that board.
usage:
> pwr_avg
mv = 7153
ma = -605
mw = -4327
BUG=chromium:752320
BRANCH=None
TEST=make buildall -j
Change-Id: Id1a3479d277aedf90dfa965afb4ee9136654b1cf
Signed-off-by: Ruben Rodriguez Buchillon <coconutruben@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/823884
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
flags are actually _not_ BATT_FLAG_*, but EC_BATT_FLAG_*. Clarify
that in the comment, and add a new EC_BATT_FLAG_INVALID flag to
indicate that some of the data may be invalid (dual-battery master
needs to know that to make appropriate charging/discharging
decision).
BRANCH=none
BUG=b:65697962
BUG=b:65697620
TEST=Flash hammer and wand, flags make sense.
Change-Id: I3c428c850020a29b3f452504b60b52946a04c503
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/859400
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Without this, the battery will discharge if we disallow battery
charging (e.g. calling charge_request with either voltage == 0 or
current == 0, either by policy, or when the battery is full).
Also update config.h to set the option whenever isl923x is used.
BRANCH=none
BUG=b:66575472
BUG=b:35585464
TEST=make buildall -j
Change-Id: Id5515d5ea82a393a3693a3da44cbdc2778296a95
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/856538
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This function sets up and enables "OTG" mode on the charger chip
(i.e. use the charger to provide power from the battery).
It also records the output current in curr.output_current, to
make sure that the charger loop is aware that current is provided
externally.
We also add a CONFIG_CHARGER_OTG to remove these functions on
boards that do not require it.
BRANCH=none
BUG=b:65697962
TEST=On wand, when discharging, battery status is updated every
5 seconds (and not every 60 seconds).
Change-Id: Ibf93933436f3eb24552a8e1eb9d97522fca2ce79
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/842743
Reviewed-by: Randall Spangler <rspangler@chromium.org>
current is actually a reserved keyword in the Linux kernel,
replace it by actual_current. And voltage by actual_voltage for
consistency.
BRANCH=none
BUG=b:65697962
BUG=b:65697620
TEST=make buildall -j
Change-Id: I8b8115174d15a1cc4b1189a54104bfec559ed72c
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/848460
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
If AC is present but we're not charging yet, it's very possible this
status is transient (eg. due to cut-off battery, brief spike in current
useage, etc), so don't use very long task timeout.
BUG=b:70554834
BRANCH=None
TEST=Verify soraka doesn't take over a minute to boot when exiting from
ship mode.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9dbfd8cb7dfc54cb8017bb0c7d633c5d64a15025
On dual-battery slave, we use the charging allowed signal from
master to indicate whether external power is present.
In most cases, this actually matches the external power status
of the master (slave battery charging when AC is connected, or
discharging when slave battery still has enough capacity), with
one exception: when we do master to slave battery charging (in
this case the "external" power is the master).
BRANCH=none
BUG=b:65697962
TEST=Deplete wand battery to 5%, see that lux still provides power
to it but the battery does not charge.
Change-Id: I8bd9f52c386a0a9edfae3837ba33725b3101a008
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
With this, the EC-EC communication slave (base) updates the battery
information, to be transmitted to the master (lid).
Note that, in the future, we might want to use a similar mechanism
to pass battery information on all boards (not only the ones that
use EC-EC communication to pass information to the lid), and TODO
are left in the code for this reason.
BRANCH=none
BUG=b:65697962
BUG=b:65697620
TEST=Flash lux and wand, EC-EC communication works.
Change-Id: I042138ee066a65c3664fbeb93aadabf483a6ceea
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/725125
Reviewed-by: Randall Spangler <rspangler@chromium.org>
CHARGE_MAX_SLEEP_USEC was originally set to 1 minute (i.e. equal to
POLL_PERIOD_VERY_LONG) in CL:191767. However, during re-factoring in
CL:193876 it got changed to 1 second as charge_state_v1 used this
value. Looking at the way CHARGE_MAX_SLEEP_USEC is used, value of 1
minute makes more sense because sleep_usec could be set to
POLL_PERIOD_VERY_LONG when device is off or suspended. With the
current logic in suspend/off state, sleep_usec is set to
POLL_PERIOD_VERY_LONG and immediately gets reset to
CHARGE_MAX_SLEEP_USEC in charger_task.
This change fixes the above behavior by defining CHARGE_MAX_SLEEP_USEC
as 1 minute. As a side-effect of this, we might not wake up early
enough in case of critical battery. Thus, check if we need to shutdown
on critical battery and adjust sleep time accordingly.
BUG=b:69695376
BRANCH=None
TEST=make -j buildall
Change-Id: Ieba7279dc4b02c3d64022c3c5ac09fb869a3632d
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/788181
Reviewed-by: Shawn N <shawnn@chromium.org>
There are two different types of suspend states that are supported on
x86 platforms -- S3 and S0ix. When AP enters S3, the chipset state is
identified as CHIPSET_STATE_SUSPEND. On the other hand, when AP enters
S0ix, the chipset state is identified as CHIPSET_STATE_STANDBY. There
are several components within the EC e.g. charger state machine, usb
pd task, motion sense task that take actions based on the chipset
suspend state (and checked only for CHIPSET_STATE_SUSPEND until
now). In order to ensure that different EC components do not have to
worry about checking for all the different types of suspend states
that are supported, introduce a new combination
CHIPSET_STATE_ANY_SUSPEND which is a combination of
CHIPSET_STATE_SUSPEND(S3) and CHIPSET_STATE_STANDBY(S0ix).
BUG=b:69690699
BRANCH=None
TEST=make -j buildall. Ruben verified that with this change, EC power
consumption in S0ix drops from 7.85mW to 6.59mW on Soraka.
Change-Id: I599a0ea2fe2f39132764a6068fa77c3aea02affa
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/786919
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The SET sub-command of EC_CMD_CHARGE_STATE sets charger current /
voltage parameters to arbitrary values and should be locked down.
EC_CMD_CHARGE_CONTROL, on the other hand, switches between several safe
operation modes, and should be allowed.
BUG=None
TEST=On kevin, set force_locked, plug zinger, and verify:
ectool chargestate param 4 3 <-- ACCESS_DENIED
ectool chargestate show <-- prints params
ectool chargecontrol idle <-- stops charging battery
ectool chargecontrol normal <-- battery charges again
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5503f07bb196d023a9bcd2e33f2e247f061f05e5
Reviewed-on: https://chromium-review.googlesource.com/757237
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When allowing an unlocked system to automatically power up we
may attempt to boot before the charger is ready to supply enough
power and get stuck in a reset loop.
In addition, if the batttery is not physically present in the system
then delay power-on until the charger is providing at least 15W of
power. (currently defined as LIKELY_PD_USBC_POWER_MW)
By adding a final check to the charge_prevent_power_on() function
to ensure that charge_manager_get_charger_current() is returning
a valid value instead of CHARGE_CURRENT_UNINITIALIZED then the
board is able to reliably boot.
This CL combines 2 CLs made on Eve which addressed the same problem
I'm seeing on Robo devices.
https://chromium-review.googlesource.com/582545https://chromium-review.googlesource.com/709473
BUG=b:68226308
BRANCH=coral
TEST=Used Robo system which was consistently failing when external
power was connected to Port 1. After adding this change was able to
consistently power up the system without going into a reboot loop. In
addition had signal wires attached to VBUS and VSYS so could verify
that VSYS was no longer collapsing.
Change-Id: Iadecf032feaacfda230bfc98a332cd7963fb0afe
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/752755
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Charge port / current selection often needs to be significantly altered
when a battery cannot provide sufficient charge, so have charge_manager
initially enter safe mode. After a battery with sufficient capacity has
been identified, charge manager will leave safe mode, and port / current
selection will return to standard rules.
BUG=chromium:777596
BRANCH=None
TEST=Pass charge_manager unit tests. On kevin, remove battery, attach
Apple PD charger, verify safe mode is not exited and device does not
brown out. Hot-plug battery and verify safe mode is exited. Next,
remove battery, attach to Samus, verify safe mode is not exited and
device doesn't brown out. Hot-plug battery, verify that safe mode is
exited and no active charge port, due to dual-role exclusion.
Change-Id: I7784865750087a037aad8dbbac058b22c77ba6d4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/733954
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Most boards had an identical implementation for this function,
previously known as board_is_consuming_full_charge(). To reduce copy
paste, let's just move it to common code. Boards that charge ramp
without a battery will have to define their own implementation, but
there probably won't be any boards like that in the near future.
BUG=None
BRANCH=None
TEST=make -j buildall
Change-Id: Ic99a378ac26dfd35d7d718bf9376eacfa8609166
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/748919
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The dump_charge_state (chgstate console command) is quite large,
and may get truncated, let's add 2 cflush at approximately
each third of the output.
BRANCH=none
BUG=b:66575472
TEST=On wand, type chgstate in EC console
Change-Id: Iaa87a6a77b9b6edb0bd8235a87297f8d63fe3085
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/678755
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
update_dynamic/static_battery_info update information in the memmap
shared with the host. When there is not host, these functions
cannot do anything.
The battery information will, eventually, have to be passed to
host (through lid EC), but this will be implemented later.
BRANCH=none
BUG=b:66575472
TEST=make BOARD=wand -j
Change-Id: I1640bb0c5a9eb242183b957ccbef4d4999112160
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/678754
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Servo / Suzy-Q related debugging methods is a big challenge
in factory especially after servo debug header is removed.
Expose some information to OS from EC will do a great help
for massive production.
+ expose charge/battery related state to ectool
1. chg_ctl_mode
2. manual_mode
3. battery_seems_to_be_dead
4. battery_seems_to_be_disconnected
5. battery_was_removed
6. disch_on_ac (learn mode state)
BUG=b:65265543
BRANCH=master
TEST=`ectool chargestate param 0x20000~0x20006 get correct state`
Change-Id: Ic2ed38e2eb9def01be29729fa1fe1959eb73fe43
Signed-off-by: Ryan Zhang <ryan.zhang@quanta.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/646412
Reviewed-by: Shawn N <shawnn@chromium.org>
In order to satisfy factory testing requirements we need to
boot a bare board with just an AC adapter without requiring
a power button.
However we also don't want to always allow booting of the
battery is present but cut-off (which will indicate BP_NO so
we can't use the existing battery_is_present function) or has
critically low level as it may not immediately boot.
To accomplish this add a function that allows the board to
specify a custom "hardware presence" for the battery that is
separate from the battery presence check.
This CL is taking a change done for Eve and pulling into TOT so it can
be used for other projects that have the same
requirements. https://chromium-review.googlesource.com/c/582544
BUG=b:63957122
BRANCH=none
TEST=manual
Change-Id: Ib1dc4f659adbf0eebd3dc8c3c61b39b8fa36cb4a
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/627113
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If board selects both CONFIG_BATTERY_CRITICAL_SHUTDOWN_CUT_OFF and
CONFIG_HIBERNATE, then CONFIG_BATTERY_CRITICAL_SHUTDOWN_CUT_OFF should
be given higher preference when deciding what action to take in case
of critical battery.
This is necessary on boards where components like H1 chip could be
consuming more power than is healthy when the battery is already
critically low, depleting it to dangeriously low voltage levels faster
than it should.
(Reference: https://chromium-review.googlesource.com/582543)
BUG=b:64460667
BRANCH=None
TEST=Manual testing to ensure that EC cuts off battery when it is
critically low instead of hibernating on soraka.
Change-Id: I6efacd7206199ca19f1073296b113b6cf18ec655
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/605014
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
The assert in the charge state machine when there is no battery and no AC
is causing a lot of headaches during development, and I don't believe it
adds any value to panic the EC like this as it prevents the system from
coming up and any debug from happening. This is especially bad with H1
locking out any useful debug by preventing flashing the EC.
On Eve EVT we have some 'bad' batteries that are not correctly asserting
presence pin, and when powering with adapter this this check happens before
AC_PRESENT asserts because the USB PD negotiation is still happening so the
EC gets stuck in a reboot loop.
Similarly we had issues with the Krill board in the Whale BFT station that
was triggering the same assert.
In both cases there is an underlying hardware issue which is being
investigated separately, but it is impossible to debug these systems
because the EC will not come up.
With this assert removed the EC and AP can boot and the LED blinks red to
indicate there is battery a problem and the OS also reports a problem that
the battery cannot be found, and we are able to do further debug without
having to open the case. Additionally the error message is printed every
~second and it is very obvious from the EC console that there is a problem.
Similar issues were reported at various points on Glados, Chell, Kevin,
Elm, and Reef.
BUG=b:35563537
BRANCH=none
TEST=successfully boot and debug a failing Eve system
Change-Id: I002b26d54428d29192a7097f1aae18f3223c5707
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/477733
Reviewed-by: Scott Collyer <scollyer@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>
When battery is fully charged, Reef starts discharging to protect
battery and starts charging again when charge level goes down
around 95%. To prevent the battery LED from showing blue with the
charger plugged in, this patch adds a new state for discharge +
nearly full. Reef shows a color indicating battery is full if
an external charger is present.
BUG=b:35775017
BRANCH=none
TEST=Fully charge Electro. Plug in OEM charger. LED lights blue.
Change-Id: I4c7c62f2c51c1d39188d1b271331984e89d5d7a3
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/448961
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
All boards have been transitioned to charge_state_v2.c
So charge_state_v1.c, HOOK_CHARGE_STATE_CHANGE, and
CONFIG_CHARGER_TIMEOUT_HOURS can be removed
BUG=chrome-os-partner:36272
TEST=make -j buildall
BRANCH=none
Change-Id: I3f20c5198ea75185f9894deb792575a1be31432a
Reviewed-on: https://chromium-review.googlesource.com/435467
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
AverageTimeToFull() and AverageTimeToEmpty() are the predicted time based
on the AverageCurrent(), these do not reflect the instant time of charging
or discharging. Hence we observe huge number of time (1092h because
register has 65535) to full time when battery starts accepting current
upon reaching 100%. To overcome this issue, explicitly checking if the
AverageTimeToFull() and AverageTimeToEmpty() register values are updated
with the valid data.
BUG=chrome-os-partner:60802
BRANCH=none
TEST=Manually tested on Reef. Charge the battery to 100%, once the
battery starts accepting current again observed time to full
is not huge number.
Change-Id: I6d6c21b72ab824dbe47e44e1e77f1c5319ac2720
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/425324
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>
Added common code for charger profile override for fast charging.
Fast charging configs can be defined in the respective board battery
file and use the common code for imposing the custom data.
BUG=chrome-os-partner:59393
BRANCH=none
TEST=Enabled the config on Reef. Manually overrode the temperature
and voltage. Observed correct charge profile config is selected
for each tests.
Change-Id: I075d271258470b98d38e4d5395d749469d3fd469
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/407928
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>
In some cases, the virtual battery code creates
transactions that violate SB spec.
One example:
If the host command is structured as two messages -
a write to 0x03 (reg addr), followed by two bytes of write data,
the first byte of the second message (write data) will be sent to
virtual_battery_read(), as if it were a reg read request.
Let's do the following change for virtual battery:
1. Parse the command more carefully with state machines.
2. Support write caching for some critical registers.
3. Cache more attributes (0x03 and 0x0f).
BUG=chrome-os-partner:59239, chromium:659819
BRANCH=none
TEST='power_supply_info' works on kevin
Change-Id: Icdeb12b21f0dc3c329f29b206b7b9395ca4c9998
Reviewed-on: https://chromium-review.googlesource.com/407987
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
If battery is not present, input current is set to PD_MAX_CURRENT_MA.
If the input power set is greater than the maximum allowed system power,
system might get damaged. Hence, limit the input current to meet maximum
allowed input system power.
BUG=chrome-os-partner:58498
BRANCH=none
TEST=Manually tested on Reef. Removed the battery & using 'charger'
console command observed the following.
With Zinger charger at 20V - Input current is set to 2.25A
With Type-C & other chargers - Input current is set to 3A
Change-Id: Ife8686f322e095aa74b740a7c469bfe87107fb9a
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/397865
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>
On the bd9995*, back boosting may occur when actual battery voltage
drops below VBAT register setting. Maintain the VBAT register at the
battery-requested charge voltage even when not charging to ensure the
bd9995* doesn't become a back boosted animal.
BUG=chrome-os-partner:56139,chrome-os-partner:54248
BRANCH=gru
TEST=Manual on kevin, unplug AC, run 'charger', verify that 'V_batt' is
maintained at 8688 mV. Attach charger, verify 'V_batt' stays at 8688 mV
and device charges.
Change-Id: Ia0cc7f9279cb460e20a8faf332ad432067dc5482
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400087
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Daisuke Nojiri <dnojiri@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>
If charge_manager has not decided on a current limit, don't set a
minimum current limit, since we may brown-out in the no / low-battery
case.
BUG=chrome-os-partner:56139
BRANCH=None
TEST=Manual on kevin, attach cut-off battery, attach OEM charger, verify
system doesn't brown-out due to OC.
Change-Id: Id53eb32c4a8ac9c6d9a0d3f1d700f089a50fcb0f
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/386793
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Since pretty much always, we've declared console commands to take
a "longhelp" argument with detailed explanations of what the
command does. But since almost as long, we've never actually used
that argument for anything - we just silently throw it away in
the macro. There's only one command (usbchargemode) that even
thinks it defines that argument.
We're never going to use this, let's just get rid of it.
BUG=none
BRANCH=none
CQ-DEPEND=CL:*279060
CQ-DEPEND=CL:*279158
CQ-DEPEND=CL:*279037
TEST=make buildall; tested on Cr50 hardware
Everything builds. Since we never used this arg anyway, there had
better not be any difference in the result.
Change-Id: Id3f71a53d02e3dc625cfcc12aa71ecb50e35eb9f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374163
Reviewed-by: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BD99955 charger auto exits from the battery learn mode if the charge
is inhibited. Hence, do not inhibit the charger in battery learn mode.
BUG=chrome-os-partner:55491
BRANCH=none
TEST=Manually tested on Reef using 'ectool chargecontrol' command.
Able to enter/exit battery learn mode safely.
Change-Id: If05f9a9451842b77619e0a8c5db5e54fec24f399
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/362123
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
There's a new OTP change for the BD99955 and therefore the following
changes needed to be made.
- Change VFASTCHG_SET1 to 8.704V before CHG_EN is set to 1.
- Change VSYS_REG to 6.144V when starting Fast Charging.
- Change VSYS_REG back to 8.906V when Fast Charge is finished.
- Wait for 50ms to set CHG_EN to off (0) after Fast Charging has ended.
BUG=chrome-os-partner:55220
BUG=chrome-os-partner:55238
BRANCH=None
TEST=Flash kevin, plug discharged battery in. Plug AC in. `bd99955 r
0x11 1' and verify that VSYSREG is set to 0x1800 (6144mV).
TEST=`bd99955 r 0x1a 1' and verify that VFASTCHARGE is set to
0x2200 (8704mV).
TEST=Remove battery. `bd99955 r 0x11 1' and verify that VSYSREG is set
to 0x2300 (8960 mV).
TEST=Plug in battery and let charge to full. Verify that VSYSREG is set
to 0x2300 (8960 mV).
Change-Id: I5e5ca2cdcd4ead383416901c904df1e6fe5a9e28
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/360421
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
In case of boot after battery is cut-off without this
change the battery is assumed to be present even though it
is not initialized and ready to provide power in try source
enable function. With this assumption charger is disconnected
momentarily which causes reboot.
Also make sure that try source enable is updated after battery
is ready by notifying hook call HOOK_BATTERY_SOC_CHANGE.
BUG=chrome-os-partner:51753
BRANCH=firmware-glados-7820.B
TEST=Enter battery cutoff command from EC console to enter into ship
mode and plug-in AC, verified no reboots happen.
Change-Id: I6f7656125717f85851f5ad4e37dfd953a52799c6
Signed-off-by: Divya Sasidharan <divya.s.sasidharan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/335913
Reviewed-by: Shawn N <shawnn@chromium.org>
(cherry picked from commit 10040ac6284efe88b74193bdbb0c05ec92b563b4)
Reviewed-on: https://chromium-review.googlesource.com/336697
Commit-Ready: Divya S Sasidharan <divya.s.sasidharan@intel.com>
Tested-by: Divya Jyothi <divya.jyothi@intel.com>
BUG=none
BRANCH=none
TEST=on system which has different static battery info based on
battery present, when the present status has changed, verify the
battery info is also changed.
Change-Id: Id58c545e3315dc63c6dd6b59141b6302d767bfb7
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/331655
Reviewed-by: Li1 Feng <li1.feng@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
In case of no battery condition, current code sets the charger input
current to the charger maximum input current. To avoid damage to the
board, set the charger input current to the maximum current that the
board can support.
BUG=none
BRANCH=none
TEST=Manually tested on kunimitsu, removed the battery & then using EC
console command 'charger', verified that the current value is set
to 3000mA.
Change-Id: I94c40228a6362822c841a6e0c226bea0d3398b73
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/325522
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Li1 Feng <li1.feng@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Battery in cut-off mode wakes when voltage is applied to the PACK
and takes approximately 2 to 3 seconds to initialize before capable
of providing the power. Hence made the battery present status to
BP_NO in case of cut-off mode. Once the battery is ready new status
is updated as BP_YES.
When the battery status changes from BP_NO to BP_YES, charger input
current is set to board specific charger input current which is not
sufficient to boot the AP hence the system reboots. To avoid this
issue, added code to write charger manager negotiated current to
charger input current when the battery status changes from BP_NO to
BP_YES.
BRANCH=none
BUG=chrome-os-partner:49224
TEST=Manually tested on Kunimitsu.
Used console command 'cutoff' to put the battery in cut-off mode.
Inserted the adopter to wake the system, system doesn't reboot &
the battery charges.
Change-Id: Ia5a1457506b4bef0b3dd27993e4b60ae64c8f746
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/322430
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
x86 systems will auto-power-on when power is applied to the EC. When
the battery level is critically low, power-on is prevented, except when
the system is unlocked. So, when unlocked, some systems will
auto-power-on regardless of battery level, overcurrent the charger /
battery, and then repeat forever.
Prevent this reboot loop by ignoring auto-power-up when the battery is
critically low, regardless of system unlocked status.
BUG=chrome-os-partner:48339
TEST=Verify power-up is prevented on no-battery chell w/ donette. Then,
run 'powerbtn' on EC console and verify system powers on (and
overcurrents).
BRANCH=None
Change-Id: Ia631b5a8c45b42ec805e4a0c3f827929a0efd236
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/319187
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
