The Samus battery can be placed into a disconnect state by asserting a
disconnect input signal. In this state, the battery will not function
until a charging current is applied. This patch adds detection of the
disconnect state. If a battery in disconnect state is found, a current
is force-applied to the battery to kick it out of disconnect.
BRANCH=None
TEST=Manual on Samus.
1. Put battery into disconnect state
2. Pull AC, then reattach AC
3. Verify "found battery in disconnect state" is seen on the
EC console.
4. Pull AC and verify that EC console is still accessable
Also verify that battery gets out of reset state:
1. Pull AC
2. Issue "i2cxfer w16 0 0x16 0x0 0x12" command on EC console
3. Re-attach AC
4. Pull AC and verify that EC console is still accessable
BUG=chrome-os-partner:29465
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ib4268887fb483094ac4e641749200268160d3014
Reviewed-on: https://chromium-review.googlesource.com/209013
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
If at-shutdown is specified, the battery is cut off
1 seconds after the host has shutdown.
BUG=chrome-os-partner:29292,chrome-os-partner:28887
BRANCH=tot,nyan
TEST=Run batterycutoff ectool command and cutoff console
command with and without 'at-shutdown' option. Verify
the battery is cut off immediately without the option
specified and 1 seconds after shutdown with. View the
console log to see the deferred cutoff occur.
The following tests are verified on big.
console:
cutoff, AC on: system is off after removing AC.
cutoff, AC off: system is off immediately.
at-shutdown, AC on: system is off after "power off" and removing AC.
at-shutdown, AC off: system is off after "power off".
ectool:
batterycutoff, AC on: system is off after removing AC.
batterycutoff, AC off: system is off immediately.
at-shutdown, AC on: battery is cut off after 1s of shutdown.
system is off right after removing AC power.
at-shutdown, AC off: system is off after 1s of shutdown.
[84.058416 power state 3 = S0, in 0x0000]
[84.058803 power lost input; wanted 0x0001, got 0x0000]
[84.059120 power off 3]
[84.072148 Cutting off battery in 1 second(s)]
[84.123896 power shutdown complete]
[84.128790 power state 7 = S0->S3, in 0x0002]
[84.139694 power state 2 = S3, in 0x0002]
[84.150857 power state 8 = S3->S5, in 0x0002]
[84.166975 power state 1 = S5, in 0x0002]
[84.177972 power state 1 = S5, in 0x0002]
[85.080012 Battery cut off succeeded.]
Change-Id: Id4bacf79ad3add885260655f80cb8127bafe1ad6
Signed-off-by: Dave Parker <dparker@google.com>
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203694
Reviewed-by: Vic Yang <victoryang@chromium.org>
This is useful for testing battery charge profiles. When enabled, a dump of
all battery, charger, and charge state information will be printed whenever
the battery charge percentage changes.
BUG=none
BRANCH=ToT
TEST=make buildall -j
On the EC console:
chg debug on
then watch the console while either charging or discharging the battery.
Disable with
chg debug off
Change-Id: I6725c461461f90fcd812873f97490e980ab47bc6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199816
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Some battery uses clock stretching feature, and this could disturb
PMU communication before battery going stable.
AP does not know and will attempt PMU setting, and could get fail
For various battery indicates usually 1s for stable
(even if it is much less in real world 200ms~700ms)
Let's checking 'battery is ready' when first pump-up power.
BRANCH=ToT
BUG=chrome-os-partner:28289
TEST=Going battery shipmode and plug-in AC, See booting and EC log
Disconnect battery, and plug-in and see booting and EC log
Change-Id: Idd8ae2ab4ec164b11fe67413bbf647cad18bc481
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/197990
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Also adds 'battparam' console command.
BUG=chrome-os-partner:25145
BRANCH=ToT
TEST=Run 'ectool batteryparam set 0 0x1234'
'ectool batteryparam get 0'
and on the console:
'battparam 0'
'battparam 0 0x1234'
on a board that implements parameter 0.
Change-Id: I9cc54d001631f53dd39ae64cfdeececaa1747181
Original-Change-Id: Ib2812f57f2484309d613b23dab12ad43e0417bd2
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195824
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197162
Add a shortcut in smart battery driver and i2c passthru. Once
the battery cut-off order is submitted (in the factory line),
the EC will no longer talk to battery.
BUG=chrome-os-partner:28248
BRANCH=tot,nyan
TEST=See below
> remove AC, cutoff: expect system is off.
> cutoff, then remove AC: expect system is off.
> cutoff, wait for 1 min, then remove AC: expect system is off.
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Change-Id: Ied963c19d17d581ce99e4543469cf2fa165f0439
Reviewed-on: https://chromium-review.googlesource.com/196657
Tested-by: Yung-chieh Lo <yjlou@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Yung-chieh Lo <yjlou@chromium.org>
So that host and EC commands will be defined in common/battery.c.
The board-specific battery.c can focus on the proprietary method.
BUG=chrome-os-partner:28248
BRANCH=tot,nyan
TEST=make buildall runtest
Tested "cutoff" in EC console on big.
Change-Id: I213c0d601d0241c8dea309d6ac60c72452d2d100
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196621
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This adds two battery parameters that need to be monitored constantly:
remaining_capacity and full_capacity (that one only changes occasionally,
but we have to notify the AP when it does).
It also adds the is_present field to indicate whether the battery is
physically present or not (when we can tell), so we know whether to try to
wake up a deep-discharged battery.
Along with that, we clean up the error flags to provide indication of which
fields were unable to be read, and replace the manual logical-or of all
errors as they were set with a bitmask (BATT_FLAG_BAD_ANY).
No functionality is changed, only new & better information is provided for
use in the upcoming cleanup of the charge state machine.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=make buildall -j
All targets build; all tests pass.
Change-Id: I4312c2fdd3cf2dd9570718e90571eff796b269db
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191917
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In most cases we can't actually know whether a battery is present until
we've been able to talk to it. This adds that NOT_SURE case.
BUG=none
BRANCH=ToT
TEST=none
Nothing uses this case yet, and the only time that battery_is_present() is
called is when we have hardware to detect the battery (which always returns
YES or NO). This is just preparation for charge_state_v2, which will need
the NOT_SURE case for trickle charging.
Change-Id: Ic5793de080529d50c98860450a021a1abae168db
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191782
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This allows boards to detect the battery and return the correct temp
ranges, which will be needed for upcoming boards.
In the board-specific implementations, it's pretty much just moving
the fields from one const struct to another, so the impact is minor.
BUG=chrome-os-partner:24310
BRANCH=none
TEST=build all platforms; verify pit and rambi still charge
Change-Id: I7be075b3abb4039577f6362316adc1860c121d5c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178424
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
Smart batteries can report capacity in mAh or 10mW units. We forced
the units to mAh in charge_state.c's main loop, but that doesn't
guarantee that they're actually set before the capacity is read. It's
cleaner to check the capacity reporting mode when actually reading the
capacity.
BUG=chrome-os-partner:20881
BRANCH=none
TEST=battery command reports the same capacity data before/after change
(on rambi, design=2940 mAh)
Change-Id: I4a4c80eaade72bb09627d5d65693c097e264a992
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176154
The charge state machine asks for all of this stuff at the same time
anyway. Bundling it into a single function removes a number of
redundant (and painfully slow) I2C reads.
Also refactor the battery debug command so it doesn't have so many
local variables all in one function; it was consuming considerably
more stack space than any other debug command.
Spring still needs low-level access to the smart battery, so move the
two functions it needs directly into the Spring implementation.
BUG=chrome-os-partner:20881
BRANCH=none
TEST=charge/discharge rambi, pit and spring; watch debug messages and
LED and output of 'battery' debug command. All should behave the
same as before. Then run 'taskinfo' and see that the console task
has at least 20 bytes unused.
Change-Id: I951b569542e28bbbb58853d62b57b0aaaf183e3f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177797
The smart battery status register holds some useful info. This displays it
along with all the other stuff.
This decodes the alarm and status bits, but not the error code, since that
field is only valid immediately after a failed i2c transaction (that's how
the battery indicates error). Since we do all sorts of automatic battery
probing in other threads, that value will never be reliable when we run the
"battery" console command.
BUG=none
BRANCH=none
TEST=manual
Run "battery". You should see a new line amongst the output:
Status: 0x00c0 DCHG INIT
Change-Id: I5e684198af2cf7767f89786c91a7d946ad95d4c2
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175659
battery.h is the high-level interface. battery_smart.h is the
low-level interface. Most things don't need the low-level interface,
but were including smart_battery.h solely to get at battery.h. Fixed
this. Also merged battery_pack.h into battery.h, since it was odd to
split that data across multiple header files. Tidied the function
comments in battery.h as well.
No functional changes, just renaming files and adding comments.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I5ef372f0a5f8f5f36e09a3a1ce24008685c1fd0d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171967
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Currently only x86 platform uses charge_state.c, and it's been tailored
to fit smart battery and bq247xx charger family.
For Kirby, we have different types of battery and charger, and thus need
to make some change to accommodate them. This includes:
- Abstract out smart battery specific bit mask
- Implement missing functions required by GAIA chipset module
- Add config flags for charging-enabled GPIO pin
- Allow battery that doesn't report desired voltage and current
BUG=chrome-os-partner:22055
TEST=Build all boards
TEST=Boot Link and check it charges/discharges battery
TEST=Test charging/discharging on Kirby along with the next two CLs
BRANCH=None
Change-Id: I910c030a45b4f775afffec0127cdc31e89b9dd55
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168005
BQ27541 is not a smart battery IC, and thus we cannot use existing smart
battery driver. Let's add a driver that implements a smart-battery-like
interface.
The 'battery' console command is also moved to battery.c so that it can
be reused by different battery driver.
BUG=chrome-os-partner:22048
TEST=Type 'battery' and check the reported values are sane.
TEST=Check 'battery' command works fine on Spring.
BRANCH=None
Change-Id: I5d1eaeb3f801478f3b9473fd43c1f2a2eda75859
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/66340
We implemented a fancy state machine for link to try and feed
almost-dead batteries smaller amounts of current than the charger
could normally supply, by dithering down the voltage to less than was
requested. It's a lot simpler just to give the battery the smallest
non-zero amount of current we can give it at the voltage it asks for.
Remove the precharge code, since we won't use it on any future
platform and link has already branched.
BUG=chrome-os-partner:20881
BRANCH=none
TEST=find a really dead batery and try to charge it, or do what I did
and just hack the battery module to lie about the requested values,
and see that it always gets the minimum current step at the requested
voltage.
Change-Id: I30bcb62bbe215abafb3a98c52e2afed3b74ead1a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61789
This preserves more battery for the real-time clock. It also gets rid
of one battery level/state, since the EC will now shut down at the
same level (2%) as the AP.
Having the EC hibernate at the same level as the AP shuts down also
prevents the following weird scenario:
- EC powers on at 2% battery.
- EC won't power on the AP to do software sync because battery is low.
- But the charge state machine won't actually hibernate the EC until 1%.
- Between 2% and 1%, AC is inserted and system starts charging.
- But EC-RO is what's doing the charging; we should go through software sync
before charging.
BUG=chrome-os-partner:17124
BRANCH=link
TEST=manual
On battery power,
1) With system on, battfake 2 -> system shuts down and EC hibernates
2) With system off, battfake 2 -> EC hibernates
Change-Id: I87d17f70d60673f3e3f1c6eb88f3f00a8c9ed4e7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44314
In preparation for cleaning up low-battery logic. Make clear what
comparison operator is used for each constant (<=, <, >=, >).
Also remove hard-coded and unused display of design warning/low
battery levels from ectool. Verified via code search that these are
not used anywhere. Even if we later care about these levels, they
should be battery-specific and not hard-coded as a
platform-independent percentage of full capacity when ectool is
compiled.
BUG=chrome-os-partner:17124
BRANCH=link
TEST=compile link; 'ectool battery' from root shell prints valid info
Change-Id: I3650e27a08f4cc77067beb0685ee1488cc56d02f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43119
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
We already shut down the main processor below 3%. Hibernating the EC
below 2% will further cut power draw and minimize the risk of
deep-discharging the battery.
BUG=chrome-os-partner:14839
BRANCH=link
TEST=manual
1) discharge battery below 3%; system should shut down. when powered
on again it should shut back down within ~10 sec.
2) discharge battery below 2%; when system shuts down it should also hibernate.
(I've also tested this with a hacked smart_battery.c which lies about
the battery state of charge, since that's faster than waiting for my
battery to discharge.)
Change-Id: I504ba927012430db5cf10b895a36e6cd6fdf4c8b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34793
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tell the host the battery is no longer charging when it hits 97%, and
set the power adapter LED to green.
This solves several problems:
1) The last 3% of charge takes a looong time. Kernel/ACPI/UI already
have a hack to show the battery as charged when it's about 3% from
full, but the EC still showed a yellow LED.
2) If the system is charged and you briefly unplug the adapter, the
LED turned yellow for a long time as it slowly trickle-charged. Now
it goes right to green.
3) A fully-charged battery will drop below 100% charge as it settles,
but won't accept more current at that time. This caused the LED to
turn yellow and stay there until the battery finally settled down to
~96%, at which point it'd accept more current and top itself off. The
whole time it did this, the kernel/ACPI/UI hack from (1) would keep
reporting "battery full". Now the LED stays green too.
BUG=chrome-os-partner:11248
BRANCH=link
TEST=manual
- Discharge system to <95% full.
- Plug adapter in. LED should come on yellow.
- At around 97% full, the LED should turn green.
- Around that the UI will display "battery full".
(Note that due to rounding, the UI may take a few minutes to display
"battery full" after the LED goes green; that's ok)
- Unplug and replug adapter. LED should come on green. UI still reports
"battery full".
Change-Id: Ie56fbf3a05239e73d2c765bb98d36aa5cfedc2ef
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34452
Yet another set of tweaks to the lightbar patterns:
At Startup or wake from sleep, Google colors cycle in.
While running, > 25% power level in the battery:
All blue, in a breathing effect (cycle up and down 30%).
While running, <= 25% power level in battery:
Same as above, but with red
Shutting down, or going into sleep:
Cycle out the Google colors (Note: the effect is only visible for S0->S3,
because shutting down kills power to the lightbar before we can react).
While sleeping:
Similar to now, but only using Blue and red for battery indication as above.
The EC doesn't have access to the ALS, so we use the keyboard backlight to
control the lightbar brightness instead:
If keyboard backlight is OFF (which it is when ambient is bright), use max
brightness for lightbar.
If keyboard backlight is ON, use keyboard backlight brightness.
BUG=chrome-os-partner:13870
BRANCH=Link
TEST=none
This is an aesthetic change. Nothing to test, only artisitic criticism.
Change-Id: Ib0b98eef18984945a83e988588c225025c4e8e52
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33824
Reviewed-by: Randall Spangler <rspangler@chromium.org>
At other times, the battery should follow the normal charging rules.
Using the trickle charging logic has 2 problems here:
1) Battery voltage is near maximum, so trickle charging logic starts
out with voltage less than the actual battery voltage, and less than
the charging spec.
2) Trickle charging only exits when battery requests more current
(which it won't if it's near full) or on 4-hour timeout, not when
battery reads 100%. So this can cause overcharging.
Note that we still limit the charging current to what the battery asks
for, but if that's less than the minimum current from the charger we
simply provide the minimum and don't fiddle with the voltage since
that may interfere with the battery's ability to determine it's fully
charged.
BUG=chrome-os-partner:14402
BRANCH=link
TEST=manual
1. charge laptop to full
2. quickly unplug and plug charger
3. look at debug log; should either not charge at all (if charge is currently
100%) or charge at 8400mV (if charge is less than 100%).
Change-Id: Ifd5a9eb2e9bb791f74196713b645d1c9211eb736
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33729
Reviewed-by: Rong Chang <rongchang@chromium.org>
I keep getting asked to build an EC image to manually control the lightbar
patterns so that the Powers That Be can look at it. This change just makes
it possible to turn that mode on and off for yourself. You'll need a root
shell or the EC console to do it, though.
BUG=chrome-os-partner:8039
BRANCH=link
TEST=manual
From the EC console, type
lightbar demo 1
OR from the root shell run
ectool lightbar demo 1
After that, these keys should change the lightbar appearance (transitions
may be slow and subtle - that's intended):
UP = battery is more fully charged
DOWN = battery is less fully charged
RIGHT = battery is charging
LEFT = battery is discharging
BRIGHT = increase lightbar brightness
DIM = decrase lightbar brightness
Note that this does not interfere with the normal function of any keys. It
only adds some additional EC behavior.
Change-Id: Ia1a9855188244d74b670f9dbfdf60e3ac0343460
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30899
BUG=chrome-os-partner:8039
TEST=manual
Boot the system, look at the lightbar. It should pulse colors slowly on
battery, faster on AC.
Change-Id: I0184973d11eda51db87d652aa2c92995f5a25588
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27810
Adding trickle charging mode to precharge batteries with
voltage lower than minimal design value. This CL adds
control to charger voltage to track battery input current
change.
To prevent battery from deeply discharging, this CL preserves
3% of the design capacity.
Minor bug fixes include error state check and charger control
logic.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BUG=chrome-os-partner:8660,8661
TEST=manual
Plug AC power, the power adapter led should be
'yellow'. On the EC serial console, type 'battery'
and 'charger' commands.
Battery input current should staid close to its
desired current.
A deeply discharged battery (5.5V) should be revived to
a healthy state after 30 minutes ~ 4 hours.
Change-Id: Ibaa2396c6b751639d98db32f5919b1e8ec700e40
This CL adds battery SMI events. And refactors the charging state
machine by adding share state context for all handlers.
Power events are moved to common handler. Minor clean up on console
output messages.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BUG=chrome-os-partner:7526,7937,8450
TEST=manual:
Watch console message when connecting/disconnecting AC adapter and
battery. Check the state transition.
Change-Id: I42eec4f87a9d49bd193cb9dde9080e3dfccbb77c
This CL adds LPC commands to provide the following information:
- Design Capacity (dword)
- Last Full Charge Capacity (dword)
- Design Voltage (dword)
- Design Capacity of Warning (dword)
- Design Capacity of Low (dword)
- Battery Type (ascii)
- Model Number (ascii)
- Serial Number (ascii)
- OEM (usually Vendor) (ascii)
- Battery charge cycle count (dword)
Signed-off-by: Rong Chang <rongchang@chromium.org>
BUG=chrome-os-partner:8181
TEST=none
CQ-DEPEND:Iad4d63c996272568b5a661a6716790ef151b29c5
Change-Id: Iabaf7d9862e15c5b21cf5170cf43450e472b7836
