[bug report] drm/i915/dp: Get optimal link config to have best compressed bpp

Nautiyal, Ankit K ankit.k.nautiyal at intel.com
Wed Feb 5 10:39:00 UTC 2025


On 2/5/2025 2:00 PM, Dan Carpenter wrote:
> Hello Ankit Nautiyal,
>
> Commit 1c56e9a39833 ("drm/i915/dp: Get optimal link config to have
> best compressed bpp") from Aug 17, 2023 (linux-next), leads to the
> following Smatch static checker warning:
>
> 	drivers/gpu/drm/i915/display/intel_dp.c:2481 intel_dp_dsc_compute_pipe_bpp_limits()
> 	warn: always clamps to 24
>
> drivers/gpu/drm/i915/display/intel_dp.c
>      2472 static void
>      2473 intel_dp_dsc_compute_pipe_bpp_limits(struct intel_dp *intel_dp,
>      2474                                      struct link_config_limits *limits)
>      2475 {
>      2476         struct intel_display *display = to_intel_display(intel_dp);
>      2477         int dsc_min_bpc = intel_dp_dsc_min_src_input_bpc();
>      2478         int dsc_max_bpc = intel_dp_dsc_max_src_input_bpc(display);
>      2479
>      2480         limits->pipe.max_bpp = clamp(limits->pipe.max_bpp, dsc_min_bpc * 3, dsc_max_bpc * 3);
> --> 2481         limits->pipe.min_bpp = clamp(limits->pipe.min_bpp, dsc_min_bpc * 3, dsc_max_bpc * 3);
>      2482 }
>
> This is an unpublished static checker warning that complains about weird
> clamps() so it only just started showing up now.  The problem is a
> mismatch between intel_dp_min_bpp() and intel_dp_dsc_min_src_input_bpc().
>
> In intel_dp_min_bpp() it uses "6 * 3" but then that gets overwriten with
> "8 * 3" eventually.  The warning is that "6 * 3" might be pointless?
> I haven't followed the code totally, but it seems like potentially the
> checker is correct.

Hi Dan,

The intel_dp_min_bpp helper function specifies the minimum bits per 
pixel (bpp) that the hardware supports for DisplayPort (DP) without 
using Display Stream Compression (DSC).

On the other hand, intel_dp_dsc_min_src_input_bpc() specifies the 
minimum bits per component (bpc) that the hardware supports when DSC is 
used. This is used to derive the min bpp which can be the input to the 
DSC HW.

For a given resolution, the driver first tries different lanes, rates, 
output formats, and bpps within a minimum and maximum bpp range without 
using DSC.

If this is not possible, it then tries to use DSC. With DSC, the minimum 
bpp the hardware can support is 24 bpp, so we update the minimum and 
maximum range accordingly.

>
> drivers/gpu/drm/i915/display/intel_dp.c
>    1175  int intel_dp_min_bpp(enum intel_output_format output_format)
>    1176  {
>    1177          if (output_format == INTEL_OUTPUT_FORMAT_RGB)
>    1178                  return 6 * 3;
>                                 ^^^^^
> Is this pointless?  Should we just always return "8 * 3" since
> that's what it's clamped to in the end?

The 6 * 3 value is the minimum bpp when DSC is not in use and the output 
format is RGB.
This value is not pointless because it represents the minimum bpp 
supported by the hardware in this specific scenario.


>
>    1179          else
>    1180                  return 8 * 3;
>    1181  }
>
> drivers/gpu/drm/i915/display/intel_dp.c
>    2161  int intel_dp_dsc_min_src_input_bpc(void)
>    2162  {
>    2163          /* Min DSC Input BPC for ICL+ is 8 */
>    2164          return 8;
>
> This 8 becomes "8 * 3" in the caller.

This function returns 8, which becomes 8 * 3 in the caller, representing 
the minimum bpp when DSC is used.
If DSC is not used, intel_dp_dsc_compute_pipe_bpp_limits() does not get 
called, and the clamping to 24 bpp does not occur.

I hope this clarifies the distinction and the logic behind the clamping.

Thanks & Regards,
Ankit


>
>    2165  }
>
> regards,
> dan carpenter
>


More information about the Intel-gfx mailing list