On 2/9/2026 2:10 PM, Imre Deak wrote:
On Mon, Feb 09, 2026 at 12:06:20PM +0530, Borah, Chaitanya Kumar wrote:
On 2/6/2026 7:20 PM, Nautiyal, Ankit K wrote:
On 2/6/2026 4:12 PM, Imre Deak wrote:
The pipe BPP value shouldn't be set outside of the source's / sink's
valid pipe BPP range, ensure this when increasing the minimum pipe BPP
value to 30 due to HDR.
Fixes: ba49a4643cf53 ("drm/i915/dp: Set min_bpp limit to 30 in HDR mode")
Cc: Chaitanya Kumar Borah <[email protected]>
Cc: <[email protected]> # v6.18+
Signed-off-by: Imre Deak <[email protected]>
---
drivers/gpu/drm/i915/display/intel_dp.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/
drm/i915/display/intel_dp.c
index 2b8f43e211741..4d8f480cf803f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2697,6 +2697,7 @@ intel_dp_compute_config_limits(struct intel_dp
*intel_dp,
bool dsc,
struct link_config_limits *limits)
{
+ struct intel_display *display = to_intel_display(intel_dp);
bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST);
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
@@ -2709,8 +2710,7 @@ intel_dp_compute_config_limits(struct intel_dp
*intel_dp,
limits->min_lane_count = intel_dp_min_lane_count(intel_dp);
limits->max_lane_count = intel_dp_max_lane_count(intel_dp);
- limits->pipe.min_bpp = intel_dp_in_hdr_mode(conn_state) ? 30 :
- intel_dp_min_bpp(crtc_state->output_format);
+ limits->pipe.min_bpp = intel_dp_min_bpp(crtc_state->output_format);
if (is_mst) {
/*
* FIXME: If all the streams can't fit into the link with their
@@ -2726,6 +2726,16 @@ intel_dp_compute_config_limits(struct
intel_dp *intel_dp,
respect_downstream_limits);
}
+ if (intel_dp_in_hdr_mode(conn_state)) {
+ if (limits->pipe.min_bpp <= 30 && limits->pipe.max_bpp >= 30)
+ limits->pipe.min_bpp = 30;
+ else
+ drm_dbg_kms(display->drm,
+ "[CONNECTOR:%d:%s] HDR min 30 bpp outside of
valid pipe bpp range (%d-%d)\n",
+ connector->base.base.id, connector->base.name,
+ limits->pipe.min_bpp, limits->pipe.max_bpp);
pipe.max_bpp < 30 will be either due to the max_bpc property set to less
than 10, or perhaps when the panel itself does not support 10 bpc
(limited by EDID or VBT).
With these constraints doesn't make sense to enable HDR and send HDR
metadata.
However, as we see in some reported issues [1] [2], in practice some
compositor seems to enable HDR by default and with the hard limit set,
they report blankout.
So it does make sense to raise the min bpp limit only if its inside the
supported range.
Reviewed-by: Ankit Nautiyal <[email protected]>
[1] https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7052
[2] https://gitlab.freedesktop.org/drm/i915/kernel/-/
issues/5969#note_3248404
I am not sure if this patch would help with the above gitlabs. For example
in case of #7052 pipe max bpp is 30 and the commit still fails.
It does fix though reported cases where the sink does not support 10 BPC
at all. Yes the monitor in #7052 is still a problem, since it supports
10 BPC only with lower resolution, where the link BW would allow this
and he monitor doesn't have DSC either.
However, I need to look deeper.
I am thinking of relaxing this restriction all together because the earlier
assumption that a panel advertising HDR will support atleast 10bpc in all
it's mode turns out to be false.
Currently, I am inclined on the following policy.
- If DSC is not available, fall back to normal bandwidth calculations and
select the highest bpp the link can support. (Also preferred by Kwin)
- If DSC is available, prefer falling back to DSC and attempt the highest
bpp allowed by bandwidth constraints.
The patch does the above, except for not handling the case where the
monitor doesn't support DSC. The attach patch handles that too and so
fixes #7052 as well, are you ok with it?
This should work since [1] did.
There is one more (theoritical) scenario that I think is still not
covered. What happens in a case where 30bpp doesnot fit into DSC bandwidth?
As I understand, the min bpp limit of 30bpp would become a bottle-neck
even then?
[1]
https://github.com/ckborah/drm-tip-sandbox/commit/5dd10a763ae6e651a0ab494ab1ad0c9d81c2de47
I am working on a patch for this and should be able to float something soon.
Imre, if you agree with this policy, would you please wait for the patch.
That should make it easier to send out fix for stable kernels.
==
Chaitanya
+ }
+
if (dsc && !intel_dp_dsc_compute_pipe_bpp_limits(connector,
limits))
return false;
