arch/arm64/boot/dts/qcom/sm8150.dtsi | 4 ++++ arch/arm64/boot/dts/qcom/sm8250.dtsi | 4 ++++ arch/arm64/boot/dts/qcom/sm8350.dtsi | 4 ++++ arch/arm64/boot/dts/qcom/sm8450.dtsi | 2 ++ 4 files changed, 14 insertions(+)
Enabling U1 and U2 power-saving states can lead to stability and
performance issues, particularly for latency-sensitive or high-
throughput applications. These low-power link states are intended
to reduce power consumption by allowing the device to enter partial
low-power modes during idle periods. However, they can sometimes
result in unexpected behavior. Over the years, some of the issues
seen are as follows:
1. In device mode of operation, when UVC is active, enabling U1/U2
is sometimes causing packets drops due to delay in entry/exit of
intermittent low power states. These packet drops are often reflected
as Missed Isochronous transfers as the controller was not able to
send the packet in that microframe interval and hence glitches are
seen on the final transmitted video output.
2. On QCS6490-Rb3Gen2 Vision kit, ADB connection is heavily unstable
when U1/U2 is enabled. Often when link enters U2, there is a re-
enumeration seen and device is unusable for many use cases.
3. On QCS8300/QCS9100, it is observed that when Link enters U2, when
the cable is disconnected and reconnected to host PC in HS, there
is no link status change interrupt seen and the plug-in in HS doesn't
show up a bus reset and enumeration failure happens.
4. On older targets like SM8150/SM8250/SM8350, there have been
throughput issues seen during tethering use cases.
To avoid such issues, the USB team at Qualcomm added these quirks
to all targets in the past 4-5 years and extensive testing was done.
Although these are intermittent power states, disabling them didn't
cause any major increase in power numbers.
Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
---
If this is fine, the patch would be made into a series, disabling
U1/U2 for all mobile and QCS targets.
arch/arm64/boot/dts/qcom/sm8150.dtsi | 4 ++++
arch/arm64/boot/dts/qcom/sm8250.dtsi | 4 ++++
arch/arm64/boot/dts/qcom/sm8350.dtsi | 4 ++++
arch/arm64/boot/dts/qcom/sm8450.dtsi | 2 ++
4 files changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index cedae8d03a51..4dbda54b47a5 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -3658,6 +3658,8 @@ usb_1_dwc3: usb@a600000 {
iommus = <&apps_smmu 0x140 0>;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
+ snps,dis-u1-entry-quirk;
+ snps,dis-u2-entry-quirk;
phys = <&usb_1_hsphy>, <&usb_1_qmpphy QMP_USB43DP_USB3_PHY>;
phy-names = "usb2-phy", "usb3-phy";
@@ -3735,6 +3737,8 @@ usb_2_dwc3: usb@a800000 {
iommus = <&apps_smmu 0x160 0>;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
+ snps,dis-u1-entry-quirk;
+ snps,dis-u2-entry-quirk;
phys = <&usb_2_hsphy>, <&usb_2_qmpphy>;
phy-names = "usb2-phy", "usb3-phy";
};
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 48318ed1ce98..e40f3b21e37a 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -4207,6 +4207,8 @@ usb_1_dwc3: usb@a600000 {
iommus = <&apps_smmu 0x0 0x0>;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
+ snps,dis-u1-entry-quirk;
+ snps,dis-u2-entry-quirk;
phys = <&usb_1_hsphy>, <&usb_1_qmpphy QMP_USB43DP_USB3_PHY>;
phy-names = "usb2-phy", "usb3-phy";
@@ -4294,6 +4296,8 @@ usb_2_dwc3: usb@a800000 {
iommus = <&apps_smmu 0x20 0>;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
+ snps,dis-u1-entry-quirk;
+ snps,dis-u2-entry-quirk;
phys = <&usb_2_hsphy>, <&usb_2_qmpphy>;
phy-names = "usb2-phy", "usb3-phy";
};
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 877905dfd861..e8f9d8bab309 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -2409,6 +2409,8 @@ usb_1_dwc3: usb@a600000 {
iommus = <&apps_smmu 0x0 0x0>;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
+ snps,dis-u1-entry-quirk;
+ snps,dis-u2-entry-quirk;
phys = <&usb_1_hsphy>, <&usb_1_qmpphy QMP_USB43DP_USB3_PHY>;
phy-names = "usb2-phy", "usb3-phy";
@@ -2485,6 +2487,8 @@ usb_2_dwc3: usb@a800000 {
iommus = <&apps_smmu 0x20 0x0>;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
+ snps,dis-u1-entry-quirk;
+ snps,dis-u2-entry-quirk;
phys = <&usb_2_hsphy>, <&usb_2_qmpphy>;
phy-names = "usb2-phy", "usb3-phy";
};
diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index 53147aa6f7e4..331f223f47c3 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -4672,6 +4672,8 @@ usb_1_dwc3: usb@a600000 {
iommus = <&apps_smmu 0x0 0x0>;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
+ snps,dis-u1-entry-quirk;
+ snps,dis-u2-entry-quirk;
phys = <&usb_1_hsphy>, <&usb_1_qmpphy QMP_USB43DP_USB3_PHY>;
phy-names = "usb2-phy", "usb3-phy";
--
2.34.1On 7.11.2024 8:36 AM, Krishna Kurapati wrote: > Enabling U1 and U2 power-saving states can lead to stability and > performance issues, particularly for latency-sensitive or high- > throughput applications. These low-power link states are intended > to reduce power consumption by allowing the device to enter partial > low-power modes during idle periods. However, they can sometimes > result in unexpected behavior. Over the years, some of the issues > seen are as follows: > > 1. In device mode of operation, when UVC is active, enabling U1/U2 > is sometimes causing packets drops due to delay in entry/exit of > intermittent low power states. These packet drops are often reflected > as Missed Isochronous transfers as the controller was not able to > send the packet in that microframe interval and hence glitches are > seen on the final transmitted video output. > > 2. On QCS6490-Rb3Gen2 Vision kit, ADB connection is heavily unstable > when U1/U2 is enabled. Often when link enters U2, there is a re- > enumeration seen and device is unusable for many use cases. Would be nice to enable it on there too, then ;) Generally per-file commits are preferred to make potential reverts easier down the road Konrad
On 11/9/2024 2:22 AM, Konrad Dybcio wrote: > On 7.11.2024 8:36 AM, Krishna Kurapati wrote: >> Enabling U1 and U2 power-saving states can lead to stability and >> performance issues, particularly for latency-sensitive or high- >> throughput applications. These low-power link states are intended >> to reduce power consumption by allowing the device to enter partial >> low-power modes during idle periods. However, they can sometimes >> result in unexpected behavior. Over the years, some of the issues >> seen are as follows: >> >> 1. In device mode of operation, when UVC is active, enabling U1/U2 >> is sometimes causing packets drops due to delay in entry/exit of >> intermittent low power states. These packet drops are often reflected >> as Missed Isochronous transfers as the controller was not able to >> send the packet in that microframe interval and hence glitches are >> seen on the final transmitted video output. >> >> 2. On QCS6490-Rb3Gen2 Vision kit, ADB connection is heavily unstable >> when U1/U2 is enabled. Often when link enters U2, there is a re- >> enumeration seen and device is unusable for many use cases. > > Would be nice to enable it on there too, then ;) > > Generally per-file commits are preferred to make potential reverts > easier down the road > Hi Konrad, I agree with you. After the SoB and the "---", I added a paragraph mentioning that if this RFC patch looks fine, I will send a series and make this change for all SM and QCS targets. Let me know if the above commit text makes sense. Although I don't have all the debug details, I didn't want others in the community face the issues we faced and hence the patch. Regards, Krishna,
On Thu, Nov 07, 2024 at 01:06:50PM +0530, Krishna Kurapati wrote: > Enabling U1 and U2 power-saving states can lead to stability and > performance issues, particularly for latency-sensitive or high- > throughput applications. These low-power link states are intended > to reduce power consumption by allowing the device to enter partial > low-power modes during idle periods. However, they can sometimes > result in unexpected behavior. Over the years, some of the issues > seen are as follows: > > 1. In device mode of operation, when UVC is active, enabling U1/U2 > is sometimes causing packets drops due to delay in entry/exit of > intermittent low power states. These packet drops are often reflected > as Missed Isochronous transfers as the controller was not able to > send the packet in that microframe interval and hence glitches are > seen on the final transmitted video output. > > 2. On QCS6490-Rb3Gen2 Vision kit, ADB connection is heavily unstable > when U1/U2 is enabled. Often when link enters U2, there is a re- > enumeration seen and device is unusable for many use cases. > > 3. On QCS8300/QCS9100, it is observed that when Link enters U2, when > the cable is disconnected and reconnected to host PC in HS, there > is no link status change interrupt seen and the plug-in in HS doesn't > show up a bus reset and enumeration failure happens. > > 4. On older targets like SM8150/SM8250/SM8350, there have been > throughput issues seen during tethering use cases. > > To avoid such issues, the USB team at Qualcomm added these quirks > to all targets in the past 4-5 years and extensive testing was done. > Although these are intermittent power states, disabling them didn't > cause any major increase in power numbers. > > Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> > --- > If this is fine, the patch would be made into a series, disabling > U1/U2 for all mobile and QCS targets. > > arch/arm64/boot/dts/qcom/sm8150.dtsi | 4 ++++ > arch/arm64/boot/dts/qcom/sm8250.dtsi | 4 ++++ > arch/arm64/boot/dts/qcom/sm8350.dtsi | 4 ++++ > arch/arm64/boot/dts/qcom/sm8450.dtsi | 2 ++ Should the same set of quirks be applied to SAR2130P too? > 4 files changed, 14 insertions(+) > -- With best wishes Dmitry
On 11/7/2024 4:33 PM, Dmitry Baryshkov wrote: > On Thu, Nov 07, 2024 at 01:06:50PM +0530, Krishna Kurapati wrote: >> Enabling U1 and U2 power-saving states can lead to stability and >> performance issues, particularly for latency-sensitive or high- >> throughput applications. These low-power link states are intended >> to reduce power consumption by allowing the device to enter partial >> low-power modes during idle periods. However, they can sometimes >> result in unexpected behavior. Over the years, some of the issues >> seen are as follows: >> >> 1. In device mode of operation, when UVC is active, enabling U1/U2 >> is sometimes causing packets drops due to delay in entry/exit of >> intermittent low power states. These packet drops are often reflected >> as Missed Isochronous transfers as the controller was not able to >> send the packet in that microframe interval and hence glitches are >> seen on the final transmitted video output. >> >> 2. On QCS6490-Rb3Gen2 Vision kit, ADB connection is heavily unstable >> when U1/U2 is enabled. Often when link enters U2, there is a re- >> enumeration seen and device is unusable for many use cases. >> >> 3. On QCS8300/QCS9100, it is observed that when Link enters U2, when >> the cable is disconnected and reconnected to host PC in HS, there >> is no link status change interrupt seen and the plug-in in HS doesn't >> show up a bus reset and enumeration failure happens. >> >> 4. On older targets like SM8150/SM8250/SM8350, there have been >> throughput issues seen during tethering use cases. >> >> To avoid such issues, the USB team at Qualcomm added these quirks >> to all targets in the past 4-5 years and extensive testing was done. >> Although these are intermittent power states, disabling them didn't >> cause any major increase in power numbers. >> >> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> >> --- >> If this is fine, the patch would be made into a series, disabling >> U1/U2 for all mobile and QCS targets. >> >> arch/arm64/boot/dts/qcom/sm8150.dtsi | 4 ++++ >> arch/arm64/boot/dts/qcom/sm8250.dtsi | 4 ++++ >> arch/arm64/boot/dts/qcom/sm8350.dtsi | 4 ++++ >> arch/arm64/boot/dts/qcom/sm8450.dtsi | 2 ++ > > Should the same set of quirks be applied to SAR2130P too? Yes, these two quirks have been added to and tested on SAR2130 downstream. I see that you have added them in your upstream DTSI file too. Thanks for that. Regards, Krishna,
© 2016 - 2024 Red Hat, Inc.