Meaning for U1 & U2 exit latency in BOS descriptor

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
HuYa_4249091
Level 4
Level 4
25 replies posted 25 sign-ins 10 replies posted

Hi All:

I'm confused for that.

U1U2 Exit Latency.jpg

According to USB spec:

U1 U2 spec.jpg

Q1: If I set the U1 latency to 0x00, it means that the FX3 will resume from U1 to U0 by 0us?

Q2: If the FX3 needs 2us to resume from U1 to U0. And I set the U1 latency to 0x05. The actual time spent is 2us?

Q3: If the FX3 needs 3us to resume from U1 to U0. What happen if I set the U1 latency to 0x0?

Thanks a lot!

0 Likes
1 Solution
YashwantK_46
Moderator
Moderator
Moderator
100 solutions authored 50 solutions authored 50 likes received

Hello,

The U1 Device Exit Latency and U2 Device Exit Latency is used to tell the host that the host doesn't need to wait for the amount of time that is specified inorder for the device to react to the U1 -> U0 or U2 -> U0 link transitions request and actually recover to U0 state in the worst case scenario.

So, in case of interrupt endpoints, they need to be completed within the service interval and inorder for that to happen, the host sends transfer far enough ahead of time to compensate for the worst case link exit latency.

All of our SDK firmware examples have 0x00 for the U1 Device Exit Latency and U2 Device Exit Latency fields in the BOS descriptors and it is recommended to follow it.

So, to answer you questions:

1.) If U1 Device Exit Latency is set to 0x00, this means that when the host sends a request for the device to transition to U0 from U1, the host need not wait for any latency and can continue other operations.

2.) If FX3 needs 2uS to transition from U1 to U0 and you set latency as 5uS, the actual time the host would wait for is 5uS irrespective of whether or not the device has recovered or not and then continue with other operations.

3.) Once the host sends request to transition from U1 to U0 and latency set to 0x00, since the LFPS handshake timer expires, the downstream port on the host side goes into inactive state.

Regards,

Yashwant

View solution in original post

3 Replies
YashwantK_46
Moderator
Moderator
Moderator
100 solutions authored 50 solutions authored 50 likes received

Hello,

The U1 Device Exit Latency and U2 Device Exit Latency is used to tell the host that the host doesn't need to wait for the amount of time that is specified inorder for the device to react to the U1 -> U0 or U2 -> U0 link transitions request and actually recover to U0 state in the worst case scenario.

So, in case of interrupt endpoints, they need to be completed within the service interval and inorder for that to happen, the host sends transfer far enough ahead of time to compensate for the worst case link exit latency.

All of our SDK firmware examples have 0x00 for the U1 Device Exit Latency and U2 Device Exit Latency fields in the BOS descriptors and it is recommended to follow it.

So, to answer you questions:

1.) If U1 Device Exit Latency is set to 0x00, this means that when the host sends a request for the device to transition to U0 from U1, the host need not wait for any latency and can continue other operations.

2.) If FX3 needs 2uS to transition from U1 to U0 and you set latency as 5uS, the actual time the host would wait for is 5uS irrespective of whether or not the device has recovered or not and then continue with other operations.

3.) Once the host sends request to transition from U1 to U0 and latency set to 0x00, since the LFPS handshake timer expires, the downstream port on the host side goes into inactive state.

Regards,

Yashwant

Dear Yashwant:

Thanks for your detailed response!!

You mentioned "All of our SDK firmware examples have 0x00 for the U1 Device Exit Latency and U2 Device Exit Latency fields in the BOS descriptors and it is recommended to follow it.".

Does it mean that FX3 recovers from U1/U2 to U0 very fast, so we can set to 0x00?

Thank you!

0 Likes

Hello,

Does it mean that FX3 recovers from U1/U2 to U0 very fast, so we can set to 0x00?

->> We actually don't have any validated data for the transition time and hence are setting it to 0x00.

We haven't faced any issues as such as well with this setting and hence are using it as default.

You can try and use some non-zero values and see if you find any improvement or change in the behaviour on your side.


Regards,
Yashwant