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>
Call ppc_set_vbus_source_current_limit to enable 3A output.
BUG=b:69378796
BRANCH=none
TEST=connect PD sink and see 5V 3A on both ports
Change-Id: Ia38ebcb3b1b3d1148a00b3050fcda2bd2cf73af5
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/866158
Reviewed-by: Justin TerAvest <teravest@chromium.org>
charge_manager_refresh() asserts that
board_set_active_charge_port(CHARGE_PORT_NONE) returns EC_SUCCESS,
so if port 1 on Grunt's daughter board is disconnected, the EC
gets stuck in an assert crash loop. Just printing the error and
continuing seems like a better way to handle the missing port.
BUG=b:71955904
BRANCH=none
TEST=grunt with no daughter board doesn't assert
Change-Id: I8a0f79e45c7b564794498cfc41bcc4acd8fd231f
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/866214
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Enable ramping by default. Follow-up CL will have EC-EC master tell
the slave if it's necessary to ramp.
BRANCH=none
BUG=b:71840796
TEST=lux fully charged, in S0ix, wand connected. Connect old
BC1.2 charger, see that the charger is not browning out anymore.
Change-Id: I5f1052257db4c581bcb700c7f0306f14f792ea03
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/863349
Reviewed-by: Shawn N <shawnn@chromium.org>
This adds support for EC_CMD_BATTERY_GET_STATIC and
EC_CMD_BATTERY_GET_DYNAMIC host commands, that can currently only
fetch the base battery information using index = 1.
In the future, all battery information can be passed to AP using
these host commands (i.e. lid could provide its own battery
information on index = 0).
BRANCH=none
BUG=b:65697620
TEST=ectool battery shows lid battery information (no change)
TEST=ectool battery 1 shows base battery information
Change-Id: Ib819e4917b3acc337348764f6cc2aa7380bed700
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/863863
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Rainier has landscape orientation and last patch was 90 degrees off in
its base rotation value.
BUG=b:71753415
TEST=Flash ec on rainier and tilt device.
BRANCH=None
Signed-off-by: Ege Mihmanli <egemih@google.com>
Change-Id: I1d0837b2391ec4d0051c6c9af984d801264fe64c
Reviewed-on: https://chromium-review.googlesource.com/865803
Reviewed-by: Shawn N <shawnn@chromium.org>
This commit enables support for reviving a battery from disconnect while
also providing the code to detect if the batteries are disconnected or
not. The disconnection code behaves similarly to some other battery
packs used in Chromebooks.
BUG=b:71515229
BRANCH=None
TEST=Flash zoombini; cut off battery; apply AC and verify that we do not
leave safe mode until the battery is no longer "disconnected".
TEST=Repeat above test for meowth.
TEST=Cutoff the battery and apply AC and verify that board wakes up from
cutoff.
Change-Id: I52fe91bd6522901671ad5a302bfa0ca27e5f5aa0
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/864830
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
We need to enable I2C_PORT_ACCEL so that the driver supports I2C
transfers.
BUG=b:71877225
BRANCH=none
TEST=On EC console:
> accelinit 1
> accelread 1
With this CL we avoid an error
Change-Id: I9b7018ef9615992d91fbf8685832ff73c3cc1172
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/863206
Reviewed-by: Edward Hill <ecgh@chromium.org>
Set this up so we can measure the CPU temperature.
BUG=b:71868256
BRANCH=none
TEST=on EC:
> temps
Charger : 312 K = 39 C
SOC : 321 K = 48 C
CPU : 331 K = 58 C
CPU shows 58 C (which seems a lot cooler than it actually is)
Change-Id: Ia625e36b95a566aa436eff751c2ebf5863d984ad
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/862885
Reviewed-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Use the SPI1 controller as the host command slave interface.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:67081508
TEST=On reworked Meowth board with ZerbleBarn connected to the PCH SPI
bus, use to the kernel cros_ec interface to communicate with the MCU.
Change-Id: Ia7bdc72677cda2752a0849266282d2a779980152
Reviewed-on: https://chromium-review.googlesource.com/860933
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Update the host command support on the STM32 SPI slave for the STM32H7
silicon.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:67081508
TEST=with a servo v2 connected to ZerbleBarn,
send host commands v3 through the servo FTDI SPI interface.
Change-Id: I26ff4b6a3a45e446cd16e9da43c6932c24c37256
Reviewed-on: https://chromium-review.googlesource.com/839864
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The user needs to be able to unlock/open/lock CCD in addition to
setting the CCD password.
This patch adds command line options for these three CCD subcommands.
They all are communicated to the TPM using the same vendor command.
'open' and 'unlock' subcommands could require the user to enter the
password. This is indicated by the appropriate vendor command return
code.
If return code of 'open' or 'unlock' subcommand indicates the need for
physical presence, the utility starts polling the Cr50 prompting the
user to press the power button when the chip expects it.
Some input parameters sanity checks are added to make sure that the
user does not request mutually exclusive actions.
BRANCH=none
BUG=b:62537474
TEST=verified that CCD can be unlocked and opend with and without
password, with and without PP required.
Change-Id: Iea229a220e9f3d2f5d07cebdaebcb9b297939310
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/861209
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When user is trying to execute 'ccd open' or 'ccd unlock' and password
is set, the return error code does not allow to tell the reason for
the command failure.
Let's add a distinct return code to indicate this condition so that
the user can supply password.
BRANCH=cr50
BUG=b:62537474
TEST=verified along with the accompanying gsctool modifications.
Change-Id: I286f87ab12114cd7dd7ebcdf0e321f7a24723367
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/861208
Reviewed-by: Randall Spangler <rspangler@chromium.org>
With the upcoming addition of ability to manage CCD using gsctool, it
is necessary to send user password in several CC_CCD subcommands. This
patch modifies the password handler to allow the user to specify the
subcommand code to use.
VENDOR_RC_IN_PROGRESS is added to the list of acceptable return codes,
as this is what could be returned in response to 'ccd unlock' or 'ccd
open'.
BRANCH=none
BUG=b:62537474
TEST=verified that password still could be set and cleared from the
CLI and gsctool
Change-Id: Ic58f344a728897fb535cd9b7bedd47d28b30f5f8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/861207
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When TPM is wiped out on 'ccd open', the TPM reset could be invoked on
the TPM task context, if physical presence verification was not
required, or on the hooks task context, if PP was required.
This patch makes sure that the proper TPM reset is invoked depending
on the context. Also fixing the return value in ccd_command_wrapper(),
because it is expected to be from the ec_error_list enun, and this is
what is returned in the vendor command error response payload.
BRANCH=cr50
BUG=b:62537474
TEST=verified that TPM and device reset happen smoothly in both cases
when 'ccd open' requires and does not require PP.
Change-Id: I1935fc90b386bb8f2158001e153da371fca22d03
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/861206
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When implementing 'ccd open' and 'ccd unlock' through gsctool, we need
to be able to pass to the host the state of the physical presences
state machine regarding the expected user action (pressing the PP
button).
Two new VENDOR_CC_CCD subcommands are being added: CCDV_PP_POLL_OPEN
and CCDV_PP_UNLOCK. In response to these commands, the Cr50 always
returns VENDOR_RC_SUCCESS return code and a single byte payload
showing the CCD and PP state:
- CCDPP_CLOSED - PP process is not running, CCD closed. Maybe user
missed a button press deadline.
- CCDPP_AWAITING_PRESS (self explanatory)
- CCDPP_BETWEEN_PRESSES (self explanatory)
- CCDPP_PP_DONE - CCD is opened/unlocked (as per user request), PP
process succeeded.
BRANCH=cr50
BUG=b:62537474
TEST=with the upcoming change to gsctool verified that PP states are
properly conveyed to the user.
Change-Id: I97b1fef4440eea93c5c5ac01b7c60bfce9a4595c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/861001
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Depending on device configuration and compile time options, CCD
commands 'open' and 'unlock' could either be executed immediately, or
require the user to take the device through physical presence state
machine.
As these commands execute through TPM vendor commands, there needs to
be a different return value indicating that the command action is not
finished and PP process is in progress.
Let's add another vendor command return value, and do not consider it
a failure if vendor command returns this value in response to 'ccd
open' or 'ccd unlock'.
BRANCH=cr50
BUG=b:62537474
TEST=took an Eve through 'ccd open' sequence
Change-Id: Ie62ccfb4319a13b6fb6c1c854a0ea26beb9f517c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/860999
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch adds an API which exports current physical presence state
machine state to allow the caller to see if the state machine is in
one of the three distinct states:
- no PP process in progress
- user PP input is expected
- PP process in progress, user input is not currently expected
BRANCH=cr50
BUG=b:62537474
TEST=with the rest of the patches applied verified that PP state is
properly communicated through this API.
Change-Id: Ia10cd20c490dadef595f30e0b7257e51b6abf8fa
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/860998
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
In preparation to conveying the PP state to gsctool let's split the
'PP_DETECT_IN_PROGRESS' physical presence FSM state in two:
- PP_DETECT_AWAITING_PRESS, a state when user physical presence
indication is expected
- PP_DETECT_BETWEEN_PRESSES, a state when the previous indication was
accepted, but the next one is not yet required.
The code is modified to accept the disjunction of the twp new states
as the old PP_DETECT_IN_PROGRESS state.
BRANCH=cr50
BUG=b:62537474
TEST=successfully took Eve through 'ccd open'
Change-Id: I0d229f2f8beeec01ea2a9106b0cbc3f9801ff479
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/860997
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
We want to be able to tell between cases when a CCD command executed
on the TPM vendor command context was invoked through CLI or received
over /dev/tpm0.
Let's add a flag set for the duration of execution of the CLI command.
BRANCH=cr50
BUG=b:62537474
TEST=none, this is not used yet.
Change-Id: I309b4364285816a5f54522b00c93a4bf5025e2c4
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/860913
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Rainier has landscape orientation, therefore needs its accelerometer
base values adjusted.
BUG=b:71753415
TEST=Rotate rainier and make sure screen orientation is not off by 90
degrees.
BRANCH=None
Signed-off-by: Ege Mihmanli <egemih@google.com>
Change-Id: I60b49e717c691e34a39e817d2c064ea45b8d53d7
Reviewed-on: https://chromium-review.googlesource.com/862733
Reviewed-by: Shawn N <shawnn@chromium.org>
Using and extending the existing framework, move ccd commands
'password, lock, open, and unlock to the same processing path.
The first three commands accept a single parameter, password. It is
required for the password command and optional for unlock and open.
The lock command does not require any parameters.
Wiping the TPM, if necessary, now happens on the same context where
CCD command is executed, i.e. the TPM task context. This is why the
same context TPM reset function needs to be exported and used here.
ccd_open() and ccd_unlock() could be further refactored, this would
require a bit more effort to find appropriate balance between
commonalities and differences.
BRANCH=cr50
BUG=b:62537474
TEST=verified that ccd commands to open, unlock, lock and set and
clear password all work.
Change-Id: I2b9f2b550347b590a55bfaef262a4f050d3f4c1c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/854709
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Instead of defining these options in other header files, set them
here. This also prevents pre-submit checks from complaining
about these symbols being used without being defined in config.h.
BRANCH=none
BUG=b:65697962
TEST=make buildall -j, presubmit checks pass for CL that makes
use of CONFIG_EC_EC_COMM_BATTERY_MASTER.
Change-Id: I8098a8ae6422bf0ffb26523785d7c16a3ee1c6df
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/861365
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The ANX3429QN-AA-R I2C bus cannot operate above 400kHz without
first setting register 0x3 to 0x48. We can just lower the bus
to 400kHz without having to set any registers and everything
works as expected.
BUG=b:71810830
BRANCH=none
TEST=Booted grunt with new firmware and p0 TCPC communicates
with EC successfully
Change-Id: I98e3c1a4844e1a79d23f8478fdf97ada72ad1c7d
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/862543
Reviewed-by: Edward Hill <ecgh@chromium.org>
From comment, we should follow rule to use sensor index.
"the first 2 entries must be accelerometers, then gyroscope."
If not, screen rotation and clamshell/tablet mode switch in ui
will not work.
And I think we had better reorder "motion_sensors" structure
as well. Use tab indent instead of space.
BUG=b:71370092, b:71370114, b:69399214
BRANCH=none
TEST=check screeen rotation and tablet/clamshell mode.
Change-Id: I6b19411890c4e1abf9ceda45b47d18616c6e7b94
Signed-off-by: Jongpil Jung <jongpil19.jung@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/858878
Commit-Ready: Jongpil Jung <jongpil19.jung@samsung.corp-partner.google.com>
Tested-by: Jongpil Jung <jongpil19.jung@samsung.corp-partner.google.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
After a call to pthread_create(), it is indeterminate which thread the
caller or the new thread will next execute. Synchronize with the new
thread and allow it to initialize (and print to console, before the
print can potentially interfere with other prints) before proceeding.
BUG=chromium:715011
BRANCH=None
TEST=Run 'make runtests', verify 'Console input initialized' is seen
before '--- Emulator initialized after reboot ---':
====== Emulator output ======
No flash storage found. Initializing to 0xff.
No RAM data found. Initializing to 0x00.
Console input initialized
--- Emulator initialized after reboot ---
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ieb622e9b7eea2d11d4a11a98bb503a44534f676c
Reviewed-on: https://chromium-review.googlesource.com/854989
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Cr50 should not automatically touch the EC reset when enabling the
USB-EC SPI bridge. Otherwise, this could interefere with ECs that might
have internal SPI flash and need to have their resets deasserted in
order to access the internal SPI flash.
This commits simply removes the assertion of EC reset when enabling the
USB-EC SPI bridge. The user or external scripts should control the
resets as necessary using servo or the cr50 console.
BUG=b:71548795,b:71557464
BRANCH=None
TEST=Flash meowth cr50. Verify that I can flash the EC using a
servo_v4.
TEST=Repeat above test with a servo_micro.
TEST=Repeat above test with a SuzyQable.
Change-Id: I114c34df43cf1e8ba622e75c3e6ecf517afc40a4
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/850865
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Current revision of nautilus boards will lose VBAT on power cycle and
therefore cannot successfully save the reset flag state.
Implement workaround that will allow boards to continue to work for
FAFT testing by indicating to the skylake chipset power code that it
could skip the PMIC reset when doing 'reboot ap-off'.
BUG=b:67062902
BRANCH=None
TEST=None
Change-Id: I078f6d62b2161c1b3322da15aba02efaca2010ba
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/855737
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Enable deep sleep on rk3399 devices and start using SYS_RST_L to track
the AP state.
We can only release this once the EC has the proper support. It needs to
assert SYS_RST_L in S5.
If we have an old EC and this change in the Cr50 firmware, Cr50 won't be
able to tell when the AP is off. I think this will just cause an
interrupt storm on the AP UART and might not go into regular sleep in
S5.
If the EC change gets released before Cr50, Cr50 won't go to sleep in
S5, because SYS_RST_L is a wake on low pin. Cr50 will immediately wake
up from the SYS_RST_L pin when it enters sleep.
BUG=b:35647982
BRANCH=cr50
TEST=run firmware_Cr50DeepSleepStress on Bob
Change-Id: Iaf46f46eb5963e9479bba40457253a6ccc91ad32
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/699295
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We have a requirement that this signal is asserted whenever cr50 is in
deep sleep. It is deasserted on resume. This change configures sys_rst_l
as wake on high before deep sleep, so cr50 doesn't wake up
immediately after entering deep sleep. This is consistent with the
behavior of plt_rst_l when it's used to track the AP state and enable
deep sleep.
This doesn't change anything right now, because no devices that use
sys_rst_l have deep sleep enabled.
BUG=b:35647982
BRANCH=cr50
TEST=none
Change-Id: Ie5c3a6bbf4d0a52c1f96a9b29ebd037104a8abc4
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/815335
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Currently only 'ccd password' command is processed using TPM vendor
command. More CCD commands are going to be processed the same way.
This patch refactors the code to make it easier to add more
subcommands.
BRANCH=cr50
BUG=b:62537474
TEST=verified that 'ccd password' still works both from crosh and CLI.
Change-Id: Id55da51d6edc5652591ad30160a4102b3026a186
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/854708
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We want CCD commands lock, open, password, and unlock (at least to
start with) to be available over both CLI and through crosh (i.e.
coming over /dev/tpm0).
Let's allocate a TPM vendor command for handling all CCD subcommands,
and move to this new framework the 'ccd password' command, which
already is available over vendor command.
BRANCH=cr50
BUG=b:62537474
TEST=verified that 'ccd password' still works both over Suzy-Q CLI and
using gsctool on the target.
Change-Id: I2d06230b762f47af7e580b188a587bc5678ca169
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/853280
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add a tweak to get faster flashing:
skip writing the empty trailing space at the end of the firmware image.
On the STM32H7x3, flashing 2MB of useless bytes over UART can be
really slow...
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:67081508
TEST=flash_ec --board=meowth_fp
Change-Id: Ie396ee7d5b5771e0f6249e38da37ef8329c84ae3
Reviewed-on: https://chromium-review.googlesource.com/856978
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
On some chips, the full erase operation can take really long:
e.g 13s for 2MB mass-erase on the STM32H7x3 family.
Add a new mechanism retrying the ACK detection rather than extending
the default timeout which would imply very slow behavior in other cases
(e.g. connection).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:67081508
TEST=flash_ec --board=meowth_fp
Change-Id: I428f56341c31c327debb9a3d2eba9b12c768ba86
Reviewed-on: https://chromium-review.googlesource.com/856976
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Shawn N <shawnn@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>
