xref: /aosp_15_r20/external/autotest/docs/faft-pd.md (revision 9c5db1993ded3edbeafc8092d69fe5de2ee02df7)
1# PD FAFT
2
3_Self-link: [go/faft-pd](https://goto.google.com/faft-pd)_
4
5PD FAFT is another set of firmware tests (FAFT), which targets testing USB-C,
6PD (Power Delivery) functionalities, and ULP (Ultra Low Power) mode.
7
8[TOC]
9
10## Overview {#overview}
11
12The USB-C and PD stack is complex that involves multiple hardware/firmware:
13
14*   TCPM (USB Type-C Port Manager),
15    [integrated in EC, using Chrome EC firmware](https://chromium.googlesource.com/chromiumos/platform/ec/+/main/docs/usb-c.md)
16*   TCPC (USB Type-C Port Controller), usually using proprietary firmware, in
17    the form of
18    *   dedicated chip, like ANX74xx, PS8xxx,
19    *   integrated in EC, like IT83xx, or
20    *   integrated in PMIC, like MT6370.
21
22The USB-C path also has other functions, like:
23
24*   DisplayPort, which shares the SuperSpeed lanes and the SBU channel;
25*   CCD, which shares the SBU channel and has special CC terminations.
26
27Many USB-C bugs are mysterious or flaky, like CCD not being detected, USB
28Ethernet connection being lost, or external monitors not showing up, etc. This
29kind of issue blocks BIOS/EC FAFT running. Some bugs may be even more serious
30that brick the hardware, negotiating a wrong voltage/current.
31
32PD FAFT was proposed to uncover any regression on the PD stack in an automated
33way.
34
35PD FAFT requires hardware to emulate the PD port partner, e.g. a PD-capable
36power adapter, a USB-C hub, a USB-C debug accessory, a USB-C protocol converter,
37a USB-C monitor, etc. The first version of PD FAFT uses
38[Plankton](https://www.chromium.org/chromium-os/plankton) as PDTester. The
39latest version uses
40[ServoV4](https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/main/docs/servo_v4.md)
41as PDTester.
42
43## Test details {#test-details}
44
45The PD FAFT tests are located in the Autotest tree as directories, usually with
46the prefix firmware\_PD.
47
48firmware\_PDConnect, checks:
49
50*   Ability to disconnect, then reconnect establishing a successful PD contract
51*   If PD Dual role mode is operational in the DUT
52
53firmware\_PDPowerSwap, checks:
54
55*   If the DUT advertises support for dualrole operation
56*   If the DUT can receive power swap requests
57*   If the DUT can initiate power swap requests
58
59firmware\_PDDataSwap, checks:
60
61*   If the DUT advertises support for data role swaps
62*   If the DUT can receive data swap requests
63*   If the DUT can initiate data swap requests
64
65firmware\_PDResetHard, checks:
66
67*   Ability of DUT to initiate hard resets
68*   Ability of DUT to receive hard resets
69*   If DUT is dualrole capable, hard resets are done with the DUT in each power
70    role
71
72firmware\_PDResetSoft, checks:
73
74*   Ability of DUT to initiate soft resets
75*   Ability of DUT to receive soft reset requests from Plankton
76*   If DUT is dualrole capable, soft resets are done with the DUT in each power
77    role
78
79firmware\_PDTrySrc, checks:
80
81*   If the DUT advertises support for dualrole and Try.SRC operation
82*   A series of disconnects/connects with Try.SRC on
83*   A series of disconnects/connects with Try.SRC off
84*   Try.SRC on the DUT connects in SRC mode
85
86firmware\_PDVbusRequest, checks:
87
88*   Ability to initiate a new PD contract with different VBUS value, according
89    to the attached charger capability, like 5V, 9V, 12V, 15V, 20V, etc.
90*   Receiving Source Capability messages from PDTester
91*   If PD Dual role mode is operational in the DUT
92
93firmware\_ECWakefromULP, checks:
94
95*   Ability to wake AP and EC from ULP mode by PB, LID.
96*   Ability to wake EC from ULP mode by AC.
97
98The above tests may have multiple subtests, the same test body but different
99prerequisite.
100
101.flip subtest, checks
102
103*   If DUT passes the same test on the flipped plug direction, which is
104    implemented by electrically flipping the CC signals on PDTester
105
106.dts subtest, checks
107
108*   If DUT passes the same test on a USB-C debug accessory
109*   No behavior difference between the normal scenarios and the CCD scenarios
110    (it is important as BIOS/EC FAFT uses the CCD setup)
111
112## How to run PD FAFT {#how-to-run-pd-faft}
113
114Hardware setup, check this
115[ServoV4 Type-C with servo micro setup](https://chromium.googlesource.com/chromiumos/third_party/autotest/+/refs/heads/main/docs/faft-how-to-run-doc.md#servov4-typec-micro).
116
117Software setup, check this
118[Running Tests instructions](https://chromium.googlesource.com/chromiumos/third_party/autotest/+/refs/heads/main/docs/faft-how-to-run-doc.md#faft-running-tests).
119
120## Known issues {#known-issues}
121
122### TCPMv2 {#tcpmv2}
123
124PD FAFT by far only supports testing DUT using TCPMv1. Porting to TCPMv2 is in
125progress.
126
127### Multiple USB-C ports {#multiple-usb-c-ports}
128
129Due to the hardware limitation, that PDTester (ServoV4) only supports testing
130one DUT-facing USB-C port at a time. If a DUT has two USB-C ports, you have to
131run PD FAFT twice -- once for each port under test.
132