displayport: skip unnecessary DSC for MST modes within link bandwidth#1025
displayport: skip unnecessary DSC for MST modes within link bandwidth#1025coleleavitt wants to merge 2 commits intoNVIDIA:mainfrom
Conversation
The MST mode validation path in compoundQueryAttachMST() unconditionally tries DSC when the device supports it, even when the link has sufficient bandwidth for the uncompressed mode. This can cause instability through MST hubs and USB-C docks that don't handle DSC negotiation well, manifesting as spurious HPD short pulses and DPCD AUX channel failures. Add a PBN pre-check before entering the DSC path: if the uncompressed mode fits within the available local link PBN, skip DSC and proceed directly to compoundQueryAttachMSTGeneric() for full validation. This mirrors the SST behavior in compoundQueryAttachSST() which only enables DSC when willLinkSupportModeSST() fails. The pre-check preserves all existing behavior for forced DSC, DSC_DUAL mode requests, and bandwidth-insufficient cases. Signed-off-by: Cole Leavitt <cole@unwrap.rs>
3291a61 to
f77ad61
Compare
Kernel 6.15+ replaced scripts/pahole-flags.sh with scripts/Makefile.btf and scripts/gen-btf.sh for BTF generation. The existing check only looks for pahole-flags.sh, causing the PAHOLE_AWK_PROGRAM wrapper to be used unnecessarily on newer kernels. This wrapper has shell quoting issues that result in awk parse errors during module build. Update the condition to also check for Makefile.btf, allowing the kernel's native BTF infrastructure to handle generation without the awk wrapper. Signed-off-by: Cole Leavitt <cole@unwrap.rs>
| # tree, the kernel handles BTF generation natively; otherwise add PAHOLE and | ||
| # PAHOLE_AWK_PROGRAM assignments to PAHOLE_VARIABLES. | ||
| # Kernel 6.15+ uses Makefile.btf + gen-btf.sh instead of pahole-flags.sh. | ||
| PAHOLE_VARIABLES=$(if $(or $(wildcard $(KERNEL_SOURCES)/scripts/pahole-flags.sh),$(wildcard $(KERNEL_SOURCES)/scripts/Makefile.btf)),,"PAHOLE=$(AWK) '$(PAHOLE_AWK_PROGRAM)'") |
There was a problem hiding this comment.
I am worried this change breaks BTF generation support for kernels 6.7 and above. I also don't see any use of gen-btf.sh directly in Makefile.btf for kernels 6.15 and above. Can you describe what issue you ran into that made you author this commit? Also, this should be a separate PR if needed.
https://elixir.bootlin.com/linux/v6.15.11/source/scripts/Makefile.btf
Thanks in advance.
| // instability through MST hubs and USB-C docks, manifesting as | ||
| // spurious HPD short pulses and DPCD AUX channel failures during | ||
| // DSC capability negotiation. | ||
| // |
There was a problem hiding this comment.
From the related issue opened,
This causes instability through MST hubs and USB-C docks that don't handle DSC negotiation well, manifesting as spurious HPD short pulses, DPCD AUX channel failures, and intermittent display disconnection.
Monitor intermittently shows "input signal out of range" and disconnects
For some of these, I am not sure how DSC would be related. DSC shouldn't affect DP AUX or HPD. I suspect the "input signal out of range" seen on the monitor is likely due to the a link assessment failure that programs the wrong compression level supported by the sink and this change works around that programming error. Would you be willing to share a log collection using nvidia-bug-report.sh with nvidia_modeset.debug=1, so we can inspect the dplib logging and understand the failure with the display?
As for why we always opportunistically enable DSC in a MST configuration, that is done for a simple software management policy since in most MST setups, DSC will be required.
Summary
Add a PBN pre-check in
compoundQueryAttachMST()to skip unnecessary DSC compression when the link has sufficient bandwidth for the uncompressed mode.Problem
The MST mode validation path unconditionally tries DSC when the device supports it, even when the link has sufficient bandwidth. This causes instability through MST hubs and USB-C docks that don't handle DSC negotiation well, manifesting as:
The SST path (
compoundQueryAttachSST) already handles this correctly by checkingwillLinkSupportModeSST()before enabling DSC.Solution
Before entering the DSC path, calculate the PBN required for the uncompressed mode and check if it fits within available local link PBN. If it does, skip DSC and proceed directly to
compoundQueryAttachMSTGeneric()for full validation.This mirrors the SST behavior without introducing state management issues (the PBN pre-check is side-effect-free).
Behavior Preserved
DSC_FORCE_ENABLE): Still enabledTesting
Tested on:
Before: Monitor intermittently disconnects every few seconds with DSC enabled at 10 bpp
After: Stable connection without DSC (mode fits in DP 1.4 HBR3 uncompressed)
Related Issues
Fixes #1024
May help with: