| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Set initial data role of the PD based on the current power role.
- Initial data role for sink is UFP
- Initial data role for source is DFP
Reference: USB Type-C cable and connector specification, Release 2.0
2.3.3 Initial Power (Source-to-Sink) Detection and Establishing the
Data (Host-to-Device) Relationship
Once initial connection is established, the Source supplies VBUS and
behaves as a DFP, and the Sink consumes VBUS and behaves as a UFP.
USB PD, when supported by both ports, may then be used to independently
swap both the power and data roles of the ports.
BUG=b:151653348
BRANCH=none
TEST=make buildall -j
Change-Id: I69e01f5b98a656394d61ee6cf657ea63a570abd8
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2106944
Reviewed-by: Keith Short <keithshort@chromium.org>
Reviewed-by: Divya S Sasidharan <divya.s.sasidharan@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When chipset is or transitioning to a new state or on sysjump, the SOC
re-negotiates to enter an alternate mode on booting up.
Added a common function which enables exiting the current supported
alternate mode, to avoid NACK from the port partner on reentry.
BUG=b:151169925
BRANCH=None
TEST=Tested on Volteer:
1. On connecting a DP dongle, able to enter into DP alternate mode
on reboot.
2. On connecting a Thunderbolt dock, able to enter into
Thunderbolt-Compatible mode on reboot.
Change-Id: Ie7ad5cee5d746691ada3e103beadf7c67667a5a3
Signed-off-by: Ayushee <ayushee.shah@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2094780
Reviewed-by: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support pdcontrol in TCPMv2 in order to support TCPC firmware update.
BUG=chromium:1021417
TEST=ectool pdcontrol suspend, resume with charger attached
TEST=ectool pdcontrol suspend, resume with sink device attached
TEST=ectool pdcontrol reset (effectively suspend on Volteer), resume
TEST=ectool pdcontrol on (unsupported on Volteer)
TEST=ectool pdcontrol disable
TEST=Compare above to behavior on TCPMv1
BRANCH=none
Change-Id: I6a72ca708f499689e1d7e8bae6f5ca8a61f72c16
Signed-off-by: Abe Levkoy <alevkoy@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2057982
Commit-Queue: Keith Short <keithshort@chromium.org>
Reviewed-by: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"enum ec_current_image" is exposed in ec_commands.h (and used by non-EC
code, such as biod).
We also have an "enum system_image_copy_t" that is the exact same thing
(though has a few more definitions).
A followup CL (I714b6bd8c0d7192386404c25a831e38438fa5238) adds the
"sysinfo" host command, so we want to be able to expose all the
potential image variants. Rather than maintain two enums that can
potentially get out of sync, unify the code to use a single enum. We
choose to keep the "enum ec_current_image", since external code depends
on it.
To verify that this change results in no changes to the generated
binaries:
./util/compare_build.sh --board all
BRANCH=none
BUG=b:146447208
TEST=./util/compare_build.sh --board=all
Change-Id: I13776bc3fd6e6ad635980476a35571c52b1767ac
Signed-off-by: Tom Hughes <tomhughes@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2036599
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Namyoon Woo <namyoon@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In one case, TCPC was being a sink but a VCONN source in a previous
explicit contract. TCPC was still be a sink but not go on suppling
VCONN after rebooting EC.
Guarding the saved VCONN role and If TCPC was being sourcing VCONN
and as a sink source in previous explicit contract, TCPC should still
be the VCONN source.
BUG=b:150112192
TEST=Some dongles (PS176-01 and JCA374) can display after
rebooting EC with adapter.
BRANCH=kukui
Signed-off-by: Xiong Huang <xiong.huang@bitland.corp-partner.google.com>
Change-Id: Ia1e226d21e3a20411521b9ce6f19f749ac48bf51
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2071536
Reviewed-by: Eric Yilun Lin <yllin@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Xiong Huang <xiong.huang@bitland.corp-partner.google.com>
Commit-Queue: Xiong Huang <xiong.huang@bitland.corp-partner.google.com>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Xiong Huang <xiong.huang@bitland.corp-partner.google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The port is enabled when suspend is not enabled and vice versa. Avoid
confusing these idioms.
BUG=none
TEST=make buildall
BRANCH=none
Change-Id: I3063793334ac875afee8a176f96625e8903d2694
Signed-off-by: Abe Levkoy <alevkoy@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2057979
Reviewed-by: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=chromium:1021235
BRANCH=none
TEST=make buildall -j
Signed-off-by: Sam Hurst <shurst@google.com>
Change-Id: Ia243d5062c77d8f6b8299fbd131cabfdbcffb01e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2070452
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Commit-Queue: Sam Hurst <shurst@google.com>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:148528713
BRANCH=none
TEST=make buildall -j
Change-Id: Idf6908bfc3e79a960a7de6e4249c2f50b41b56e6
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2052645
Reviewed-by: Diana Z <dzigterman@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:148528713
BRANCH=none
TEST=make buildall -j
Change-Id: I5fb9bda868961008db858a46b7898b5c58cdd922
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2052647
Reviewed-by: Denis Brockus <dbrockus@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:148528713
BRANCH=none
TEST=make buildall -j
Change-Id: I79f75d23f6091a264c11b4da6cf0cea26205df60
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2052648
Reviewed-by: Denis Brockus <dbrockus@chromium.org>
Reviewed-by: Diana Z <dzigterman@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:148528713
BRANCH=none
TEST=make buildall -j
Change-Id: Ic965dd1622b6bc20fca6777d4c81f37661c6c886
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2052646
Reviewed-by: Diana Z <dzigterman@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TCPCIr2 had an issue with setting CC coming out of DRP
that if the polarity was not retained that the connection
dropped back to OPEN. Unfortunately this change broke
many of the other TCPCI implementations. I am working
on a different method of dealing with coming out of DRP
and this is no longer needed.
BUG=none
BRANCH=none
TEST=verify USB-C is working
Change-Id: Ifa8f26d417df2f5d5f41a23fbf7e6f9129031e94
Signed-off-by: Denis Brockus <dbrockus@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2056968
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't set the polarity behind the back of the PD stack.
Just clear the DRP and leave the CC lines so they look
just as we found them. This will allow TRY to work
and we will no go OPEN because we set the CC lines to
something that was not expected.
BUG=b:149415919
BRANCH=none
TEST=verify USB-C connections are working
Change-Id: I766514bd46922000ea8916d61d00265e7e5e4fd4
Signed-off-by: Denis Brockus <dbrockus@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2053461
Reviewed-by: Jett Rink <jettrink@chromium.org>
Commit-Queue: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:148528713
BRANCH=none
TEST=make buildall -j
Change-Id: Icb9dfe998df889e8e2d6de7776d9889295115708
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2052644
Reviewed-by: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:148528713
BRANCH=none
TEST=Manually tested on Volteer
1. When only one charger connected:
Able to negotiate to PD max.
2. When two chargers are connected (one on each port):
Non charging port is rejected
Swaps the charging port based on charger's priority
Change-Id: Ib7fdc5d31bf36189a85f8cd3217bec78f83a9efe
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2051318
Reviewed-by: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nct38xx needs to have the cached polarity set in order
to leave DRP mode without going back to an OPEN line.
Other TCPCI implementations break when this happens.
So moved it to a driver specific function instead
TODO(b/149415919): Consider trying to clear the DRP
mode instead of changing the polarity
BUG=b:149311437
BRANCH=none
TEST=verify charger functions on Trogdor
Change-Id: I5092a468d860b573a6e5acaf7c013b3425916efb
Signed-off-by: Denis Brockus <dbrockus@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2050336
Tested-by: Wai-Hong Tam <waihong@google.com>
Commit-Queue: Diana Z <dzigterman@chromium.org>
Reviewed-by: Diana Z <dzigterman@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
EFS v1 allowed Chromeboxes to verify RW without AP. EFS v2 will bring
the benefts to Chromebooks, which are:
- Reduce RO dependency and presence. Allow more code to be updated
in the fields.
- Remove jumptag and workarounds needed for late sysjump.
Major imporvements over v1 are:
- No A/B slot required.
- No signature in RW or public key in RO.
- Rollback-attack protection.
- Verifies only RW being used instead of whole RW section.
For battery-equipped devices, additional benefts are:
- Immediate boot on drained battery.
- Support recovery mode regardless of battery condition.
- Faster charge in S5/G3.
EC-Cr50 communication is based on the shared UART (go/ec-cr50-comm).
EFS2 is documented in go/ec-efs2.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=chromium:1045217,chromium:141143112
BRANCH=none
TEST=Boot Helios in NORMAL/NO_BOOT/NO_BOOT_RECOVERY/RECOVERY mode.
TEST=Wake up EC from hibernate.
TEST=Make EC assert PACKET_MODE to wake up Cr50 from deepsleep.
Change-Id: I98a4fe1ecc59d106810a75daec3c424f953ff880
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2015357
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Auto-Submit: Daisuke Nojiri <dnojiri@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Plug in type-c adapter in G3 power state. Because the
SLEEP_MASK_USB_PD won't be set before we receive the SRC_Cap
from SRC in SNK_Discovery state, but at waiting SRC_Cap this
period time we will enter deep sleep mode and turns pd module
clock off. This will cause TCPC miss the SRC_Cap message from
SRC, then our PD_T_SINK_WAIT_CAP timer timeout and tx hard reset.
So I add a configuration: SLEEP_MASK_USB_PD is set only by
it83xx driver, so that SLEEP_MASK_USB_PD value won't be overwritten
by set_state() function in usb_pd_prtocol.c. If one of the port TCPC
Rx is enabled, chip will not go to deep sleep, but chip can go to doze
mode that pd module clock won't be turned off only mcu core clock off.
if all ports are nothing plug-in, the chip can go to deep sleep.
BUG=none
BRANCH=none
TEST=TCPC doesn't miss any message from partner:
-in SNK_DISCOVERY and power G3 state on board ampton.
-in SRC_DISCOVERY and power S0 state on board it8xxx2_evb.
Change-Id: I9639523e2ca180809f0f74f24321d06e7b3a04c2
Signed-off-by: Ruibin Chang <ruibin.chang@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1990935
Tested-by: Ruibin Chang <Ruibin.Chang@ite.com.tw>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Commit-Queue: Ruibin Chang <Ruibin.Chang@ite.com.tw>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patchset enables checking and storaging the MessageId counter
received from the SOP'' messages.
Since SOP*(Cable) communication and SOP(Port Partner) have separate
MessageID counters, it is necessary to store separate messageIDs to
avoid the the incoming packets from getting dropped.
BUG=b:148481858
BRANCH=None
TEST=Tested on Volteer, able to maintain separate MessageId count for
SOP, SOP' and SOP'' communication.
Change-Id: Id3a29594c5f9b354ecb650c6d351b16883d2126b
Signed-off-by: Ayushee <ayushee.shah@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2032344
Reviewed-by: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For entering into Thunderbolt-Compatible mode with active
cable, the port sends Enter mode command for SOP', SOP''
(if the cable has a SOP'' controller) and SOP respectively.
If the port doesn't receive GoodCRC from Enter Mode SOP'',
the port resets the cable characteristic and exits the
Thunderbolt-Compatible mode discovery.
This CL enables SOP'' communication with the cable plug
and adds support to enter into Thunderbolt-compatible mode
with active cables.
BUG=b:140643923
BRANCH=None
TEST=Able to enter into Thunderbolt-Compatible mode for
active cables.
Change-Id: Iea0c652043933047e0158265c911775d4afe5758
Signed-off-by: Ayushee <ayushee.shah@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2001938
Reviewed-by: Diana Z <dzigterman@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patchset enables storage of MessageId counter received from the
cable plug.
Since SOP*(Cable) communication and SOP(Port Partner) have separate
MessageID counters, it is necessary to store separate messageIDs to
avoid the the incoming packets from getting dropped.
BUG=b:148481858
BRANCH=None
TEST=Tested on Volteer, able to maintain separate MessageId count for
SOP and SOP' communication.
Change-Id: Iac2dc616f99a9e19914588e59441df8b09068afa
Signed-off-by: Ayushee <ayushee.shah@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2026650
Reviewed-by: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
USB4 is based on the Thunderbolt 3 protocol specification. It
supports 40 Gbit/s throughput, is compatible with Thunderbolt 3,
and backwards compatible with USB 3.2, USB 2.0.
USB4.0 PD Flow:
Ref: USB Type-C Cable and Connector Specification 2.0
Figure 5-1 USB4 Discovery and Entry Flow Model
USB PD Explicit Contract
Discover ID SOP -------- USB4 compatible?
|
-------------yes------------|------No----- Exit USB4 Discovery
|
Discover ID SOP' --------- Product type
|
Passive cable----------|----Active Cable---USB4?
| |
| (Not implemented in this CL)
USB Signaling -----------------------
| | |
| USB4 with USB4 active cable Exit USB4
| Discovery
---------------------------------------------
| | | |
USB4 Gen3 USB3.2 Gen2 USB3.2 Gen1 USB2.0
| | | |
Enter USB4 with | Enter USB4 with Exit USB4 Discovery
USB4 Gen3 | USB4 Gen1
Passive cable | Passive cable
|
DFP Gen3 capable?
|
------yes---- |---------No--------
| |
Discover SVID SOP Enter USB4 with USB3.2 Gen2 Passive Cable
|
Discover SVID SOP'
|
Discover Mode SOP
|
Discover Mode SOP' --------Is TBT3?
|
-----yes----|-----No----
| |
Enter USB4 with TBT3 Enter USB4 with TBT
Gen3 passive cable Gen2 passive cable
BUG=b:140819518
BRANCH=None
TEST=With Gatkex creek 3 device, TGLRVP can enter to USB4.0 mode
Change-Id: Id861661c66c53a0a32679388bb7e2e81aae3ceb5
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Signed-off-by: Ayushee <ayushee.shah@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1926382
Reviewed-by: Diana Z <dzigterman@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the last message ID received was a 0, then executing "pd N soft"
on the EC shell would incorrectly mark the next message received as
a repeat message. This change resets the last received message ID
to the invalid value before executing the soft reset.
BUG=b:146811519
BRANCH=firmware-hatch-12672.B
TEST=Executing
"pd 0 swap power
pd 0 soft"
while connected as a SNK to a servo V4 no longer results in a loop
because the message was not marked as a repeat any more.
Change-Id: I754d1d3ed9f7a4a5163b0f3cd4bb844f47e0ccc7
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2028359
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Denis Brockus <dbrockus@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:142911453
BRANCH=none
TEST=make buildall -j
Change-Id: Iadb75b9b187a0444c445c2641ec71d592cf4ac92
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2013228
Reviewed-by: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When refusing a PR_Swap, DR_Swap, or VCONN_Swap the Reject control message
needs to be used rather than Not_supported.
BRANCH=None
BUG=b:64411727
TEST=tested with a PD 3.0 hub which always requests a DR_swap upon
connection. Previously, it would leave its cc line at NG upon receiving
the unexpected Not_supported response and it now leaves the line at OK.
Change-Id: Ifafbadece5c45e51f4100be5e3590c07fcb27346
Signed-off-by: Diana Z <dzigterman@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1250023
Commit-Queue: Keith Short <keithshort@chromium.org>
Tested-by: Keith Short <keithshort@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an explicit contract is in place for PD 3.0, the source shall
control the Rp value in order to facilitate collision avoidance. When
the value is set to 1.5 A, the sink can only respond to an existing AMS,
and not start a new one.
An Atomic Message Sequence (AMS) is defined as "a Message sequence that
starts and/or ends in either the PE_SRC_Ready, PE_SNK_Ready or
PE_CBL_Ready
states." This means any given PD message may be starting an AMS
(requiring the source to set Rp, and sink to check the CC level) or it
may be a response within an AMS (in which case, sink may send regardless
of CC levels).
This change adjusts the pd_transmit() calls to indicate whether any
given PD message is the beginning of an AMS. There are many AMS's
defined, which may be found in section 8.3.2 of the PD 3.0 spec.
Anytime the source returns to its ready state, it will reset Rp to
reflect that the sink may start an AMS.
Additionally, this removes the buffer for sending PD messages. If an
AMS cannot be started, then it's better to fail the send so the pd_task
state machine can handle the unsent message.
BRANCH=None
BUG=b:64411727, b:147476471
TEST=Tested with bip board with PD 3.0 config using 2 different PD 3.0
hubs. Monitored Twinkie output with hubs acting as source, sink, and
power swapping to source. Also turned off PD 3.0 to ensure PD 2.0
behavior with the hubs was unaffected.
TEST=Tested on volteer board with PD 3.0 config using Thunderbolt
capable dock.
Change-Id: Ib02670add1a125217a981a846e6e2c31681de169
Signed-off-by: Diana Z <dzigterman@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1246273
Tested-by: Keith Short <keithshort@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Commit-Queue: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:148114593
BRANCH=none
TEST=tested on Volteer, able to get correct TBT control flags
Change-Id: If673d4a194d3cc6b9579f0f32511c6363f2614f3
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2013825
Reviewed-by: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:145796172
BRANCH=none
TEST=make buildall -j
Change-Id: Ie4ffaf208745764262931501f0dff77b525a4e59
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2017569
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:142911453
BRANCH=none
TEST=make buildall -j
Change-Id: If9d902ef77da7d56a123c0c78b1ebbcd0d95bc3b
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2008301
Reviewed-by: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:142911453
BRANCH=none
TEST=make buildall -j
Change-Id: Id5cb4475a4bdf37947a6b1484441dadb7aa2d214
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2008300
Reviewed-by: Denis Brockus <dbrockus@chromium.org>
Reviewed-by: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:142911453
BRANCH=none
TEST=make buildall -j
Change-Id: Ia858db061811c58a14b2525d17d6abdc35ea6fa7
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2008299
Reviewed-by: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:142911453
BRANCH=none
TEST=make buildall -j
Change-Id: Ibcf7b23c9b4c166a59c00b4805d1fbad5e79e5f1
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2008298
Reviewed-by: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:142911453
BRANCH=none
TEST=make buildall -j
Change-Id: Ibdd840efd79dbba1e2836f990ec86515ae08c919
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2008297
Reviewed-by: Denis Brockus <dbrockus@chromium.org>
Reviewed-by: Diana Z <dzigterman@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before sending SOP' requests to cable plug, the port checks if
the port is the Vconn source. If the port isn't the Vconn source,
it can't talk to the cable.
From USB PD spec 1.3 sections 2.6.1 and 2.6.2, during an explicit
contract, after the data and power role swaps, if any, source/sink
can initiate or receive a request for exchanging the Vconn source.
Hence, adding support for the port to request Vconn swap, if it
hasn't already been swapped.
BUG=b:147209888
BRANCH=None
TEST=Checked on volteer, able to communicate with the cable plug
Change-Id: I36d896eda6319970b1a0a9bd7cc4efcbc381c8b1
Signed-off-by: Ayushee <ayushee.shah@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1988234
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Diana Z <dzigterman@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL fixes an issue where USB PD would not allow the max request
when there is currently no charge port. This was causing issues
following the jump to RW when the PD contract gets
reestablished. There is a race condition between the PD contract
negotiation and the charage manager being updated from the first 5V/3A
state. This race condition results in selection of the vSafe5V PDO and
this can cause problems with external adapters resulting in a hard
reset. Note that this problem only occurs when no battery is present
since otherwise there wouldn't have had a pd contract negotiated when
the EC is executing from RO.
BUG=b:145783611
BRANCH=firmware-hatch-12672.B
TEST=On Kohaku using the kohaku provided external adapter, verified
that kohaku can boot to the OS when SW sync is enabled and no battery
is present.
In addition, connected two kohaku chargers simultaneously (via power
strip on button) and verified that only one port negotiates VBUS at 20V.
Change-Id: I68b21f2a86634d4bae91a5b812f2a61b302b0ef3
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1993914
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Commit-Queue: Scott Collyer <scollyer@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:147249926, b:146623068
BRANCH=none
TEST=make buildall -j
Change-Id: Ibb24bdad4e9ec24b02106c05ca5fe51269efcb1c
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1990425
Reviewed-by: Denis Brockus <dbrockus@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ref: USB Type-C Cable and Connector Specification 2.0
F.2 TBT3 Discovery and Entry Flow
- Corrected the TBT3 Discovery flow
- Corrected the TBT3 Entry Flow
- Enabled the Active cable TBT3 mode entry
- Refactored TBT & Cable VDO code on TCPMv1 so that same VDO
structures can be used for TCPMv2
- Corrected getting the cable version
- Cleaned up the code for super speed cable detection
BUG=b:146006708, b:140643923, b:147134610
BRANCH=none
TEST=Make buildall -j
Able to detect Thunderbolt-compatible devices on TGLRVP
Change-Id: I65f82e241d0cc2187050913e7d16942fdaa0ebd4
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1981276
Reviewed-by: Diana Z <dzigterman@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the second half of b/147290482
Cleaning up to use pd_data_role instead of int
BUG=b:147314832
BRANCH=none
TEST=make buildall -j
Change-Id: I2445b06f5f5469fb1f3a968034a83e3ee792e7c7
Signed-off-by: Denis Brockus <dbrockus@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1991845
Reviewed-by: Jett Rink <jettrink@chromium.org>
Reviewed-by: Edward Hill <ecgh@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pd_get_role in the TCPMv1 stack meant pd_get_power_role.
pd_get_role in the TCPMv2 stack meant pd_get_data_role.
This CL will clean that up and make them the correct naming.
pd_get_power_role will also return an enum pd_power_role
type instead of an int.
BUG=b:147290482
BRANCH=none
TEST=make buildall -j
Change-Id: I73ee465401ccd050c2bd151f2fc043a59d95e079
Signed-off-by: Denis Brockus <dbrockus@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1991844
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the partner device is source and it is not capable
of USB communication then set the USB MUX as none.
BUG=b:146545195
BRANCH=none
TEST=Tested on Volteer, USB MUX is not set for Zinger,
USB devices are detected over Type-C ports
Change-Id: Ic06f919a56c21cb7e832446e6a3c26eb24afcebf
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1977194
Reviewed-by: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the NCT38XX driver code was more generic TCPCI
than specific to the chip. So moved a number of the
functions over to be generically handled.
In doing this I propagated the idea of tri-state
polarity. It is now either NORMAL, FLIPPED, or NONE
for unattached. This is needed for the generic handling
of correctly setting CC. This required changing the
polarity from NONE to the appropriate detected polarity
when in auto toggle.
tcpci_tcpm_set_cc will now only set a single CC line
when attached and both when unattached.
BUG=b:146003980, chromium:951681
BRANCH=none
TEST=Charging works with both plug orientations with AP on
TEST=Device works with both plug orientations with AP on
TEST=Charging works with both plug orientations with AP off
Change-Id: Ie4b5cc998902a346a4f4a2c1480204b3a81017dd
Signed-off-by: Denis Brockus <dbrockus@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1967932
Commit-Queue: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently tcpc reset always let usb pd state machine goes back to
PD_DEFAULT_STATE, which is SNK_DISCONNECTED if USB_PD_DUAL_ROLE enabled,
and stay at sink even if PD_DRP_FORCE_SOURCE flag turned on.
We should follow the drp_state setting after reset.
BUG=b:138803492
TEST=test_that --fast --board=kukui $DUT_IP firmware_PDConnect \
firmware_PDTrySrc firmware_PDDataSwap
BRANCH=none
Change-Id: I2ef59214fc63f253488789f1dc820576497e20ad
Signed-off-by: Ting Shen <phoenixshen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1873859
Reviewed-by: Eric Yilun Lin <yllin@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Commit-Queue: Ting Shen <phoenixshen@chromium.org>
Tested-by: Ting Shen <phoenixshen@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are a number of potential callers that care if there is a battery,
but for boards that don't support batteries (chromeboxes) we can let
them skip implementing this stub.
Tests default to battery present, but they can provide their own
per-test implementation if desired.
Some PD battery presence checks have been disabled when battery support
is disabled; these are irrelevant when there is no battery, and they
cause linking failures because they depend on both the charge manager
and battery presence.
BUG=b:146504182
BRANCH=none
TEST=buildall
Change-Id: Ifad6a9e356c8ac2146b09bc83b359a7c55adc1a7
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1980099
Reviewed-by: Scott Collyer <scollyer@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Setting the RDO flags correctly for communication capable PD devices.
Ref: USB Power Delivery Specification
(Revision 3.0, Version 2.0 / Revision 2.0, Version 1.3)
6.4.2.4 USB Communications Capable
6.4.2.5 No USB Suspend
If the port partner is capable of USB communication set the
USB Communications Capable flag.
If the port partner is sink device do not suspend USB as the
power can be used for charging.
BUG=b:147134608
BRANCH=none
TEST=TBT3 devices can enter into Thunderbolt-compatible mode
Change-Id: If9010a4f6b1770415d386e03657e689c465bbaae
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1986883
Reviewed-by: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CL:1565147 introduced a new clause to the SNK_DISCOVERY state to
prevent reset timers from starting when a battery is reporting below a
configured level, which indicates the point at which the battery is
capable of withstanding the potential loss of Vbus.
There is an another case of having good battery level but battery can't
discharge due to the DFET status of fuel gauge so we need to consider it
as well.
BUG=b:146758440
BRANCH=octopus
TEST=Verify on the DUT with bad battery which can report battery level
correctly but DFET is disabled and can't be revived.
Change-Id: Ia3f3d26625a054f631fdddc74065f2e829852989
Signed-off-by: Marco Chen <marcochen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1980406
Reviewed-by: Diana Z <dzigterman@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sending the following information to the host in cros_ec_usb_pd_control
command to configure thunderbolt compat mode:
1. TBT flag - Contains information about:
a. Retimer (Present/Absent)
b. Thunderbolt-compatible adapter (Type-C/ Legacy TBT adapter)
c. Thunderbolt-compatible type (Optical/Non-optical)
d. Active link training (Uni/bi-directional communication)
2. Cable speed (USB3.1 Gen1 Cable / 10 Gbps / 10 Gbps and 20 Gbps)
3. Cable rounded support (3rd Gen Non-Rounded TBT/
3rd & 4th Gen Rounded and Non-Rounded TBT)
BUG=b:140644242
BRANCH=None
TEST=Verfied on the tglrvp-u CPU console using "ectool usbpd" command,
able to get the information
Change-Id: I38cf0b488945d78564c96eedab50a6e2900dfb80
Signed-off-by: Ayushee <ayushee.shah@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1926381
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Reviewed-by: Keith Short <keithshort@chromium.org>
Commit-Queue: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thunderbolt is a hardware interface that allows connection of external
peripherals to a computer. This code enables thunderbolt 3 over Type-C
interface. Thunderbolt provides concurrent support for PCIe transactions
and DisplayPort and the thunderbolt controller provides isochronous
communication on a single network style interface, allowing a Host
computer to communicate at high bandwidth with multiple data/display
devices through a single physical connection.
The USB Type-C specification allows for Alternate Modes to be supported
on the connector and cables. This CL adds a Discovery flow to determine
if an Thunderbolt Alternate Mode is supported and a mechanism for
switching in thunderbolt mode.
TBT USB PD flow:
-------------------Explicit contact---------------------
Discover Identity(SOP) ---- Modal operation supported?
|
---------- ACK -----|---- NACK --- Disable TBT
|
Discover Identity(SOP') --- Check and store response
(CL:1707851 and CL:1553898)
|
Is cable super speed?
-------- Yes -------|----- No ---- Disable TBT
|
Discover SVID (SOP) -------- SVID == 0x8087?
|
------------- Yes -----|------ No ---- Disable TBT
|
Discover SVID (SOP') -------- SVID == 0x8087?
|
----------- yes------- | - No - Limit TBT to passive Gen 2
|
Discover Mode (SOP) ------ Store device response
---------------|
|
Discover Mode (SOP') ----- Store cable response
|
Enter Safe mode
|
Active cable?
--------- Yes -----|-------- No ---------
| |
Enter TBT mode (SOP' SOP" SOP) Enter TBT mode SOP
(Note: This is not implemented in this CL)
BUG=b:140643923
BRANCH=none
TEST=Tested on Tglrvp-u able to enter into Thunderbolt-compatible mode &
Non Thunderbolt-compatible devices are detected as per their spec.
Change-Id: I65ed86e9f32d36fe8e30c3285f516b9871f3e119
Signed-off-by: Ayushee <ayushee.shah@intel.com>
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1926379
Reviewed-by: Diana Z <dzigterman@chromium.org>
Commit-Queue: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was changed in PD 2.0 years ago (via ECN authored by our own David
Schneider), but our codebase still refers to BIT 27 of the Fixed PDO as
"Externally powered" instead of "Unconstrained Power".
This will search and replace all instances of "Externally powered" when it
refers to BIT 27, as well as function names, other internal representations
of that property, strings, and comments.
seds:
s/PD_FLAGS_PARTNER_EXTPOWER/PD_FLAGS_PARTNER_UNCONSTR/g
s/partner_extpower/partner_unconstrained/g
s/externally powered/unconstrained/g
Some others too.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chromium:1030990
TEST=Codebase builds clean. No functional change, except for the property shows
up in ectool as "Unconstrained power" now.
Change-Id: I5ececa03f29eb31057be3d0ad5311117093bc6da
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1956147
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Commit-Queue: Benson Leung <bleung@google.com>
Tested-by: Benson Leung <bleung@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was originally thought the connect/disconnect would be
a good generic way to set/clear auto_discharge_disconnect
but it was not working reliably. Although the points that
we are calling to perform this enable/disable are close to
the connect/disconnect, there is more fine tuning required
to make this work.
BUG=b:144126745,chromium:951683
BRANCH=none
TEST=attach/disconnect charger with and without AP running
TEST=attach/disconnect device with AP running
Change-Id: Ib1418771aec6d0a52895972e4db6881b072c0c3d
Signed-off-by: Denis Brockus <dbrockus@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1960514
Reviewed-by: Edward Hill <ecgh@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the new changes in CL:1949052 getting DP pin mode status
is removed hence adding back old CL:1646534 on TOT.
BUG=b:146006717
BRANCH=none
TEST=Manually tested on TGLRVP, able to see DP working
Change-Id: I09cee179ad64c1b7753ec87ce83a1d5dc54770cd
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1961150
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
|