-
Notifications
You must be signed in to change notification settings - Fork 1.6k
displayport: skip unnecessary DSC for MST modes within link bandwidth #1025
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1395,6 +1395,49 @@ bool ConnectorImpl::compoundQueryAttachMST(Group * target, | |
|
|
||
| if (compoundQueryAttachMSTIsDscPossible(target, modesetParams, pDscParams)) | ||
| { | ||
| // | ||
| // Before entering the DSC path, check if the mode can be supported | ||
| // without compression. The SST path (compoundQueryAttachSST) already | ||
| // does this correctly: it only enables DSC when willLinkSupportModeSST | ||
| // fails. For MST, perform an equivalent pre-check using PBN to avoid | ||
| // unnecessary DSC on links with sufficient bandwidth. | ||
| // | ||
| // Unnecessary DSC adds link training complexity and can cause | ||
| // instability through MST hubs and USB-C docks, manifesting as | ||
| // spurious HPD short pulses and DPCD AUX channel failures during | ||
| // DSC capability negotiation. | ||
| // | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. From the related issue opened,
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 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. |
||
| bool bForceDsc = pDscParams && | ||
| (pDscParams->forceDsc == DSC_FORCE_ENABLE); | ||
| bool bDscDualRequested = | ||
| (modesetParams.modesetInfo.mode == DSC_DUAL); | ||
|
|
||
| if (!bForceDsc && !bDscDualRequested) | ||
| { | ||
| unsigned base_pbn, slots, slots_pbn; | ||
| localInfo.lc.pbnRequired(localInfo.localModesetInfo, | ||
| base_pbn, slots, slots_pbn); | ||
|
|
||
| if (compoundQueryLocalLinkPBN + slots_pbn <= | ||
| localInfo.lc.pbnTotal()) | ||
| { | ||
| // | ||
| // The uncompressed mode fits within available local link PBN. | ||
| // Skip the DSC path and proceed directly to the full generic | ||
| // validation (watermark, per-device bandwidth). If the generic | ||
| // check fails for non-bandwidth reasons, the mode is not | ||
| // supportable regardless of DSC. | ||
| // | ||
| return compoundQueryAttachMSTGeneric(target, modesetParams, | ||
| &localInfo, pDscParams, | ||
| pErrorCode); | ||
| } | ||
| } | ||
|
|
||
| // | ||
| // DSC is required: either forced by client, DSC_DUAL requested, | ||
| // or local link bandwidth is insufficient for uncompressed mode. | ||
| // | ||
| unsigned int forceDscBitsPerPixelX16 = pDscParams->bitsPerPixelX16; | ||
| result = compoundQueryAttachMSTDsc(target, modesetParams, &localInfo, | ||
| pDscParams, pErrorCode); | ||
|
|
@@ -1406,13 +1449,12 @@ bool ConnectorImpl::compoundQueryAttachMST(Group * target, | |
| compoundQueryResult = compoundQueryAttachMSTGeneric(target, modesetParams, &localInfo, | ||
| pDscParams, pErrorCode); | ||
| // | ||
| // compoundQueryAttachMST Generic might fail due to the insufficient bandwidth , | ||
| // We only check whether bpp can be fit in the available bandwidth based on the tranied link config in compoundQueryAttachMSTDsc function. | ||
| // There might be cases where the default 10 bpp might fit in the available bandwidth based on the trained link config, | ||
| // however, the bandwidth might be insufficient at the actual bottleneck link between source and sink to drive the mode, causing CompoundQueryAttachMSTGeneric to fail. | ||
| // Incase of CompoundQueryAttachMSTGeneric failure, instead of returning false, check whether the mode can be supported with the max dsc compression bpp | ||
| // and return true if it can be supported. | ||
|
|
||
| // compoundQueryAttachMSTGeneric might fail due to insufficient bandwidth | ||
| // at a bottleneck link between source and sink. The default 10 bpp might | ||
| // fit based on the trained link config, but the actual available bandwidth | ||
| // at intermediate MST branches may be lower. If so, retry with max DSC | ||
| // compression (8 bpp) to check if that can support the mode. | ||
| // | ||
| if (!compoundQueryResult && forceDscBitsPerPixelX16 == 0U) | ||
| { | ||
| pDscParams->bitsPerPixelX16 = MAX_DSC_COMPRESSION_BPPX16; | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.