We currently rely on *head == 0 as error condition, which is
fragile and inconsistent across TCPCs implementations.
Instead, let's return a proper return value on all implementations.
BRANCH=none
BUG=chrome-os-partner:60575
TEST=elm FW as of 65fb80d (later version include a fix that would
hide this issue), cherry-pick this patch, connect j5create
adapter, then HDMI, then power => no crash
Change-Id: If7235e0491e9f80fdd50ce2605477ee518f8e1aa
Reviewed-on: https://chromium-review.googlesource.com/417443
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
From TCPC spec:
"""
RECEIVE_BYTE_COUNT: Indicates number of bytes in this register
that are not stale. The TCPM should read the first RECEIVE_BYTE_COUNT
bytes in this register. This is the number of bytes in the
RX_BUFFER_DATA_OBJECTS plus three (for the RX_BUF_FRAME_TYPE and
RX_BUF_HEADER).
"""
We were always reading 3 bytes too many. This is an issue if we
receive a packet followed by a hard reset, as the register value
will be set back to 0, but TCPC_REG_RX_HDR may contain a valid
header, leading to corrupted packets being passed down the stack.
Also update usb_pd_tcpc to match the specification.
BRANCH=none
BUG=chrome-os-partner:60575
TEST=elm FW as of 65fb80d (later version include a fix that would
hide this issue), cherry-pick this patch, connect j5create
adapter, then HDMI, then power => no crash
Change-Id: I9ed8f3b500d5733ec7563e31246505e0b8bd48bb
Reviewed-on: https://chromium-review.googlesource.com/417442
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Modified the SPI NOR flash driver to implement
and expose a read JEDEC ID command as well as
support block (64KiB) erase operations.
BUG=None
BRANCH=None
TEST=Built all targets. Tested on two different EEPROMs.
Before:
-------------------------------------------
$ ~/haven_updater$ ./read_jedec_ftdi
[+] JEDEC_ID=0x1940ef
$ ~/haven_updater$ time ./chip_erase_ftdi
[+] Success!
real 4m0.440s
user 0m6.674s
sys 0m11.998s
-------------------------------------------
$ ~/haven_updater$ ./read_jedec_ftdi
[+] JEDEC_ID=0xc21a20c2
$ ~/haven_updater$ time ./chip_erase_ftdi
[+] Success!
real 5m57.291s
user 0m9.964s
sys 0m18.363s
-------------------------------------------
After:
-------------------------------------------
$ ~/haven_updater$ ./read_jedec_ftdi
[+] JEDEC_ID=0x1940ef
$ ~/haven_updater$ time ./chip_erase_ftdi
[+] Success!
real 1m33.176s
user 0m2.327s
sys 0m5.050s
-------------------------------------------
$ ~/haven_updater$ ./read_jedec_ftdi
[+] JEDEC_ID=0xc21a20c2
$ ~/haven_updater$ time ./chip_erase_ftdi
[+] Success!
real 2m41.923s
user 0m4.191s
sys 0m8.576s
-------------------------------------------
Change-Id: Ic20372ca9966499977a52a700d6492d3f648d7b2
Signed-off-by: Nadim Taha <ntaha@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416903
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Some chargers lose VBUS even when ramp is stable and we re-ramp for
those chargers. It continues in loop. To avoid this issue, reduce
the max input current limit if VBUS drops on stable ramp.
BUG=chrome-os-partner:60544
BRANCH=none
TEST=Tested on Reef. Ramp settles to lower current and multiple
re-ramp is not observed.
Change-Id: I6c9ce4720d01b9e8e3215e8122f798076e516c19
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/416349
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Rachel Nancollas <rachelsn@google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
It's preferable to print an error when mv = 0, rather than
crashing. Also, do not even select invalid PDO in
pd_find_pdo_index.
This was seen on elm, where ANX7688 appears to send the EC a
corrupted packet during hard reset when connected to j5create
adapter.
BRANCH=none
BUG=chrome-os-partner:60575
TEST=Plug in j5create adapter, then HDMI adapter, then power, elm
does not crash (note that the HDMI output still does not work,
but at least elm charges).
Change-Id: I2150ad6f13465a005444804ec44ec3bdc0ded361
Reviewed-on: https://chromium-review.googlesource.com/416700
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If battery is not present, input current is set to PD_MAX_CURRENT_MA.
If the input power set is greater than the maximum allowed system power,
system might get damaged. Hence, limit the input current to meet maximum
allowed input system power.
BUG=chrome-os-partner:58498
BRANCH=none
TEST=Manually tested on Reef. Removed the battery & using 'charger'
console command observed the following.
With Zinger charger at 20V - Input current is set to 2.25A
With Type-C & other chargers - Input current is set to 3A
Change-Id: Ife8686f322e095aa74b740a7c469bfe87107fb9a
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/397865
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Upon requesting a PD power contract at a new voltage, keep the input
current limit at 500mA until PD_RDY is received.
BUG=b:30744563,chrome-os-partner:59311,chrome-os-partner:44340
BRANCH=ryu, gru, glados
TEST=Manual on kevin, set ilim to 5V through `chglim` console command,
attach zinger. Set ilim to 20V through `chglim`, verify that ilim goes
from 3A to 500mA to 3A.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I452f183cfb958780e336a9f99dc6398356de17a0
Reviewed-on: https://chromium-review.googlesource.com/399918
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When a WAIT is received in response to a request, wait SinkRequestTime
before resending the request.
BUG=chrome-os-partner:34984
TEST=make -j buildall
BRANCH=none
Change-Id: I5c8429c4a7b9cf06609996f924b8d9d535ab6b5f
Reviewed-on: https://chromium-review.googlesource.com/414533
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Common code is more flexible and supports more parts, so delete the
npcx-only register translation code.
BUG=chrome-os-partner:60029
BRANCH=gru
TEST=Manual on gru, run 'flashrom -p ec --wp-enable' and check that 0x28
gets written to SR1, which matches our desired 'protect botton 128KB',
according to the datasheet. Also run 'flashrom -p ec --erase' then read
back EC SPI contents, verify ROM is erased except for first 128KB
region.
Change-Id: I526401997ff7ec77f2a6047a4a9af74a671ed69a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/413228
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 43634d36d273887b1f2349c333a7b4b229a83365)
Reviewed-on: https://chromium-review.googlesource.com/415498
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Making dual-role determination after receiving source caps is not
sufficient, since we may not yet have identified the partner port.
BUG=chrome-os-partner:56966
BRANCH=gru
TEST=Attach 'old' Apple USB-C accessory to kevin, attach OEM charger to
accessory, run 'pd X hard', verify device charges from port.
Change-Id: I7333dd2c723e7245d30cf8a6cb1344e60073c063
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/403118
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 09691a0e8dd93383fa76b74332d89707bfe16001)
Reviewed-on: https://chromium-review.googlesource.com/415492
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
On the bd9995*, back boosting may occur when actual battery voltage
drops below VBAT register setting. Maintain the VBAT register at the
battery-requested charge voltage even when not charging to ensure the
bd9995* doesn't become a back boosted animal.
BUG=chrome-os-partner:56139,chrome-os-partner:54248
BRANCH=gru
TEST=Manual on kevin, unplug AC, run 'charger', verify that 'V_batt' is
maintained at 8688 mV. Attach charger, verify 'V_batt' stays at 8688 mV
and device charges.
Change-Id: Ia0cc7f9279cb460e20a8faf332ad432067dc5482
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400087
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This reverts commit c459c8278e
as the fix is not straightforwad, some host command codes in
private repos are expressed using C preprecessor which
breaks the assumption of this patch that all host commands
are expressed as four digit hex numbers.
Change-Id: I922de9ae8dbab6eef048463c5c09b1f338152083
Reviewed-on: https://chromium-review.googlesource.com/414492
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Use binary search in host command lookup dispatcher
BUG=chrome-os-partner:570895
TEST=manual testing on kevin
- Kevin boots
- ectool hello
make buildall -j
Verify *.smap hcmds section is sorted:
100bca94 R __hcmds
100bca94 R __host_cmd_0x0000
100bcaa0 R __host_cmd_0x0001
100bcaac R __host_cmd_0x0002
100bcab8 R __host_cmd_0x0003
100bcac4 R __host_cmd_0x0004
100bcad0 R __host_cmd_0x0005
100bcadc R __host_cmd_0x0006
100bcae8 R __host_cmd_0x0007
100bcaf4 R __host_cmd_0x0008
100bcb00 R __host_cmd_0x0009
100bcb0c R __host_cmd_0x000a
100bcb18 R __host_cmd_0x000b
100bcb24 R __host_cmd_0x000d
100bcb30 R __host_cmd_0x0010
100bcb3c R __host_cmd_0x0011
100bcb48 R __host_cmd_0x0012
100bcb54 R __host_cmd_0x0013
100bcb60 R __host_cmd_0x0015
100bcb6c R __host_cmd_0x0016
100bcb78 R __host_cmd_0x0017
100bcb84 R __host_cmd_0x0025
100bcb90 R __host_cmd_0x0026
100bcb9c R __host_cmd_0x0029
100bcba8 R __host_cmd_0x002a
100bcbb4 R __host_cmd_0x002b
100bcbc0 R __host_cmd_0x002c
100bcbcc R __host_cmd_0x0044
100bcbd8 R __host_cmd_0x0045
100bcbe4 R __host_cmd_0x0046
100bcbf0 R __host_cmd_0x0047
100bcbfc R __host_cmd_0x0061
100bcc08 R __host_cmd_0x0062
100bcc14 R __host_cmd_0x0064
100bcc20 R __host_cmd_0x0065
100bcc2c R __host_cmd_0x0067
100bcc38 R __host_cmd_0x0087
100bcc44 R __host_cmd_0x008c
100bcc50 R __host_cmd_0x008d
100bcc5c R __host_cmd_0x008f
100bcc68 R __host_cmd_0x0092
100bcc74 R __host_cmd_0x0093
100bcc80 R __host_cmd_0x0096
100bcc8c R __host_cmd_0x0097
100bcc98 R __host_cmd_0x0098
100bcca4 R __host_cmd_0x0099
100bccb0 R __host_cmd_0x009e
100bccbc R __host_cmd_0x00a0
100bccc8 R __host_cmd_0x00a1
100bccd4 R __host_cmd_0x00a8
100bcce0 R __host_cmd_0x00a9
100bccec R __host_cmd_0x00b6
100bccf8 R __host_cmd_0x00b7
100bcd04 R __host_cmd_0x00d2
100bcd10 R __host_cmd_0x00d3
100bcd1c R __host_cmd_0x00db
100bcd28 R __host_cmd_0x0101
100bcd34 R __host_cmd_0x0102
100bcd40 R __host_cmd_0x0103
100bcd4c R __host_cmd_0x0104
100bcd58 R __host_cmd_0x0110
100bcd64 R __host_cmd_0x0111
100bcd70 R __host_cmd_0x0112
100bcd7c R __host_cmd_0x0113
100bcd88 R __host_cmd_0x0114
100bcd94 R __host_cmd_0x0115
100bcda0 R __host_cmd_0x0116
100bcdac R __host_cmd_0x0117
100bcdb8 R __host_cmd_0x0118
100bcdc4 R __host_cmd_0x011a
100bcdd0 R __evt_src_EC_MKBP_EVENT_KEY_MATRIX
100bcdd0 R __hcmds_end
BRANCH=none
Change-Id: Ideb9951b318763f71915e2c4e5052f4b4bfab173
Reviewed-on: https://chromium-review.googlesource.com/405528
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When the console is unlocked, the function nvmem_wipe_or_reboot()
is called. This holds the EC in reset, clears nvmem, resets the
TPM task, then releases the EC. Nothing about that should cause
the Cr50 to reboot, but it was happening anyway.
This CL addresses several subtle problems.
First, holding the EC in reset invoked the sys_rst_asserted()
interrupt handler, triggering extra (and early) calls to
tpm_reset(). That should wait until after nvmem is cleared, and
only be called once.
Second, the intentional call to tpm_reset() caused the current
(HOOKS) task to wait for the operation to finish, but it didn't
wait long enough (recreating the endorsement certs can take over
a second). When the task_wake_event() returned, a timeout was
indicated in addition to the completion event.
Third, because we checked for the timeout first, we reported an
error even though tpm_reset() completed successfully, just slower
than we expected. We didn't get the timeout event before it
completed because the TPM task runs at a higher priority.
This CL addresses all of these cases, and makes wiping nvmem the
responsibility of the TPM task as well, so that it can do it when it's
ready.
Note that the EC (and thus AP too) will be held in reset while nvmem is
erased.
BUG=chrome-os-partner:59902
BRANCH=none
TEST=make buildall, manual tests
From the Cr50 console, run the "lock on" and "lock off" commands.
Try it both with and without the battery present. Observe that
the Cr50 no longer reboots just because the console unlocks.
Change-Id: I65a342502718acc5b9bda8c6f28dcd27e8f027f7
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/411379
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
File-scoped variables in common/tpm_registers.c must be handled
specially to avoid unexpected behavior when calling tpm_reset().
Enhance the comments and add a couple of macros to help explain
it better.
BUG=none
BRANCH=none
TEST=make buildall; Run on Reef
This is just commenting and code cleanup. No changes in behavior
are expected; none are observed.
Change-Id: If70e56d00642a11df7b5ceb5d5d32c485236f7a8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/412407
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The variable last_rx_time shouldn't be able to be used without being
initialized, so initialize it to make GCC 5.x & 6.x happy.
common/btle_ll.c: In function 'bluetooth_ll_task':
common/btle_ll.c:835:25: error: 'last_rx_time' may be used uninitialized
in this function [-Werror=maybe-uninitialized]
This does not change the size of any ec.*.flat file.
BRANCH=none
BUG=none
TEST=build succeeds under GCC 4.9.2, 5.3, and 6.2
Change-Id: I99f716fcb3c8c871e4f325eca3bf3cd622e727d1
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/411406
Reviewed-by: Shawn N <shawnn@chromium.org>
The variable "offset" gets configured if it's not the first data packet,
but gets used even on the first data packet.
common/btle_ll.c: In function 'connected_communicate':
common/btle_ll.c:729:15: error: 'offset' may be used uninitialized
in this function [-Werror=maybe-uninitialized]
This does not change the size of any ec.*.flat file.
BRANCH=none
BUG=none
TEST=build succeeds under GCC 4.9.2, 5.3, and 6.2
Change-Id: Ib3882aab3e081afc4b00dc02b002ba4c590cb0f9
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/403500
Reviewed-by: Shawn N <shawnn@chromium.org>
Some functions are only defined if CONFIG_HOSTCMD_EVENTS is set,
leading to link-time failures.
In particular, do not call these functions from keyboard_scan,
and do not define PD host event commands if the configuration
option is not set.
BRANCH=none
BUG=chrome-os-partner:59083
TEST=make buildall -j
Change-Id: I0da31cdec08f86f148aa883698a44f462de46d8e
Reviewed-on: https://chromium-review.googlesource.com/410923
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This add basics for acc and gyro sensor ST lsm6dsm
Still need to add interrupt management for embedded
functions and FIFO
BUG=none
BRANCH=master
TEST=Tested on discovery BOARD with sensor connected on
EC i2c master bus. Added motion sense task on discovery
board task list, added gpio info in board configuration
file and tested with motion sense console commands. Data
for acc/gyro seems ok, can successfully change ODR and
full scale range for acc and gyro.
Change-Id: Ie50c8c0ee366994ed97f7ff3252633893b813ac2
Signed-off-by: Mario Tesi <mario.tesi@st.com>
Reviewed-on: https://chromium-review.googlesource.com/406947
Commit-Ready: mario tesi <mario.tesi@st.com>
Tested-by: mario tesi <mario.tesi@st.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Chrome seems to pay attention to the tablet mode switch reported by the
EC. However, for some devices that don't actually have a switch and use
the lid angle as a "virtual" switch, it's possible for invalid tablet
mode change events to be reported. This is because a single reading
could flip the switch.
This commit adds some debouncing to the tablet mode event changes.
Instead of having a single event be able to change the tablet mode
switch, we will now perform TABLET_MODE_DEBOUNCE_COUNT number of
calculations of the new tablet mode value. If those calculations all
agree, then we'll flip the switch. This should help mitigate false
tablet mode change events caused by spurious forces.
BUG=chrome-os-partner:59203
BUG=chrome-os-partner:59480
BRANCH=gru
TEST=flash kevin; open lid to pi/2 rad; rotate device counter-clockwise
pi/2 rad; shake device and verify that tablet mode doesn't change
easily.
TEST=verify that tablet mode still works.
Change-Id: Id020f7db28e93e53b276b3f0d28a40251f035f0b
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/410942
Commit-Ready: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
This allows custom TPM commands to be declared using the a
DECLARE_VENDOR_COMMAND macro instead of the original (and still
unchanged) DECLARE_EXTENSION_COMMAND macro.
The new commands are nearly identical, but they are encapsulated
using the vendor-specific protocols described in the TPMv2 spec.
Our original extensions use a non-standard command code, and
return a non-standard struct on completion, which can be
confusing to standard TPM drivers and tools.
Demonstrating the use of the new macros, this adds commands to
obtain the state of the Cr50 restricted console lock, or to set
the lock. There is intentionally no command to unlock the
console.
Note that this CL just adds the commands to the Cr50. We still
need to provide a nice userspace utility for the AP to use.
BUG=chrome-os-partner:58230
BUG=chrome-os-partner:57940
BRANCH=none
TEST=make buildall; load, boot, test, and update again on Reef
On Reef, I can use the trunks_send tool to send the raw TPM bytes
to invoke these commands:
Get the lock state:
# trunks_send 80 01 00 00 00 0C 20 00 00 00 00 10
80010000000D00000000001000
The last byte 00 indicates that the lock is NOT set, so set it:
# trunks_send 80 01 00 00 00 0C 20 00 00 00 00 10
80010000000C000000000011
Success. On the Cr50 console, I see it take effect:
[480.080444 The console is locked]
Query the state again:
# trunks_send 80 01 00 00 00 0C 20 00 00 00 00 10
80010000000D00000000001001
and now the last byte 01 indicates that the console is locked.
And of course the existing extension commands still work as
before. In addition to uploading firmware, I can use the
usb_updater from my build machine to query the running firmware
version:
$ ./extra/usb_updater/usb_updater -f
open_device 18d1:5014
found interface 4 endpoint 5, chunk_len 64
READY
-------
start
Target running protocol version 5
Offsets: backup RO at 0x40000, backup RW at 0x4000
Keyids: RO 0x3716ee6b, RW 0xb93d6539
Current versions:
RO 0.0.10
RW 0.0.9
$
Change-Id: I7fb1d888bf808c2ef0b2b07c782e926063cc2cc4
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/409692
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
BUG=chrome-os-partner:55158,chrome-os-partner:55889,chrome-os-partner:55890
BRANCH=none
TEST=on reef use ina (pp3300_pd_a_mw) to check tcpc power consumption
Change-Id: I5a2904f4e549b7da22242848bb3b1887331ecadd
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/399882
Reviewed-by: David Hendricks <dhendrix@chromium.org>
These keys are much quicker to verify (259ms to 51ms on a -M0 at
48 Mhz), so they can be used when timing is critical and
verification needs to be performed on the board.
BRANCH=none
BUG=chromium:663631
TEST=make buildall -j && make run-rsa
TEST=make run-rsa3 (next commit)
Change-Id: I0da4b3e21543bb6f7b18e8b6ddc5e153046a61b8
Reviewed-on: https://chromium-review.googlesource.com/408006
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When kernel get EC_HOST_EVENT_PD_MCU event and query power state, we may
not done refresh here. Delay EC_HOST_EVENT_PD_MCU event to avoid this
race.
BUG=chrome-os-partner:59499
BRANCH=gru
TEST=Manual on kevin, check power state correct after unplug charger
Change-Id: Ib88acf5a39c2780c6e40144ccebfba17cf84f77c
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/408131
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This adds new key combination (Left_Shift+Esc+Refresh+Power) that triggers
recovery mode by setting a new host event
EC_HOST_EVENT_KEYBOARD_RECOVERY_HW_REINIT. This host event can be used
whenever user wants to request entry into recovery mode by
reinitializing all the hardware state (e.g. memory retraining).
BUG=chrome-os-partner:56643,chrome-os-partner:59352
BRANCH=None
TEST=Verified that device retrains memory in recovery mode
with (Left_Shift+Esc+Refresh+Power) on reef.
Change-Id: I2e08997acfd9e22270b8ce7a5b589cd5630645f8
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/407827
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Simple API to set/get the tablet mode. It can be set via lid angle
calculation or if a board has a dedicated HAL sensor/GPIO.
Merged from glados branch, add MKBP switch support.
BUG=chromium:606718
BRANCH=gru
TEST=Check with Cave that both mode works.
Reviewed-on: https://chromium-review.googlesource.com/402089
Reviewed-by: Shawn N <shawnn@chromium.org>
(cherry picked from commit c940f36ceabcf2425284001298f03ebdb4c3079e)
Change-Id: I2ee5130f3e0a1307ec3ea543f7a32d66bc32b31d
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/404915
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
We were getting occasional stack overflow and watchdog timeouts
when clearing NVMEM. Bump up the stack size a bit in the HOOKS
task, and pet the watchdog before invoking the tpm2 init
functions.
BUG=chrome-os-partner:59419
BRANCH=none
TEST=make buildall, manual
Lock the console, then unlock it. This will reboot the EC & AP,
but should never reboot the Cr50.
Before this CL, it did about half the time.
After, it doesn't.
Change-Id: I33adfeb7360bf7d146a55ef16c923a1a0416393d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/407847
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Since PD task are highest priority, the 50msec delay between was intended
allow other tasks to execute if PD has continuous interrupt. With two
separate TCPC handled by host_command_pd task, interrupt from one TCPC will
block the interrupt handling of another TCPC by this 50msec and cause
error in the PD negotiation.
Reduced to 5msec to ensure TCPC interrupt is handled as soon as possible
while allow other tasks to execute if needed.
BUG=chrome-os-partner:59061
BRANCH=none
TEST=Verify zinger can negotiate to 20V, hoho can get display. Also tested
with faking PD interrupt always asserted to check for watchdog reset.
Change-Id: I9b71277a3d65923f1f5bbfd744b3399e34fd0e6c
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/407542
Tested-by: Divya S Sasidharan <divya.s.sasidharan@intel.com>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
This change is a safegaurd to ensure that TPM register data is always
placed in the correct location in the HW read I2CS fifo. It is only
checked for 1 or 4 byte regsiter reads. Because of the way in which a
TPM command is sent and the response is read, there are multiple reads
of the STS register prior to reading the TPM fifo register. Therefore
ensuring the fifo has zero depth when 1 or 4 byte regsiter reads,
improves the robustness of the design.
Added a counter to track the number of times the fifo is adjusted and
a new console command 'i2cs disp|rst' to display the count and reset
it to 0 if desired.
Removed section in code for TPM fifo register reads intended to handle
the case where there was a mismatch between how many bytes were copied
into the fifo and the number read by the host. Since the burstcount
field in the status register always contains a valid amount of data
that can be read by the host, there should not be cases where the
host reads less data than was copied from the TPM fifo register. In
the unexpected cases where the host may not drain all of the I2CS read
fifo data during a TPM register read, the I2CS fifo depth will be
corrected the next time that it reads either the access or STS
register which happens prior to the start of any TPM transaction.
BRANCH=none
BUG=chrome-os-partner:57338,chrome-os-partner:59191
TEST=manual
Booted Reef and verfied that TPM functionality is working.
Change-Id: I065a55e64bbcc0cb3357a2bd83447a05400b8899
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/382689
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Don't queue non-wake events, and ensure wake events (and all subsequent
events) always get queued.
BUG=chrome-os-partner:59248, chrome-os-partner:59336
BRANCH=gru
TEST=Manual on kevin, go to suspend, press volume keys dozens of times,
press 'shift', verify device wakes. Place cursor on URL bar, go to
suspend, type "google" quickly, verify device wakes and "google" appears
on URL bar. Go to suspend, press 'VolUp' key 5 times, press keyboard,
verify device wakes and no volume meter is seen on display.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ibe761187fbcefd686776a512786550970a6fc067
Reviewed-on: https://chromium-review.googlesource.com/405717
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
(cherry picked from commit aa2f01566314604404e104d7975c6c755c22a601)
Reviewed-on: https://chromium-review.googlesource.com/407958
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Previously the memmap'd host event mask copy wasn't always updated. Be
consistent with other mkbp code and call host_get_event() to get our
current mask.
BUG=chrome-os-partner:59241
BRANCH=gru
TEST=Manual on kevin, close lid to suspend, press volume keys, verify
device doesn't wake. Open lid, verify device wakes. Run
'powerd_dbus_suspend', press volume keys, verify device doesn't wake.
Press keyboard key, verify device wakes.
Change-Id: I3de49efa1ebc53a9c56bed57007c48356c7e97bb
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/406547
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
(cherry picked from commit 763d3b2c6f26d41e7147f860e59755af2fe87fe4)
Reviewed-on: https://chromium-review.googlesource.com/407957
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This combines stm32 and chip/g usb_i2c interfaces so they
will not diverge. Note that this fixes the chip/g implementation
to use 8-bit i2c addresses.
BUG=chrome-os-partner:57059
BRANCH=none
TEST=servod interacts with servo_micro and servo_v4
Change-Id: Ibff217d84b132556202c8a71e3d42c07d546c634
Reviewed-on: https://chromium-review.googlesource.com/405108
Commit-Ready: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
BUG=chrome-os-partner:54668
BRANCH=none
TEST=Verified SNK is detected in S0 (toggle on), S3 (toggle off),
and S5 (force sink). SRC is detect in S0 only, stays detected when
entered S3, but unplug/plug while in S3 will not re-detect until
system back in S0. When go to S5, SRC will get disconnected until
back in S0, and hotplug SRC in S5 will not get detected. Checked
power role swap with another chromebook in the above scenario also.
Change-Id: I2a487fca5cb04c45524aa3efde84fcd10ff0579e
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/396918
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When sourcing current on the type-C port, set the OCP limit on the VBUS
load switch according to current dynamic capability.
(3.0A when only one port is a power source, 1.5A else)
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=gru
BUG=chrome-os-partner:56110
TEST=manual: connect Caroline to Kevin with Twinkie in between,
ask Caroline to sink current through the UI.
without anything else connected on Kevin, see 3A flowing when measuring
with Twinkie ('tw vbus'), plug a dangling C-to-A receptacle dongle on
the other Kevin port and see 1.5A flowing through Twinkie.
Force the input current limit on Caroline to 3.0A and see Kevin cutting
VBUS.
Change-Id: Ib879b1ed720b20aa702c5f3643948ba0575d1193
Reviewed-on: https://chromium-review.googlesource.com/403869
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Previously, sleep was being reenabled only after tpm fifo reads as
that would typcially be near the end of a host driven TPM
command. However, in the case the host reads or writes to the STS
register, then sleep would not be re-enabled. Moved the re-enable
point to at the end of every i2cs interrupt. Since sleep is delayed by
1 second prior to being reenabled then Cr50 will not go to sleep in
the middle of TPM command since the host is either writing or reading
STS at a much faster rate when a TPM command is being executed.
BRANCH=none
BUG=chrome-os-partner:40397
TEST=manual
Added a debug counter in idle.c and shortened sleep delays from 3
minutes to 5 seconds. Unplugged suzyq and verified that when
reconnected, the counter was incrementing to verify that Reef would
go to sleep. Also verified that TPM worked successfully and kernel
was launched.
Change-Id: I03ad33ed3591bbba24b5c56445c06d0e11368019
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/401808
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
In __wait_evt(), if a timer expiration occurs after we read event
status, before the timer is canceled, then TASK_EVENT_TIMER will be
propagated to the next task wait, likely leading to premature timeout.
Prevent this by clearing TASK_EVENT_TIMER after canceling our timer.
BUG=chrome-os-partner:58658
BRANCH=gru
TEST=Manual on gru, run 'pd # hard' for 12 hours with charger attached,
verify no TCPC I2C read errors occur.
Change-Id: Iac2f05a768b4ef29f82e7c3eb899f4c7dd5c3744
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400968
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When the board is using dynamic source PDOs, we need to ensure that we
are checking the incoming sink power request against the right set of
PDOs else we might reject a valid request (e.g. with high-power source,
we need to check against the 3.0A limit if we only have one port
connected).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=gru
BUG=chrome-os-partner:56110
TEST=Connect Kevin to Caroline, ask Caroline to charge from the other
side and see it negotiating successfully a 5V/3A contract.
Change-Id: Ie1aa5746776be5946422bf07c08ae0f22faddd8c
Reviewed-on: https://chromium-review.googlesource.com/403088
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The code clearly indends to sleep on the second time the loop
is taken, but the variable first_exchange is reset to 1 inside
the loop. If, for whatever reason, PD alert status cannot be
cleared, the code will then loop forever, and lead to a watchdog
reset.
BRANCH=none
BUG=chrome-os-partner:58750
TEST=Flash EC RO using ec_util
Run fwupdatetest with charger unplugged for 10 iterations.
Change-Id: I9e13f2523111853fdc5c45e75886c11f1c8006eb
Reviewed-on: https://chromium-review.googlesource.com/401238
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The lengths were previously specified as end offsets and were
thus off by 1.
Fortunately it seems these chips were never used with an EC where we
actually utilize this table. Still, it would be nice if we actually
tested this on real hardware to check that there aren't any other
silly errors.
BUG=none
BRANCH=none
TEST=needs testing
Signed off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I0a5315808c756797940436a10cd4f6df7313ab8c
Reviewed-on: https://chromium-review.googlesource.com/400642
Commit-Ready: Dan Shi <dshi@google.com>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Shifted pd_task debug level by 1 so that debug level 1 will
enable printing the pd state name.
Added a CONFIG flag to remove ability to change debug_level
during runtime and debug print level will be fixed.
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: I545813bafa8084355cedc2d8334c3aec5a2b6739
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/339935
Tested-by: Divya S Sasidharan <divya.s.sasidharan@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Don't call into tcpm_*() functions from HOOKs since these functions may
manipulate common sets of TCPC registers.
BUG=chrome-os-partner:57691
BRANCH=gru
TEST=On kevin, boot to S0, verify 5V is sourced to legacy peripheral.
Drop to G3, verify role is back to sink and charging is functional. Back
to S0, verify 5V is sourced.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9ade9de068589dce6995cda6b106217aa85aa793
Reviewed-on: https://chromium-review.googlesource.com/394809
(cherry picked from commit 18e9e3870722d57efd232bd7f0a0300003b46ad6)
Reviewed-on: https://chromium-review.googlesource.com/396137
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
To be able to identify different cr50 devices connected to the same
machine we need a serial number. This change uses dev id 0 and 1 to come
up with one.
BUG=chrome-os-partner:56641
BUG=chrome-os-partner:58342
BRANCH=none
TEST=lsusb -vd 18d1:5014 | grep iSerial shows different numbers for
different devices. Verify when ccd is disabled the serial number is 0.
Change-Id: I85c54af4a21bdfd0542019c02aa8420d9a879fae
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/395633
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
