| Message ID | 20241218102707.76272-1-quic_prashk@quicinc.com |
|---|---|
| Headers | show |
| Series | Disable USB U1/U2 entry for QC targets | expand |
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 >
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
On Wed, Dec 18, 2024 at 05:18:50PM +0530, Prashanth K wrote: > > > 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. No, it's fine. The text in the commit message lead me to a wrong conclusion. > > >> > >> 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. Then where is a changelog between RFC and v2? Please consider switching to the b4 tool, it handles such issues for you. > > > >> > >> 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 >
On 19-12-24 08:37 am, Dmitry Baryshkov wrote: > On Wed, Dec 18, 2024 at 05:18:50PM +0530, Prashanth K wrote: >> >> >> 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. > > No, it's fine. The text in the commit message lead me to a wrong > conclusion. > Ok sure. >> >>>> >>>> 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. > > Then where is a changelog between RFC and v2? > > Please consider switching to the b4 tool, it handles such issues for > you. > Ok, Should I send a new version updating the cover letter? >>> >>>> >>>> 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 >> >
On Thu, Dec 19, 2024 at 09:47:12AM +0530, Prashanth K wrote: > > > On 19-12-24 08:37 am, Dmitry Baryshkov wrote: > > On Wed, Dec 18, 2024 at 05:18:50PM +0530, Prashanth K wrote: > >> > >> > >> 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. > > > > No, it's fine. The text in the commit message lead me to a wrong > > conclusion. > > > Ok sure. > >> > >>>> > >>>> 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. > > > > Then where is a changelog between RFC and v2? > > > > Please consider switching to the b4 tool, it handles such issues for > > you. > > > Ok, Should I send a new version updating the cover letter? For now you can provide data in the reply. Just make sure to include it in the cover letter if the patchset gets reposted. > >>> > >>>> > >>>> 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 > >> > > >
On 18.12.2024 11:26 AM, 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: For the series: Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Konrad
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: > > 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 Thank you for submitting this, changes looks good and this is very welcome corrections! But patch subject is not okay. The prefix should match other changes in these files, and no "for XYZ" suffix. As such, these should all look like: "arm64: dts: qcom: <soc>: Disable USB U1/U2 entry" > > 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 I merge Arm and Arm64 patches through different trees, so I would appreciate if you send these two as a separate series (also v4). Thanks, Bjorn > 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(+) > > -- > 2.25.1 >
On 26-12-24 10:13 am, Bjorn Andersson 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: [...] >> 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 > > Thank you for submitting this, changes looks good and this is very > welcome corrections! > > But patch subject is not okay. The prefix should match other changes in > these files, and no "for XYZ" suffix. > > As such, these should all look like: > > "arm64: dts: qcom: <soc>: Disable USB U1/U2 entry" > >> >> 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 > > I merge Arm and Arm64 patches through different trees, so I would > appreciate if you send these two as a separate series (also v4). > Sure, will update the subject for all patches, and split it into 2 series (v4 for for both arm and arm64). I hope its fine to keep the Reviewed-by tag from Konrad on next version. Thanks for the review, Prashanth K
On 26.12.2024 5:55 AM, Prashanth K wrote: > > > On 26-12-24 10:13 am, Bjorn Andersson 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: > > [...] > >>> 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 >> >> Thank you for submitting this, changes looks good and this is very >> welcome corrections! >> >> But patch subject is not okay. The prefix should match other changes in >> these files, and no "for XYZ" suffix. >> >> As such, these should all look like: >> >> "arm64: dts: qcom: <soc>: Disable USB U1/U2 entry" >> >>> >>> 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 >> >> I merge Arm and Arm64 patches through different trees, so I would >> appreciate if you send these two as a separate series (also v4). >> > > Sure, will update the subject for all patches, and split it into 2 > series (v4 for for both arm and arm64). I hope its fine to keep the > Reviewed-by tag from Konrad on next version. Yes, you can usually feel free to keep tags, unless there's major changes Konrad