This patch makes EC enable PD communication if it's running in
manual recovery mode. This is required to show recovery screen
on a type-c monitor.
This patch also makes EC-EFS ignore power availability. It will
make EC verify & jump to RW even if power is sourced by a barrel
jack adapter. This should allow depthcharge to show screens
(e.g. broken, warning) on a type-c monitor.
BUG=b:72387533
BRANCH=none
TEST=On Fizz with type-c monitor, verify
- Recovery screen is displayed in manual recovery mode.
- Critical update screen is displayed in normal mode.
- Warning screen is displayed in developer mode.
Monitors tested: Dingdong, Dell S2718D
Change-Id: Ib53e02d1e5c0f5b2d96d9a02fd33022f92e52b04
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/898346
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
In particular, this will allow touchpad driver and keyboard matrix
scanning to be powered off/disabled when the USB interface is
disabled without setting the remote wake feature
(USB_REQ_FEATURE_DEVICE_REMOTE_WAKEUP), as events would be
ignored anyway.
BRANCH=none
BUG=b:72683995
TEST=With next CLs, touchpad and keyboard matrix scanning are disabled
when lid is closed.
Change-Id: I3750bfaf8c31cde075adf9da4fef39753b8981c5
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/897067
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This patch makes EC_CMD_SET_CROS_BOARD_INFO return
EC_RES_ACCESS_DENIED if the command fails due to write-protect
switch.
BUG=b:70294260
BRANCH=none
TEST=Verify 'ectool cbi set 2 4' prints 'WP enabled?' when WP
is enabled.
Change-Id: I7c27ee748caf32e57f22ab79edcbff96e42c44ad
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/897683
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Automated code scanner highlighted a few problems in the recent ode
additions. This patch fixes the problems.
BRANCH=cr50
BUG=none
TEST=none
Change-Id: I1f199eb5d2af992384ab04f3010b4b646464a70f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/897993
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Prevents a null pointer dereference when the AP asks the EC
for nonexistent settings of a sensor.
BUG=chromium:761758
TEST="ectool motionsense offset ${ID of baro_bmp280 sensor}"
And see no null pointer dereference, but an invalid command error
BRANCH=master
Change-Id: I3050feaa3c9752abebc30237dac1befa4e5775cc
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/850639
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
If the sn5s330 PPC is being used to detect VBUS presence
(CONFIG_USB_PD_VBUS_DETECT_PPC), then enable interrupts and call
usb_charger_vbus_change when VBUS_GOOD changes.
BUG=b:72007153,b:72007492
BRANCH=none
TEST=Connect 3A and 1A USB-A chargers to each of Grunt's USB-C ports,
check that BC1.2 detection is working:
With 1A:
> chgsup
port=0/1, type=7, cur=500mA, vtg=5000mV, lsm=1
With 3A:
> chgsup
port=0/1, type=7, cur=2400mA, vtg=5000mV, lsm=1
TEST=Boot Grunt to OS, then connect USB2 mouse or USB3 flash drive to each
of Grunt's USB-C ports. Devices do not work due to b:71772180, but gpioget
shows EC is setting USB_C0/1_BC12_VBUS_ON_L correctly.
Change-Id: Iffc352105a321997adb364b9fbb8bafef248c224
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/887938
Reviewed-by: Jett Rink <jettrink@chromium.org>
Boards with a PPC will use the PPC to discharge the VBUS line instead
of the TCPC or GPIO discharge path.
BRANCH=none
BUG=b:72179253
TEST=Fall time after device removal on grunt within spec now
Change-Id: I822923a1cedb32a20efc3610cce4437ade3387f0
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/886563
Reviewed-by: Edward Hill <ecgh@chromium.org>
It's no longer necessary to call board_tcpc_init() from PD tasks, since
HOOK_INIT completion is guaranteed before the task starts. Also, calling
board_tcpc_init() for each PD task without a port arg is a bad idea.
BUG=b:72229154
BRANCH=none
TEST=`make buildall -j`
Change-Id: I6fba07771693b8343568041960a263e02775a8fc
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/881538
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Edward Hill <ecgh@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>
Allow to have CONFIG_MALLOC defined for one partition and not the other.
The typical use-case is asymetric firmware whose small RO is typically
just an updater/verifier (and RW signature verification currently
doesn't like malloc as the memory initialization is done too late).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:72360575
TEST=make buildall
Change-Id: I67cc04cd11385d4c05556ea41ef674cb7a232e65
Reviewed-on: https://chromium-review.googlesource.com/885820
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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>
Some chargers don't respect the SRC.Open state within the 20ms allotted by
the usb spec. The LiteOn Charger seems to notice after ~120ms bumping to
200ms so we cutoff Vbus for even ill-behaved chargers. We expect to brown
out in the sleep.
BRANCH=none
TEST=LiteOn charge will disconnect now
BUG=b:72510370
Change-Id: Ief0e999ed52f39420eed5f07432273e741a14c7e
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/886833
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
We don't want the PPC to connect the CC lines from the
TCPC to the USB connector until the TCPC resistors are
set in a valid state (SINK initially).
If we connect the CC lines (happens in the ppc_init) before
setting the resistor values, some TCPC will be toggling the
CC line between Rp/Rd since it doesn't detect a cable yet.
In the dead battery charging case, connecting the toggling
CC lines to the charger can rail the CC lines to 3.3 V signaling
to the charger to disconnect Vbus, thus browning out the board.
BRANCH=none
BUG=b:71865251
TEST=Grunt powers on via usbc p0 with and without USB hub.
Change-Id: I8e78aa2af42075398fab89a2dccef5e7df27b260
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/882305
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Edward Hill <ecgh@chromium.org>
Update the FP MCU interface to include a few convenient diagnostics
functions for factory testing.
It's mostly backward compatible, but overall this interface never
shipped in anything, so not a big deal regardless.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:71986991
TEST=ectool --name=cros_fp fpinfo && ectool --name=cros_fp fpcheckpixels
CQ-DEPEND=CL:*546799
Change-Id: Ic641f891ace02d79af9339cf6cb59a2960e506a7
Reviewed-on: https://chromium-review.googlesource.com/873924
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Host command handler prints every single host command except when
commands are repeated back-to-back. This patch allows each board
decide which commands should be ignored. When debug printf is
suppressed, a global counter is incremented. Developers know there
were commands processed but not reported to the console.
BUG=chromium:803955
BRANCH=none
TEST=Observe 0x97 and 0x98 were not printed. Global suppress
counter is incremented.
Change-Id: I05e8cde9039f602e8fc06c20e89b328e797bd733
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/876952
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch adds CBI_GET_RELOAD flag to EC_CMD_GET_CROS_BOARD_INFO
command. When the flag is set, the command will be forced to read
data from EEPROM even, ignoring the data cached by the previous
read.
This allows ectool to verify a write was successful without reboot.
BUG=b:70294260
BRANCH=none
TEST=ectool cbi set 0 0x1234 && ectool cbi get 0 1
Change-Id: I3e7ced5be56a74c605870a4c0622c0a2f47963bb
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/874155
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch makes read_board_info retry to read CBI on error. The
successive calls will be immediately returned with the cached result.
This will avoid attempting reads doomed to fail.
BUG=b:70294260
BRANCH=none
TEST=ectool cbi get 0
Change-Id: Iacd9cc38bab814af9188c4557c2ee751c421e3a3
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/872259
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>
This patch adds host command to write board information in EERPOM.
BUG=b:70294260
BRANCH=none
TEST=Run ectool cbi set <type> <value> to write BOARD_VERSION, OEM_ID,
and SKU_ID. Enable WP and verify cbi set command fails.
Change-Id: I39536d146313408ace666f350a107d89b331bf7a
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/865570
This patch adds host command to get board info from EEPROM.
BUG=b:70294260
BRANCH=none
TEST=Run ectool cbi get <type> to get board version, OEM, SKU
Change-Id: I41a84d3eea6da9d88fa8122db36dcd1df515842d
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/865161
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch adds Cros Board Info APIs. It reads board info from EEPROM.
This patch sets CONFIG_CBI for Fizz to make it use CBI.
BUG=b:70294260
BRANCH=none
TEST=Read data from EEPROM.
Change-Id: I7eb4323188817d46b0450f1d65ac34d1b7e4e220
Reviewed-on: https://chromium-review.googlesource.com/707741
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@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>
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>
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>
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>
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>
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>
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>
If a bios carries an EC image signed by a wrong key, EFS EC falls back
to the previous slot upon reboot. Vboot currently does not handle this
case and tries to update the EC with an incompatible image again.
When this happens, a user sees 'applying critical update' screen
repeatedly.
This patch adds EFS_VERIFYV host command. Vboot on AP calls it to check
whether the EC likes a newly updated image or not. If the verification
fails, it's considered as update failure and vboot displays 'broken'
screen.
BUG=b:71719323
BRANCH=none
TEST=Flash EC SPI with an image which has a different RO key. Boot DUT
and let it run software sync. EC-RO rejects the updated image and falls
back to the previous one. The update counter is incremented and vboot
shows the 'broken' screen, requesting recovery.
Change-Id: I8a107a376963baa146ff691c50d80018ec3e429c
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/858159
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds functions required for the master in EC-EC communication,
requesting base battery static and dynamic information, and charger
control.
BRANCH=none
BUG=b:65526215
TEST=Flash lux and wand, EC-EC communication works.
Change-Id: I7a46ee3f5848d22c2c9bea7870cbd7e74141cf3d
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/839201
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>
Modify chipset_in_state to always say that the chipset is off,
when we do not actually have a chipset (like on hammer): that
makes sure the battery can actually be cut off (else the EC
would just wait forever for the chipset to turn off).
Also, wake the charger state on "AC" change, that is, when
charging_allowed changes state, to make sure the charging loop
is executed after lux tries to charge it (else the charging loop
would wait until timeout expires, and wand would ask the battery
to be cut off again).
BRANCH=none
BUG=b:65697962
TEST=Deplete wand battery, reboot without providing external power
to it.
After 30 seconds, battery is cut off:
[1.354683 Low battery: 2%, 6866mV]
[1.354888 charge warn shutdown due to critical battery]
[31.381410 Low battery: 2%, 6865mV]
[31.381643 charge force battery cut-off due to critical level]
TEST=Upon providing power to wand, charging loop is executed
regularly, and battery is charging.
Change-Id: I7154b25bd852b8422a0ae3b506675a297a948132
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/842742
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>
