1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
|
# EC Implementation of USB-C Power Delivery and Alternate Modes
USB-C PD requires a complex state machine as USB-C PD can operate in many
different modes. This includes but isn't limited to:
* Negotiated power contracts. Either side of the cable can source or sink
power up to 100W (if supported by device).
* Reversed cable mode. This requires a mux to switch the signals before
getting to the SoC (or AP).
* Debug accessory mode, e.g. [Case Closed Debugging (CCD)]
* Multiple uses for the 4 differential pair signals including
* USB SuperSpeed mode (up to 4 lanes for USB data)
* DisplayPort Alternate Mode (up to 4 lanes for DisplayPort data)
* Dock Mode (2 lanes for USB data, and 2 lanes for DisplayPort)
* Audio Accessory mode. (1 lane is used for L and R analog audio signal)
For a more complete list of USB-C Power Delivery features, see the
[USB-C PD spec][USB PD Spec Id].
This document covers various touch points to consider for USB-C PD and Alternate
Modes in the EC codebase.
[TOC]
## Glossary
* PD {#pd}
* Power Delivery. Protocol over USB-C connector that allows up to 100W of
power. Not supported on USB-A or USB-B connectors. A good overview of
USB PD is found in the [Introduction to USB Power Delivery] application
note.
* TCPC {#tcpc}
* Type-C Port Controller. Typically a separate IC connected through I2C,
sometimes embedded within the EC as a hardware sub module. The TCPC
interprets physical layer signals on CC lines and Vbus, and sends that
information to the TCPM to decide what action to take. In older designs,
there was a separate EC (running this codebase) that acted as the TCPC
that communicated with the main EC (also running this codebase), which
acted as the TCPM. More info in the official
[TCPC spec][USB TCPM Spec Id].
* TCPM {#tcpm}
* Type-C Port Manager. Manages the state of the USB-C connection. Makes
decisions about what state to transition to. This is the code running on
the EC itself.
* PE {#pe}
* Policy Engine. According to the [TypeC spec][USB TC Spec Id], the policy
engine is the state machine that decides how the USB-C connection
progresses through different states and which USB-C PD features are
available, such as Try.SRC
* TC {#tc}
* Type-C physical layer.
* PPC {#ppc}
* Power Path Controller. An optional, separate IC that isolates various
USB-C signals from each other and the rest of the board. This IC should
prevent shorts and over current/voltage scenarios for Vbus. Some PPCs
will protect signals other than Vbus as well.
* SSMUX {#ssmux}
* SuperSpeed Mux. This is typically the same IC as the TCPC; it enables
the mirrored orientation of the USB-C cable to go to the correct pins on
SoC. Also, allows the SuperSpeed signal to be used for different
purposes, such as USB data or DisplayPort.
* SVDM {#svdm}
* Structured Vendor Defined Messages are a class of [USB PD](#pd) messages
to enable non-power related communication between port partners. SVDMs
are used to negotiate and set the display port mode on a USB-C
connection.
* DRP {#drp}
* Dual Role Power Port. A USB-C port that can act as either a power Source
or power Sink.
* UFP {#ufp}
* Upstream Facing Port. The USB data role that is typical for a peripheral
(e.g. HID keyboard).
* DFP {#dfp}
* Downstream Facing Port. The USB Data role that is typical for a host
machine (e.g. device running ChromeOS).
* E-Mark {#emark}
* Electronically marked cable. A USB-C cable that contains an embedded
chip in the cable, used to identify the capabilities of the cable.
* VCONN {#vconn}
* Connector Voltage. A dedicated power supply rail for [E-Mark](#emark)
cables and other accessory functions (such as display dongles, and
docks). VCONN re-uses one of the CC1/CC2 signals to provide 5 volt, 1
watt, of power.
## Different PD stacks
Right now platform/ec has two different implementations of USB-C PD stack.
1. The older implementation is mainly contained within
[`usb_pd_protocol.c`](../common/usb_pd_protocol.c) and
[`usb_pd_policy.c`](../common/usb_pd_policy.c)
2. The newer implementation is found under [`common/usbc`](../common/usbc) and
is broken up into multiple different files and state machines
* Policy engine state machine files, `usb_pe_*_sm.c`.
* Protocol engine state machine file, `usb_prl_*_sm.c`.
* State machine framework file, `usb_sm.c`.
* Type-C physical layer state machine files, `usb_tc_*_sm.c`.
* USB-C PD Task file, `usbc_task.c`.
The older implementation supports firmware for device types other than
Chromebooks. For example, the older stack supports the Zinger, which is the
USB-C charging device that shipped with Samus, the Google Chromebook Pixel 2.
The Zinger implements the charger only side of the USB PD protocol.
To use the newer USB-C PD stack implementation, see
[TCPMv2 Overview](usb-tcpmv2.md).
## Implementation Considerations
In both older and newer implementations, the following details apply:
* For each USB-C port, there must be two tasks: `PD_C#` and `PD_INT_C#`, where
`#` is the port number starting from `0`.
* The `PD_C#` task runs the state machine (old or new) for the port and
communicates with the TCPC, MUX, and PPC. This task needs a large task
stack.
* The `PD_INT_C#` tasks run at a higher priority than the state machine
task, and its sole job is to receive interrupts from the TCPC as quickly
as possible then send appropriate messages to other tasks (including
`PD_C#`). This task shouldn't need much stack space, but the i2c
recovery code requires a decent amount of stack space so it ends up
needing a fair amount too.
* Saving PD state between EC jumps
* PD communication is disabled in locked RO images (normal state for
customer devices). When the jump from RO to RW happens relatively
quickly (e.g. there is not a long memory training step), then there
aren't many problems when RW takes over and negotiates higher PD
contracts.
* To support factory use cases that don't have a battery (and are
therefore unlocked), PD communication is enabled in unlocked RO. This
allows systems without software sync enabled to get a higher power
contract than 15W in RO.
* We save and restore PD state between RO -> RW and RW -> RO jump to allow
us to maintain a higher negotiated power through the full jump and
re-initialization process. For example, for each port we save the power
role, data role, and Vconn sourcing state in battery-backed or
non-volatile RAM. This allows the firmware image that is initializing to
restore an existing SNK contract (Chromebook as SNK) without cutting
power. We don't cut the power from the external supplier because we
issue a SoftReset (leaves Vbus intact) instead of a HardReset (drops
Vbus) in this contract resume case.
* Both use cases where we actually are able to restore the PD contract
require an unlocked RO (e.g. factory) otherwise RO cannot communicate
via PD and will drop the higher PD contract (by applying Rp/Rp on the CC
lines temporarily)
* The RO->RW use case is for an unlocked (e.g. factory) device that
negotiated power and we want to keep that contract after we jump to
RW in the normal software sync boot process. This is especially
useful when there is no battery and Vbus is our only power source.
* The RW->RO use case happens when we are performing auxiliary FW
upgrades during software sync and BIOS instructs the EC to jump back
to RO. We'll also try to maintain contracts over an EC reset when
unlocked.
## Configuration
There are many `CONFIG_*` options and driver structs that are needed in the
board.h and board.c implementation.
### TCPC Config
The `tcpc_config` array of `tcpc_config_t` structs defined in `board.c` (or
baseboard equivalent) should be defined for every board. The index in the
`tcpc_config` array corresponds to the USB-C port number. This struct should
point to the specific TCPC driver that corresponds to the TCPC that is being
used on that port. The i2c port and address for the TCPC are also specified
here.
### SSMUX Config
The `usb_muxes` array of `usb_mux` structs defined in `board.c` (or baseboard
equivalent) should be defined for every board. Normally the standard
`tcpci_tcpm_usb_mux_driver` driver works, especially if TCPC and MUX are the
same IC.
If the signal strength for the high-speed data lines needs to be tuned for a
specific hardware layout, the `board_init` field on the `usb_mux` is called
every time the mux is woken up from a low power state and should be used for
setting custom board tuning parameters.
### PPC Config
Some boards have an additional IC that sits between the physical USB-C connector
and the rest of the board. The PPC IC gates whether the Vbus line is an input or
output signal, based on i2c settings or gpio pins. A PPC also typically provides
over voltage and over current protection on multiple USB-C pins.
The `ppc_chips` array of `ppc_config_t` structs defined in `board.c` (or
baseboard equivalent) sets the appropriate driver and i2c port/address for the
PPC IC.
### Useful Config Options
Many USB-C policies and features are gated by various `CONFIG_*` options that
should be defined in `board.h` (or baseboard equivalent).
Most USB-C options will start with `CONFIG_USB_PD_` or `CONFIG_USBC_`. For their
full descriptions see [config.h][config header link]
## Interactions with other tasks
TODO(https://crbug.com/974302): mention `USB_CHG_P#` and `CHARGER`
## Upgrading FW for TCPCs
TODO(https://crbug.com/974302): Mention how this works even though it is in
depthcharge. Probing now. Need new driver in depthcharge
[Case Closed Debugging (CCD)]: https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/case_closed_debugging_cr50.md
[Introduction to USB Power Delivery]: https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en575003
[USB PD Spec Id]: https://www.usb.org/document-library/usb-power-delivery
[USB TC Spec Id]: https://www.usb.org/document-library/usb-type-cr-cable-and-connector-specification-revision-20-august-2019
[USB TCPM Spec Id]: https://www.usb.org/document-library/usb-type-ctm-port-controller-interface-specification
[config header link]: ../include/config.h
|
