mbox series

[v3,00/19] Disable USB U1/U2 entry for QC targets

Message ID 20241218102707.76272-1-quic_prashk@quicinc.com (mailing list archive)
Headers show
Series Disable USB U1/U2 entry for QC targets | expand

Message

Prashanth K Dec. 18, 2024, 10:26 a.m. UTC 
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.

5. On targets like SDX75, intermittent disconnects were observed
with certain cables due to impedence variations.

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.

This series was earlier started by Krishna Kurapati where he disabled
U1/U2 on some SM targets. I'm extending this to more devices including
Auto, Compute and IOT platforms. On a side note, this quirk has been
already included on some mobile targets like SM8550/8650.

Changes in v2:
- Removed the wrongly added quirks from tcsr_mutex node.
- Link to v2: https://lore.kernel.org/all/20241213095237.1409174-1-quic_prashk@quicinc.com/

Link to RFC:
https://lore.kernel.org/all/20241107073650.13473-1-quic_kriskura@quicinc.com/#Z31arch:arm64:boot:dts:qcom:sm8250.dtsi

Krishna Kurapati (8):
  arm64: dts: qcom: Disable USB U1/U2 entry for SM8350
  arm64: dts: qcom: Disable USB U1/U2 entry for SM8450
  arm64: dts: qcom: Disable USB U1/U2 entry for SM8150
  arm64: dts: qcom: Disable USB U1/U2 entry for SM6125
  arm64: dts: qcom: Disable USB U1/U2 entry for SM8250
  arm64: dts: qcom: Disable USB U1/U2 entry for SM6350
  arm64: dts: qcom: Disable USB U1/U2 entry for SC7280
  arm64: dts: qcom: Disable USB U1/U2 entry for SA8775P

Prashanth K (11):
  arm64: dts: qcom: Disable USB U1/U2 entry for SDM630
  arm64: dts: qcom: Disable USB U1/U2 entry for SDM845
  arm64: dts: qcom: Disable USB U1/U2 entry for SDX75
  ARM: dts: qcom: Disable USB U1/U2 entry for SDX65
  ARM: dts: qcom: Disable USB U1/U2 entry for SDX55
  arm64: dts: qcom: Disable USB U1/U2 entry for QCS404
  arm64: dts: qcom: Disable USB U1/U2 entry for SC7180
  arm64: dts: qcom: Disable USB U1/U2 entry for X1E80100
  arm64: dts: qcom: Disable USB U1/U2 entry for QDU1000
  arm64: dts: qcom: Disable USB U1/U2 entry for SC8280XP
  arm64: dts: qcom: Disable USB U1/U2 entry for SC8180X

 arch/arm/boot/dts/qcom/qcom-sdx55.dtsi |  2 ++
 arch/arm/boot/dts/qcom/qcom-sdx65.dtsi |  2 ++
 arch/arm64/boot/dts/qcom/qcs404.dtsi   |  4 ++++
 arch/arm64/boot/dts/qcom/qdu1000.dtsi  |  2 ++
 arch/arm64/boot/dts/qcom/sa8775p.dtsi  |  6 ++++++
 arch/arm64/boot/dts/qcom/sc7180.dtsi   |  2 ++
 arch/arm64/boot/dts/qcom/sc7280.dtsi   |  4 ++++
 arch/arm64/boot/dts/qcom/sc8180x.dtsi  |  6 ++++++
 arch/arm64/boot/dts/qcom/sc8280xp.dtsi |  6 ++++++
 arch/arm64/boot/dts/qcom/sdm630.dtsi   |  4 ++++
 arch/arm64/boot/dts/qcom/sdm845.dtsi   |  4 ++++
 arch/arm64/boot/dts/qcom/sdx75.dtsi    |  2 ++
 arch/arm64/boot/dts/qcom/sm6125.dtsi   |  2 ++
 arch/arm64/boot/dts/qcom/sm6350.dtsi   |  2 ++
 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 ++
 arch/arm64/boot/dts/qcom/x1e80100.dtsi | 10 ++++++++++
 19 files changed, 72 insertions(+)

Comments

Dmitry Baryshkov Dec. 18, 2024, 11:27 a.m. UTC | #1 
On Wed, Dec 18, 2024 at 03:56:48PM +0530, Prashanth K 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:
> 

[..]

> 
> This series was earlier started by Krishna Kurapati where he disabled
> U1/U2 on some SM targets. I'm extending this to more devices including
> Auto, Compute and IOT platforms. On a side note, this quirk has been
> already included on some mobile targets like SM8550/8650.

Why are you resending previous patches rather than adding another series
on top of it?

> 
> Changes in v2:
> - Removed the wrongly added quirks from tcsr_mutex node.
> - Link to v2: https://lore.kernel.org/all/20241213095237.1409174-1-quic_prashk@quicinc.com/

What was changed in v3?

> 
> Link to RFC:
> https://lore.kernel.org/all/20241107073650.13473-1-quic_kriskura@quicinc.com/#Z31arch:arm64:boot:dts:qcom:sm8250.dtsi
>
Prashanth K Dec. 18, 2024, 11:48 a.m. UTC | #2 
On 18-12-24 04:57 pm, Dmitry Baryshkov wrote:
> On Wed, Dec 18, 2024 at 03:56:48PM +0530, Prashanth K 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:
>>
> 
> [..]
> 
>>
>> This series was earlier started by Krishna Kurapati where he disabled
>> U1/U2 on some SM targets. I'm extending this to more devices including
>> Auto, Compute and IOT platforms. On a side note, this quirk has been
>> already included on some mobile targets like SM8550/8650.
> 
> Why are you resending previous patches rather than adding another series
> on top of it?
> 
Hi Dmitry,

RFC had only one patch with quirks (to disable u1/u2) only for few
targets (SM8150, 8250, 8350, 8450). It was later decided to split it
into per-file commits as per the review comments. Hence I clubbed
Krishna's changes along with few more targets. Let me know if this needs
to be changed.

>>
>> Changes in v2:
>> - Removed the wrongly added quirks from tcsr_mutex node.
>> - Link to v2: https://lore.kernel.org/all/20241213095237.1409174-1-quic_prashk@quicinc.com/
> 
> What was changed in v3?
It was supposed to be "Changes in v3" instead of v2.
> 
>>
>> Link to RFC:
>> https://lore.kernel.org/all/20241107073650.13473-1-quic_kriskura@quicinc.com/#Z31arch:arm64:boot:dts:qcom:sm8250.dtsi
>>
> 
Regards,
Prashanth K