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.
