General

This is a crude summary of the key issues related to entering the U1, U2 or U3 low-power states on a
SuperSpeed USB link. It’s by no means a replacement for reading the USB 3.0 spec, but rather an
attempt to clarify its underlying concepts.

A similar discussion on waking up from these low-power states can be found on this page. There is
also a page with an broader view of power states.

The handshake in brief

To enter a low power state, either port of a link sends one of the LGO_U1, LGO_U2 or LGU_U3 Link
Layer command, each requesting the respective low power state U1, U2 or U3. Within 3 μs
(PM_LC_TIMER), the link partner must respond with either an LAU Link Layer command for confirming
the request , or with an LXU to reject it (rejection is disallowed in some cases however).

If the requesting port receives an LXU packet, both ports remain in the active U0 state, as if no
request was sent. If an LAU packet is received, the requesting port sends an LPMA Link Layer packet
and enters the relevant power state after that.

The LPMA packet is not necessary for entering the low power state, but saves a few microseconds of
staying in U0 on the port that sent the LAU packet, as explained below.

So all in all, it’s a three-way handshake: LGO_Ux, LAU and LPMA. The state transition is aborted if any
of the first two are lost, and just slightly delayed if the third is lost.

Note that a device is allowed to request a low-power state only an explicit SET_FEATURE control
command, enabling the device’s capability to request U1 and/or U2 (these have separate feature
flags, U1_ENABLE and U2_ENABLE). By default, these features are disabled per spec, but the common
practice is to enable them when a device is enumerated. Note that when these feature flags are
enabled, the device is permitted, and not required, to initiate requests for U1 and/or U2.

The power state is local between link partners. For example, if a device is connected to a computer
through a USB splitter hub, the link between the splitter and the device may (and often will) enter a
low power state even if the link between the splitter and the computer is fully up. The link between
the splitter and computer is allowed to enter a low power state only if all of its downstream ports are
in a low power state.

How it works
The state transition handshake ensures that both sides either enter the low power state, or both sides
remain in U0 (possibly with a detour into Recovery in the middle). This is backed up by the following
important rule: A port that receives TS1 ordered sets, indicating that the other side has entered
Recovery, also enters Recovery, and aborts the low-power handshake.

Consider the port that receives an LGO_Ux command. If it rejects it with an LXU, it remains in U0. If it
accepts it with an LAU, it automatically enters the requested power state after 6 μs
(PM_ENTRY_TIMER), or immediately upon receiving an LPMA command — the sooner of the two.

Now to the sender of the LGO_Ux command: After sending this command, it waits for the LXU or LAU
response for up to 3 μs (PM_LC_TIMER). If it doesn’t arrive until then, it enters the Recovery state.
The opposite site is guaranteed to still be in U0 (as it transitions state automatically only after 6 μs),
so it follows suit into Recovery, and the handshake is aborted, both ports ending up in U0.

So if either the LGO_Ux or the LAU/LXU commands were lost, the link will eventually go into Recovery,
and eventually stay in U0. No place for confusion.
If an LXU arrived in time, neither side change state. If an LAU arrived in time, its receiver (i.e. the
sender of LGO_Ux) sends an LPMA command just before entering the low-power state. All it does is
that the opposite side enters the low-power state immediately, and not a few microseconds later.
Even if this link command is lost, both sides will still end up in the correct low-power state.

While waiting for the LPMA, the port that sent the LAU shall not respond to a LFPS signal attempting to
bring it back into U0, but rather complete the powerdown cycle, and then respond to the wakeup
request (USB 3.0 spec, section 7.2.4.2.3, also note that PM_ENTRY_TIMER is disabled when LPMA
arrives per section 7.2.4.2.1). Not something expected to happen often, but the spec closes this
corner as well.

Note that both PM_LC_TIMER and PM_ENTRY_TIMER have larger values in USB 3.1 and USB 3.2
(Table 7-8 in those specs).

Silence during the handshake

Neither side transmits any packets after sending LGO_Ux or LAU. This holds until an LXU is received
(hence returning to U0 as if nothing happened) or when resuming to U0 after a wakeup from the low-
power state and Recovery. Transmission of Link Commands (LPMA in particular) is allowed by the side
that issued LGO_Ux.

Note that when a port receives an LGO_Ux, packets may be in transmission in the opposite direction.
The spec requires that the sender of LGO_U1/LGO_U2 continues to process arriving packets, after
sending this link command, but to ignore them after sending LGO_U3. “Processing packets” probably
includes acknowledging them with LGOOD_n link commands, which it’s allowed to send.

The rationale is that the LGO_U1/LGO_U2 requests may be rejected, in which case the show must go
on as usual. LGO_U3 must be accepted so no point going on. Ignoring packets this way doesn’t cause
a packets loss, as the Recovery state facilitates a handshake for retransmission of lost Header
Packets.

The spec says nothing about whether the receiver of LGO_Ux should continue to process arriving
packets, as such packets shouldn’t arrive.

When both sides send LGO_Ux at the same

time
Section 7.2.4.2.5 in the USB 3.0 spec details the mandatory behavior of both sides having sent
LGO_Ux commands at the same time (or more precisely, before receiving the other side’s LGO_Ux).
Being short and concise, it’s recommended reading for whoever intends to develop a USB 3.0 device,
and considers whether it should initiate low-power transitions.

The governing principle is that in this kind of negotiation between a hub and a device, the hub refuses
the device’s request with an LXU, and the device waits for the hub’s LXU, and then sends its response
(LXU or LAU). This makes the device’s design slightly more complicated, as it needs to remember the
last LGO_Ux request, rather than always responding to it immediately.

This sections also states something almost obvious: If the ports are in the middle of transition into U1
or U2, and a U3 is requested, then the transition into U1 and U2 is completed, a wakeup takes place,
and then the transition into U3 takes place.

When LXUs are allowed (or: the right to

refuse)
LGO_U3 cannot be refused, plain and simple. When a device is required to suspend itself, it can’t say
no.
As for LGO_U1/LGO_U2, LXU is allowed without limitation. Even though the spec suggests conditions
for accepting a low-power state, a refusal is allowed indefinitely for no reason at all.

An exception is when the Force_LinkPM_Accept feature has been set by virtue of a Set Link Function
Link Management Packet (which is a subclass of Header Packets). If this feature is set, an LXU is not
allowed for any LGO_Ux, and neither is the receiver of this command allowed to initiate a wakeup
handshake.

If an LPMA / LXU / LAU arrive out of the blue

These link commands are supposed to arrive inside a handshake session. However if such commands
are received out of this scope, section 7.3.10 states that the behavior is undefined and
implementation specific. The recommendation given is however to ignore them (and hence not switch
to Recovery).

Transition from U1 to U2
All low-power states are invoked directly from U0, except, possibly, a transition from U1 to U2. This
transition occurs, automatically and individually for each port, after a certain time in U1. The intention
is that both sides make this transition at the same time so they’re always in the same state. However
there might be slight differences between the port’s clock source, so the ports enter the U1 state with
a slight time difference. Hence there’s always a short time period in which one port is in U1 and the
second in U2. The wakeup handshake is specified to handle a wakeup during this period gracefully.

In common practice, the U1 to U2 transition mechanism is enabled, or both U1 and U2 are disabled.

The specified mechanism is that the host tells each hub in the hierarchy what inactivity timeouts to
apply for entering U1 and U2, and the devices connected directly to it make sure to transition from U1
to U2 at the same time (if at all). So for the purpose of designing a USB 3.0 device, the understanding
of the hub’s low-power behavior is required to ensure that the device follows suit.

Note that a computer’s USB port controller is a hub for all purposes.

Sections 10.4.2.1 and 10.14.2.10 in the USB 3.0 (both related to hubs) spec covers the meaning of
PORT_U1_TIMEOUT and PORT_U2_TIMEOUT, which determine the hub’s behavior regarding
transitions into U1 and/or U2 in response to lack of activity. The host sets these parameters by virtue
of a Set Port Feature control command going to the hub (selecting PORT_U1_TIMEOUT or
PORT_U2_TIMEOUT as the feature to set). Each of these two parameters consist of a word of 8 bits,
treated as an unsigned number. From the perspective of a device connected to the hub, only the latter
matters, as explained further below.

Both parameters have a special meaning when set to either 0x00 or 0xff.

 0x00 means completely disabled: The hub won’t enter the respective low power state,
and shall reject the device’s requests with an LXU.
 0xff means infinite timeout: The hub won’t attempt to enter the respective low power
state (infinite timeout), but shall accept requests from the device.
All other values (0x01-0xfe) mean that the hub shall attempt entering the respective low power state
after a time that is this value multiplied with a constant (1 μs for U1 and 256 μs for U2). The timeout
relates to the time spent in the previous state (and not necessarily since U0).

From a perspective of a device, PORT_U1_TIMEOUT doesn’t matter: If it’s disabled completely, the
hub responds with LXUs to any initiations of U1 from the device. If the timeout is enabled, the device
will get an LGO_U1 when the time comes, or never if the timeout is disabled. The only thing a device
needs to know is how long it takes before the hub moves automatically from U1 to U2. That is given
by PORT_U2_TIMEOUT.
This parameter is mediated to the devices directly connected to a hub by virtue of U2 Inactivity
Timeout Link Management Packet (non-root hubs’ upstream ports are devices for this purpose).

The device’s interpretation is as follows: If PORT_U2_TIMEOUT is 0x00 or 0xff, never transition from
U1 to U2. Otherwise, start a timer when entering U1 (regardless of which side initiates this) and move
to U2 after PORT_U2_TIMEOUT multiplied with 256 μs. The reason 0x00 and 0xff are excluded is that
in neither cases will the hub enter U2: The former means that the state is completely disabled, and
0xff means infinite timeout.

Typical values on a Linux machine (even when connected through hub splitters) are
PORT_U1_TIMEOUT = 50 (i.e. 50 μs) and PORT_U2_TIMEOUT = 40 (i.e. 10240 μs, that is ~ 10 ms).
For a non-root hub (i.e. a USB splitter), it’s typically 30 for U1, 63 for U2.

The accuracy of the timers: The timer for PORT_U1_TIMEOUT may expire up to 1 μs too late, the
timer for PORT_U2_TIMEOUT may expire 500 μs too late (section 10.4.1 in the USB 3.0 spec).

As a side note, a hub can be programmed to skip U1 and timeout directly into U2. This doesn’t matter
so much from the device’s point of view, because the timeout mechanism will never kick in as the
device is never put in U1. Just don’t make the mistake of thinking that if PORT_U2_TIMEOUT is set to
something else than 0x00 or 0xff, it necessarily means that the U1 to U2 mechanism is being used.