This adds functions required for the slave in EC-EC communication,
including the task that processes requests from the master.
This also adds required CONFIG_EC_EC_COMM_SLAVE/MASTER/BATTERY
config options.
BRANCH=none
BUG=b:65697962
TEST=Build wand and lux boards, flash it, EC-EC communication works.
Change-Id: I772d9023a830f4fbc37316ca31e4da8240de7324
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/828180
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This adds 3 commands to obtain static and dynamic battery
information, as well as control base charger state.
These host commands are meant to be used as part of the EC-EC
communication protocol (based on hostcmd v4 protocol), but could
be used in the future to pass information between AP and EC,
especially when more than 1 battery is present, which would be
hard to support with the current MEMMAP-based approach.
BRANCH=none
BUG=b:65697962
BUG=b:65697620
TEST=Build wand and lux boards, flash it, EC-EC communication works.
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Change-Id: I263454794394838918832c9e4623835ab2f3a3da
Reviewed-on: https://chromium-review.googlesource.com/670380
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The CONFIG_BUTTON_RECOVERY option was a little confusing especially when
we have the CONFIG_DEDICATED_RECOVERY_BUTTON option. This commit
renames CONFIG_BUTTON_RECOVERY to CONFIG_BUTTON_TRIGGERED_RECOVERY to
help make things a little clearer.
Additionally, to avoid copy paste, defining
CONFIG_BUTTON_TRIGGERED_RECOVERY will populate the recovery_buttons
table with either the volume buttons or a dedicated recovery button
depending what the board is configured for.
Lastly, if CONFIG_DEDICATED_RECOVERY_BUTTON is defined,
CONFIG_BUTTON_TRIGGERED_RECOVERY is defined as well since it's implicit.
BUG=chromium:783371
BRANCH=None
TEST=make -j buildall
Change-Id: Idccaa4d049ace0df3b98b35bdd38ac9dbd843200
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/830917
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Nobody is calling the flush function for consumer_ops structure,
so let's remove it to save flash space, until we find a use for it.
CQ-DEPEND=CL:*529221
BRANCH=none
BUG=chromium:795624
TEST=make buildall -j, saves from 40 to 128 bytes on some boards.
Change-Id: Iad18b30f419ccebc54a90914ec46da84b8d19601
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/826905
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The PPC needs to update its Vbus source current limits whenever our
policy changes on the PD ports. This commit simply adds and API to do
so.
BUG=None
BRANCH=None
TEST=With some extra code to enable 3A out, flash zoombini; Plug in a PD
device to a port, verify that it gets 5V @ 3A. Plug in a second device,
verify that we re-send new source caps of 5V @ 1.5A.
TEST=Repeat above for meowth.
Change-Id: Ifa4bc8b7df87f7730f2bcded842906d43171394b
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/818335
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The size of empty structs (and unions) varies between C and C++. When
including in C++ code our external API in ec_commands.h header with
extern "C". clang will complain (correctly) for all empty structs:
error: empty struct has size 0 in C, size 1 in C++
[-Werror,-Wextern-c-compat]
Remove them from the ec_commands.h header file.
ectool.c has some ugly macros which assume subcommands have both
requests and responses. Change those macros so they only reference
the non-empty sub-structs. The macros are still ugly, but generate
identical output, and don't rely upon zero-length structs.
BUG=chromium:792408
BRANCH=none
TEST=manual
1) Compile the following using 'clang -Wall -Werror':
#include <stdint.h>
extern "C" {
#include "include/ec_commands.h"
}
int main(void) { return 0; }
It compiles without error.
2) Copy the lb_command_paramcount, ms_command_sizes, and
cs_paramcount globals from ectool.c to a dummy .c file and
compile with 'gcc -S' to generate assembly. Do the same
after applying this patch.
Confirm the arrays have the same contents.
Change-Id: Iad76f10315b97205b42118ce070463071fe97128
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/820649
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Pull-down means backlight is present, pull-up means backlight
is absent.
After detection, we still apply internal pull-down on the GPIO,
to make sure old boards with both pull-up and pull-down stuffed
do not always keep backlight on.
BRANCH=none
BUG=b:67722756
TEST=On reworked board with pull-down on backlight pin,
backlight works, and "Backlight present" shown in console.
TEST=On old board with both pull-up and pull-down, backlight is
off by default, and "Backlight not present" shown in console.
Change-Id: I6988c6ef8f4d155a08967db34f72d7ea4c835306
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/538458
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Right now, the only events that are unmasked by default are overcurrent
conditions on PP1. This commit adds a simple interrupt handler and
introduces a board specific callback when the overcurrent status changes
on a port. This way, a board can take whatever action it desires with
the notification.
BUG=b:69139844
BRANCH=None
TEST=Flash zoombini with SN5S330 stuffed. Verify that board boots okay.
TEST=With some extra code to setup the interrupt handler, attempt to
exceed the current limit set, verify that interrupt handler is called.
Reduce the current pulled to under the current limit, verify that the
condition is no longer present.
CQ-DEPEND=CL:797937
Change-Id: Id3321c5703f9608da895be0ed5841f2fb76e734e
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/797936
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Setting password should be allowed only after the owner logged in for
the first time and before they log out or someone else logs in.
Once any other user but the owner logs in, it should become impossible
to set password until the device is reset.
As proposed here, this would apply to both attempts to set password
through crosh and Cr50 console.
Password handling on Cr50 passes the following states:
- password setting is not allowed after Cr50 reset until an upstart
(as opposed to resume) TPM startup happens, as signalled by the TPM
callback. After the proper TPM reset the state changes to
'POST_RESET_STATE' which means that the device was just
reset/rebooted (not resumed) and no user logged in yet.
- if the owner logs in in this state, the state changes to
'PASSWORD_ALLOWED_STATE'. The owner can open crosh session and set
the password.
- when the owner logs out or any user but the owner logs in, the state
changes to PASSWORD_NOT_ALLOWED_STATE and does not change until TPM
is reset. This makes sure that password can be set only by the owner
and only before anybody else logged in.
Separate changes to the TPM library code make sure that TPM reset is
reported through the platform layer, so that POST_RESET_STATE is
entered.
BRANCH=cr50
BUG=b:67007578
TEST=with the rest of the infrastructure in place verified that
password can be set only when the owner logged in for the first
time before anybody else logs in or the owner logs out.
Change-Id: Ieaa3dc8ff9d2e43ae11151eb31173220f5c75b58
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/804141
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
There might be more than one place that will use very similar codes in
CL:542716 (usb_i2c.c). To avoid unnecessary duplication of code, we fold
the logic into i2c_xfer(). With config enabled (illustrated in this CL),
i2c_xfer() will support large reading. An early prototype of potential
usage is demostrated in CL:781300.
BRANCH=none
TEST=For CONFIG_I2C_XFER_LARGE_READ:
With proprietary software on slave: ./touchpad_updater -d
TEST=For usb_i2c regression:
./touchpad_updater still works (where the reading is less than 255)
TEST=For generic EC regression test:
On poppy EC (With CONFIG_I2C_XFER_LARGE_READ defined)
(1) Prevent override of update
/usr/share/vboot/bin/set_gbb_flags.sh 0xa39
(2) flashrom -p ec -w ec_binary_contains_this_CL.bin
(3) ectool reboot_ec cold
(4) "ectool version" verified that both RO/RW/Build info is local.
(5) Test with a type-C DP dongle on DELL 2408WFP.
(6) Plug-in type-C charger and external display still works.
(7) Confirmed that battery is charging.
(7) "ectool battery" reads same data (for fixed field) as before.
(8) "ectool usbpdpower", confirmed charger info displayed as before.
(9) "ectool usbpd 0", confirmed content exactly as before.
(10) For Gyro. Verify under Arc++
Using App: com.gamma.bubblelevel, works the same as before.
(11) For Accelerometers. Verify under Arc++
Using App: com.innoventions.sensorkinetics,
small movement's charts looks as expected.
TEST=For generic EC regression test:
On Caroline EC (Without CONFIG_I2C_XFER_LARGE_READ defined).
Details in CL:810332
BUG=b:63993891
Change-Id: I654868945fa535e784800177d54eb2d9803f5249
Signed-off-by: Chun-Ta Lin <itspeter@google.com>
Reviewed-on: https://chromium-review.googlesource.com/788479
Commit-Ready: Chun-ta Lin <itspeter@chromium.org>
Tested-by: Chun-ta Lin <itspeter@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The SN5S330 has support for detecting when Vbus is present on a port.
This commit simply adds an API to query the PPC.
BUG=None
BRANCH=None
TEST=`make -j buildall`.
TEST=Flash a board with the SN5S330, with some extra code, verify that
Vbus can be detected with this API.
Change-Id: I45bf7ff24bcdc447efe12932f51f8094108e29d5
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/791502
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Unified Host Event Programming Interface (UHEPI) enables a unified host
command EC_CMD_PROGRAM_HOST_EVENT to set/get/clear different host events.
Old host event commands (0x87, 0x88, 0x89, 0x8A, 0x8B, 0x8C, 0x8D, 0x8E,
0x8F) is supported for backward compatibility. But newer version of
BIOS/OS is expected to use UHEPI command (EC_CMD_PROGRAM_HOST_EVENT)
The UHEPI also enables the active and lazy wake masks. Active wake mask
is the mask that is programmed in the LPC driver (i.e. the mask that is
actively used by LPC driver for waking the host during suspended state).
It is same as the current wake mask that is set by the smihandler on host
just before entering sleep state S3/S5. On the other hand, lazy wake masks
are per-sleep masks (S0ix, S3, S5) so that they can be used by EC to set
the active wake mask depending upon the type of sleep that the host has
entered. This allows the host BIOS to perform one-time programming of
the wake masks for each supported sleep type and then EC can take care
of appropriately setting the active mask when host enters a particular
sleep state.
BRANCH=none
BUG=b:63969337
TEST=make buildall -j. And verfieid following scenario
1). Verified wake masks with ec hostevent command on S0,S3,S5 and S0ix
2). suspend_stress_test with S3 and S0ix
3). Verified "mosys eventlog list" in S3 and s0ix resume to confirm
wake sources (Lid, power buttton and Mode change)
4). Verified "mosys eventlog list" in S5 resume to confirm wake sources
(Power Button)
5). Verified above scenarios with combination of Old BIOS + New EC and
New BIOS + Old EC(making get_feature_flags1() return 0)
Change-Id: Idb82ee87fffb475cd3fa9771bf7a5efda67af616
Signed-off-by: Jenny TC <jenny.tc@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/576047
Commit-Ready: Jenny Tc <jenny.tc@intel.com>
Commit-Ready: Jenny Tc <jenny.tc@intel.corp-partner.google.com>
Tested-by: Jenny Tc <jenny.tc@intel.com>
Tested-by: Jenny Tc <jenny.tc@intel.corp-partner.google.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This commit introduces a driver framework for power path controllers.
It provides some common PPC APIs as well as allowing a board to use
multiple different PPCs drivers/parts. This should make it easier to
add PPC drivers in the future.
BUG=None
BRANCH=None
TEST=`make -j buildall`
TEST=Flash zoombini; verify PPC works as expected.
TEST=Flash meowth; verify PPC works as expected.
Change-Id: Icfb99f384610590b431456cfd28d4aff18442cb2
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/807630
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
After firmware update, cr50 toggles the EC's reset line, expecting
the system will boot. This isn't the case for Chromebox because it
sets AP_OFF flag on a clean shutdown (to restore the previous power
state after power loss & restore).
This patch adds EC_REBOOT_HIBERNATE_CLEAR_AP_OFF to EC reboot
command. It makes EC first clear AP_OFF then hibernate.
BUG=b:69721737
BRANCH=none
TEST=Verify Fizz reboot after cr50 update.
Change-Id: If3207d7284f244ca1adf0d516ef744dbc739a9c1
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/802632
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Also added CONFI_ISH_I2C_PORT0_SPEED, CONFI_ISH_I2C_PORT1_SPEED, and
CONFI_ISH_I2C_PORT2_SPEED to define speed for each ISH I2C port. By
default, those are set to fast mode, 400kbps, I2C_SPEED_FAST.
The values can be modified in board.h.
BUG=None
BRANCH=None
TEST=On Soraka modified board for ISH, set I2C stardard mode, fast mode
and fast mode plus, measured I2C clock freq using scope respectively and
confirmed the freq matched I2C mode.
Change-Id: I426b50dc935c3760903360a50f6069e99bd0abff
Signed-off-by: li feng <li1.feng@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/784091
Commit-Ready: Li1 Feng <li1.feng@intel.com>
Tested-by: Li1 Feng <li1.feng@intel.com>
Reviewed-by: Aaron Durbin <adurbin@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>
This change adds a new software panic type PANIC_SW_PMIC_FAULT that
can be used to report any PMIC faults during previous boot.
BUG=b:65732924,b:69334392
BRANCH=None
TEST=make -j buildall
Change-Id: I218b5d01ee145bb02a773495046f4255f1ec8986
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/797910
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 new vendor command takes the CCD state machine through necessary
transitions leaving it in the CCD locked state.
It succeeds only if user password is not set and CCD capabilities are
right, which is guaranteed to be the case after an RMA unlock.
BRANCH=cr50
BUG=b:68213540
TEST=tested using the modified gsctool utility.
Change-Id: Ic2cce34e74b1ff476841cfa1a99f50d6a947c315
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/784352
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Usually, the max current and supply voltage of dedicated chargers
are not known to the EC.
This patch adds EC_CMD_OVERRIDE_DEDICATED_CHARGER_LIMIT, which
allows the host to change the max current and supply voltage of the
dedicated charge port.
BUG=b:64442692
BRANCH=none
TEST=make runtests && buildall. Boot Fizz and let coreboot set
the adapter current and voltage.
Change-Id: I29b3f5762f8b316ca363c23e230530cdf4ca207a
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/769152
For now we guard charger-based VBUS voltage measurement
behind CONFIG_USB_PD_VBUS_DETECT_CHARGER.
But we should be able to measure VBUS voltage by charger
while detecting VBUS presence by other methods.
BUG=b:67991345
BRANCH=none
TEST=plug in guppy on Scarlet rev2, 'ectool usbpdpower' on console,
and see VBUS is measured as 4975mV
Change-Id: I94cada81159ea4b097001997e2444873ec2d8763
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/789910
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Originally, i2c passthru is limited to use I2C_XFER_SINGLE flag where
it can only read at most 255 bytes at a time. For application that
requires larger i2c bus reading, we change the flag setting and the
command protocol.
TEST=old ./touchpad_updater still works (previous protocol)
TEST=new ./touchpad_updater can get more than 500 bytes per transaction
TEST=Debug message only print when -d assigned.
./touchpad_updater -d
TEST=Manually change #define CONFIG_USB_I2C_MAX_READ_COUNT (1024 - 6)
to #define CONFIG_USB_I2C_MAX_READ_COUNT (1024 - 4) and trigger
POWER_OF_TWO assertion.
BRANCH=none
BUG=b:35587174, b:63993891
Change-Id: Id75b11ea49ba89bab8e18af24d47219030c778c5
Signed-off-by: Chun-Ta Lin <itspeter@google.com>
Reviewed-on: https://chromium-review.googlesource.com/542716
Commit-Ready: Chun-ta Lin <itspeter@chromium.org>
Tested-by: Chun-ta Lin <itspeter@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
This only adds the structs for V4 packets. Host command support for
them is coming in a subsequent CL. V3 packets will continue to be
supported for a while, until all sides support V4.
BUG=chromium:787159
BRANCH=none
TEST=make -j runtests
Change-Id: I7e188a063d8ed60c85f3b8359959c424e3ccd1d9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/780452
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
With the upcoming change to add a new command to get/set/clear host
events and masks, it seems to be the right time to bump up the host
events and masks to 64-bit. We are already out of available host
events. This change opens up at least 32 bits for new host events.
Old EC commands to operate on host events/masks will still deal with
lower 32-bits of the events/mask. On the other hand, the new command
being added will take care of the entire 64-bit events/masks. This
ensures that old BIOS and kernel versions can still work with the
newer EC versions.
BUG=b:69329196
BRANCH=None
TEST=make -j buildall. Verified:
1. hostevent set 0x4000 ==> Sets correct bit in host events
2. hostevent clear 0x4000 ==> Clears correct bit in host events
3. Kernel is able to query and read correct host event bits from
EC. Verified using evtest.
4. Coreboot is able to read correct wake reason from EC. Verified
using mosys eventlog list.
Change-Id: Idcb24ea364ac6c491efc2f8dd9e29a9df6149e07
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/770925
Reviewed-by: Randall Spangler <rspangler@chromium.org>
These functions are not used by usb_i2c.c on chip/stm32, let's
move them to board/cr50 which is the only place where they are
used.
BRANCH=none
BUG=None
TEST=make buildall -j
Change-Id: I8c1b292838b8dbee9a9001add9332e0add80c342
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/778749
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Change the names to generic touchpad_* functions, instead of
vendor-specific names. Makes it a little easier to add drivers
for other touchpads.
Also fix console_channel.inc to add the channel whenever any
touchpad is used.
BRANCH=none
BUG=b:68934906
TEST=make buildall -j
Change-Id: I6d268db5ebd53db272fb2ee7bbf06bbe80845734
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/778750
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Nearly every board had a buttons array defined in which its contents had
the standard volume buttons. This commit creates a single common
buttons array that can contain the standard volume buttons and recovery
buttons. If a board has volume up and down buttons, they can simply
define CONFIG_VOLUME_BUTTONS and it will populate the buttons array with
the standard definition. The buttons are active low and have a 30 ms
debounce period. Similiarly, if a board has a dedicated recovery
button, defining CONFIG_DEDICATED_RECOVERY_BUTTON will also populate the
buttons array with a recovery button.
BUG=chromium:783371
BRANCH=None
TEST=make -j buildall.
TEST=Flash a device with CONFIG_VOLUME_BUTTONS, verify pressing volume
buttons still work.
Change-Id: Ie5d63670ca4c6b146ec8ffb64d40ea9ce437b913
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/773794
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
At the end of the sensor initialization, all _init sensor routines set
the range to the default value from board.c file.
Put all the code in a single place, move it from sensor_common.c to
motion_sense.c.
BUG=none
BRANCH=none
TEST=compile
Change-Id: If89cf27c6438e0f215c193d68a480e027110174c
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/767610
Reviewed-by: Shawn N <shawnn@chromium.org>
EC_IN_RW signal is used to determine if the switch to dev mode can be
safely made. However, EC_IN_RW needs the EC_RST_L line driven low in
order to be reset. In faft tests that utilize crosEcSoftrecPower
method, EC_RST_L is not being driven by servo to fix other test
failures related to keeping EC and AC reboots in sync.
This CL adds a new argument 'wait-ext' to the EC reboot command.
When this option is used, instead of the EC generating a reset via
it's system watchdog, it will wait 10 seconds for EC_RST_L to be
driven.
BUG=b:64603944
BRANCH=coral
CQ-DEPEND=I086687c3dd7591460099267880d56ab8265d2e4b
TEST=Ran "/usr/bin/test_that --board=coral <ip addr> firmware_DevMode"
mutliple times and verified that it passes. Previoulsy, this test
always fails when the EC is in RW before it starts. Also tested
platform_ServoPowerStateController_USBPluggedin and verified it passed.
Change-Id: I614f9156066d5719601ee43e29c7a064f9bba6e2
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/737524
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This reverts commit 352276235c.
This is required to ensure that PMIC VR decay is enabled before
SLP_S0# is asserted. Else, the setting does not take effect and hence
results in higher power consumption.
BUG=b:69337192
BRANCH=None
TEST=make -j buildall
Change-Id: I6885e7447277d853a2414be299dfea25f5547df4
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/771054
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add espi control module for it83xx.
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=1. it8390+Intel SKL-Y RVP3 and boot to shell.
2. console command "kbpress 1 4" to test keyboard data.
(board code for espi module test on CL:392587)
Change-Id: I1b32bd16f7e01abf07b9c9a68ebef2399cc9828d
Reviewed-on: https://chromium-review.googlesource.com/394471
Commit-Ready: Dino Li <Dino.Li@ite.com.tw>
Tested-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We support touchpad-specific debugging feature over the USB update
protocol. This will be used to fetch raw data from the sensor,
without requiring to remove the write-protect screw.
BRANCH=none
BUG=b:63993891
TEST=./usb_updater2 -g 00 -d 18d1:502b
Change-Id: I46dfd97aaa17b73a5893fe1e8c62327a302f829b
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/763574
Reviewed-by: Chun-ta Lin <itspeter@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This patch allows Fizz to switch the power source from a type-c
charger to a barrel jack adapter if the system is in S5.
BUG=b:38321259
BRANCH=none
TEST=Verify the following with 45W and 60W type-c chargers:
1. Boot Fizz with a type-c charger
2. Go to S5 if not already.
3. Plug in a BJ adapter. Fizz boots to S0 using BJ power.
Also verified other boot modes are not affected:
1. Auto boot on BJ insert
2. Auto boot on Type-C insert
3. Recovery boot on BJ
4. Recovery boot on Type-C
5. Stay off if it's previously S5
Change-Id: I86aa0fe6e403bcbacfe396997d897111ffcf8e74
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/706251
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Currently the Cr50 code resets TPM communications layer at a certain
point during TPM reset process.
It turns out that this is not sufficient - the comms layer keeps
receiving and trying to invoke TPM layer, which does not mesh well
with TPM reset.
Let's provide two callbacks for each comms layer - to shut it down and
to bring it back up. We shut down the comms when starting TPM reset
and bring them back up when reset is completed.
BRANCH=cr50
BUG=b:68012381
TEST=ran AP firmware test suite on both SPI and I2C based devices.
Change-Id: I7caf4a09b9a5c6e5fc6bfe60eae1c0d64ab24904
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754502
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
gcc 6.3 (as provided by coreboot-sdk) needs that to know which code
paths end early.
Also add a loop after the command that is "supposed" to reset the
machine so that the compiler believes it (and in case that assumption
fails).
BRANCH=none
BUG=b:65441143
TEST=none
Change-Id: Idb87253ec7880d66ffec30d75f4d007f02f63aab
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/742916
Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
It's undesirable to do BC1.2 detection on power swap, so add a function
to check if the partner port is known to be PD-capable.
BUG=chromium:780905
BRANCH=gru
TEST=With subsequent CL, attach USB-PD phone capable of role swap.
Verify USB 2.0 device is enumerated on plug, and not re-enumerated
through a series of "pd # swap power" commands on the EC console. Also
verify BC1.2 charging and PD charging are still functional on kevin.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ifa75c94e9758d3e407492bbda6fc52ed7bc378fa
Reviewed-on: https://chromium-review.googlesource.com/755877
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The bd9995x driver was written to allow any PD port # to be VBUS or VCC,
but the mapping is broken in a few places. Since all boards use VBUS =
port 0, remove the conversion entirely.
BUG=chromium:781849
BRANCH=kevin
TEST=Verify PD and BC1.2 charging still works on kevin.
Change-Id: I3687866835d1684342d9f746d91b3a6079ab5cc4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/755000
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
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>
