Re: [PATCH 1/3] drm/i915/dp: Prefer DSC over a 6 bpc uncompressed output

["Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com>]

On 6/13/2026 12:16 AM, Alexander Kaplan wrote:
> On Fri, Jun 12, 2026 at 07:32:33PM +0300, Imre Deak wrote:
>> So, this would be a generalization for/instead of the HDR logic above
>> using a intel_dp_in_hdr_mode() ? 30 : 24 limit (which would also apply a
>> lower max-bpc limit for HDR as well).
> Hi Imre,
>
> yes, it follows the same pattern as the HDR logic, with one deliberate
> difference.
> The extra crtc_state->pipe_bpp check makes an explicit max bpc property
> request below 8 win over the new limit, so the uncompressed 6 bpc path
> stays reachable.
> That keeps the current uAPI behavior under IGT kms_dither and leaves an
> escape hatch for sinks with a broken DSC implementation.
> The HDR limit currently wins over a lower property request, so a merge
> into an intel_dp_in_hdr_mode() ? 30 : 24 block would, as you say, make
> HDR honor such a request as well.
> If that behavior change for HDR is acceptable I am happy to merge the
> two blocks in a v2, otherwise I would keep them separate.
>
>> There could be other reasons to prefer DSC, like a more finegrained BW
>> allocation on MST links. But there are also reasons to prefer non-DSC
>> mode like power saving (no need to enable either a DSC encoder in the
>> source or a DSC decoder downstream), or reliability issues related to
>> DSC.
>>
>> There's been a lot of talk internally about the above aspects and how to
>> handle them in a way suitable in all scenarios. Hence, I'm not sure if
>> adding more policies to the driver like the above bpp limit/DSC
>> preference is too ad-hoc/early or not at this point.
> I understand the hesitation about adding more policy, but for this
> series the patch is less a quality preference and more a dependency of
> patches 2 and 3.
> Those open up RGB configurations on FRL links where previously only the
> 4:2:0 fallback existed, and for modes like 4k120 on a 4 lane HBR3 link
> the only uncompressed fit is 6 bpc.
> Both tested Synaptics PCON device families output corrupted FRL timings
> for exactly that configuration and the TV shows a black screen, while
> the same mode works with DSC.
> So without patch 1 the series would trade the previous 4:2:0 picture
> for a black screen on this hardware.
>
> I also think the 6 bpc case is narrow enough that it does not really
> open the general DSC versus non-DSC question.
> 6 bpc is a DP and eDP panel concept, HDMI only defines 8, 10, 12 and 16
> bpc output depths.
> A PCON that has to forward an 18 bpp stream to an HDMI sink has no
> valid HDMI output format for it, which would explain why both device
> families fail in the same way.
> Windows and macOS drive 4k120 on these devices via DSC, and they have
> no other choice, RGB 8 bpc at a 1188 MHz pixel clock needs 28.5 Gbps
> against the 25.92 Gbps payload of a 4 lane HBR3 link.
> There is also precedent for forcing DSC where the uncompressed 18 bpp
> path is broken, commit 55eaef164174 ("drm/i915/dp_mst: Handle the
> Synaptics HBlank expansion quirk") does the same for the affected MST
> docks.
> And only modes which do not fit through the link at 8 bpc are affected
> at all, so in the uncompressed case the link already runs at the top of
> its capability.
> For the power and reliability concerns the max bpc property acts as the
> userspace override, setting it to 6 restores today's behavior.
>
> If the general form is still considered too early, I could narrow the
> limit to HDMI sinks behind a PCON, gating it on
> intel_dp_has_hdmi_sink().
> There 6 bpc is not a valid output format on the HDMI side, so the
> change is a correctness fix rather than a preference, and it would
> still unblock patches 2 and 3.

I agree to this part. As you have noted, since HDMI does not accept 6 
bpc, we should narrow down the check to HDMI sinks behind a DFP.

Regards,

Ankit


> Just let me know which shape you prefer.
>
> Thanks,
> Alex
>