[PATCH 1/2] drm/i915/dp: Fix pipe BPP clamping due to HDR

[PATCH 1/2] drm/i915/dp: Fix pipe BPP clamping due to HDR

[Imre Deak]

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 <chaitanya.kumar.borah@intel.com>
Cc: <stable@vger.kernel.org> # v6.18+
Signed-off-by: Imre Deak <imre.deak@intel.com>
---
 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);
+	}
+
 	if (dsc && !intel_dp_dsc_compute_pipe_bpp_limits(connector, limits))
 		return false;
 
-- 
2.49.1

Re: [PATCH 1/2] drm/i915/dp: Fix pipe BPP clamping due to HDR

[Nautiyal, Ankit K]

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 <chaitanya.kumar.borah@intel.com>
> Cc: <stable@vger.kernel.org> # v6.18+
> Signed-off-by: Imre Deak <imre.deak@intel.com>
> ---
>   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 <ankit.k.nautiyal@intel.com>


[1] https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7052
[2] 
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969#note_3248404

> +	}
> +
>   	if (dsc && !intel_dp_dsc_compute_pipe_bpp_limits(connector, limits))
>   		return false;
>   

Re: [PATCH 1/2] drm/i915/dp: Fix pipe BPP clamping due to HDR

[Borah, Chaitanya Kumar]

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 <chaitanya.kumar.borah@intel.com>
>> Cc: <stable@vger.kernel.org> # v6.18+
>> Signed-off-by: Imre Deak <imre.deak@intel.com>
>> ---
>>   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 <ankit.k.nautiyal@intel.com>
> 
> 
> [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.
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.

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;

Re: [PATCH 1/2] drm/i915/dp: Fix pipe BPP clamping due to HDR

[Imre Deak]

[-- Attachment #1: Type: text/plain, Size: 5014 bytes --]

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 <chaitanya.kumar.borah@intel.com>
> > > Cc: <stable@vger.kernel.org> # v6.18+
> > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > > ---
> > >   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 <ankit.k.nautiyal@intel.com>
> > 
> > 
> > [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?

> 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;
> 

[-- Attachment #2: 0001-drm-i915-dp-Fix-pipe-BPP-clamping-due-to-HDR.patch --]
[-- Type: text/x-diff, Size: 2452 bytes --]

From 550f8de76d0b5a497d36a24dee6988d07a634588 Mon Sep 17 00:00:00 2001
From: Imre Deak <imre.deak@intel.com>
Date: Thu, 5 Feb 2026 16:49:03 +0200
Subject: [PATCH] drm/i915/dp: Fix pipe BPP clamping due to HDR

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 <chaitanya.kumar.borah@intel.com>
Cc: <stable@vger.kernel.org> # v6.18+
Signed-off-by: Imre Deak <imre.deak@intel.com>
---
 drivers/gpu/drm/i915/display/intel_dp.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index 4b786706ea2d..ad167393282d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2703,6 +2703,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);
@@ -2715,8 +2716,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
@@ -2732,6 +2732,17 @@ intel_dp_compute_config_limits(struct intel_dp *intel_dp,
 							respect_downstream_limits);
 	}
 
+	if (intel_dp_in_hdr_mode(conn_state) &&
+	    intel_dp_supports_dsc(intel_dp, connector, crtc_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);
+	}
+
 	if (dsc && !intel_dp_dsc_compute_pipe_bpp_limits(connector, limits))
 		return false;
 
-- 
2.49.1

Re: [PATCH 1/2] drm/i915/dp: Fix pipe BPP clamping due to HDR

[Borah, Chaitanya Kumar]

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 <chaitanya.kumar.borah@intel.com>
>>>> Cc: <stable@vger.kernel.org> # v6.18+
>>>> Signed-off-by: Imre Deak <imre.deak@intel.com>
>>>> ---
>>>>    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 <ankit.k.nautiyal@intel.com>
>>>
>>>
>>> [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;
>>

Re: [PATCH 1/2] drm/i915/dp: Fix pipe BPP clamping due to HDR

[Imre Deak]

On Mon, Feb 09, 2026 at 02:55:21PM +0530, Borah, Chaitanya Kumar wrote:
> 
> 
> 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 <chaitanya.kumar.borah@intel.com>
> > > > > Cc: <stable@vger.kernel.org> # v6.18+
> > > > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > > > > ---
> > > > >    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 <ankit.k.nautiyal@intel.com>
> > > > 
> > > > 
> > > > [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.

I think the sink / source support for 10 BPC should be still checked as
in this patch.

> 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?

No, the link BW requirement is determined by the link BPP, not the pipe
BPP for which the minimum is set. The link BPP in DSC mode can be
lowered below that, based on the sink's minimum compressed BPP support.
So in the fallback case, where 30 BPP uncompressed mode is not
supported by the sink due to a BW limit, DSC is used instead lowering
the compressed link BPP as required.

> [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;
> > > 
> 

Re: [PATCH 1/2] drm/i915/dp: Fix pipe BPP clamping due to HDR

[Imre Deak]

On Mon, Feb 09, 2026 at 11:34:34AM +0200, Imre Deak wrote:
> On Mon, Feb 09, 2026 at 02:55:21PM +0530, Borah, Chaitanya Kumar wrote:
> > 
> > 
> > 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 <chaitanya.kumar.borah@intel.com>
> > > > > > Cc: <stable@vger.kernel.org> # v6.18+
> > > > > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > > > > > ---
> > > > > >    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 <ankit.k.nautiyal@intel.com>
> > > > > 
> > > > > 
> > > > > [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.
> 
> I think the sink / source support for 10 BPC should be still checked as
> in this patch.
> 
> > 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?
> 
> No, the link BW requirement is determined by the link BPP, not the pipe
> BPP for which the minimum is set. The link BPP in DSC mode can be
> lowered below that, based on the sink's minimum compressed BPP support.
> So in the fallback case, where 30 BPP uncompressed mode is not
> supported by the sink due to a BW limit, DSC is used instead lowering
> the compressed link BPP as required.

Although, it's still possible that the sink wouldn't support the minimum
pipe BPP set here as a DSC input BPP. Setting a minimum (pipe/input) BPP 
in DSC mode isn't actually needed, since the highest possible BPP will
be selected there anyway. So I think the actual condition for setting
pipe.min_bpp = 30 above should be:

        if (intel_dp_in_hdr_mode(conn_state) &&
            intel_dp_supports_dsc(intel_dp, connector, crtc_state) &&
            !dsc) {
            ...

> > [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;
> > > > 
> > 

Re: [PATCH 1/2] drm/i915/dp: Fix pipe BPP clamping due to HDR

[Nautiyal, Ankit K]

On 2/9/2026 3:39 PM, Imre Deak wrote:
> On Mon, Feb 09, 2026 at 11:34:34AM +0200, Imre Deak wrote:
>> On Mon, Feb 09, 2026 at 02:55:21PM +0530, Borah, Chaitanya Kumar wrote:
>>>
>>> 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 <chaitanya.kumar.borah@intel.com>
>>>>>>> Cc: <stable@vger.kernel.org> # v6.18+
>>>>>>> Signed-off-by: Imre Deak <imre.deak@intel.com>
>>>>>>> ---
>>>>>>>     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 <ankit.k.nautiyal@intel.com>
>>>>>>
>>>>>>
>>>>>> [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.
>> I think the sink / source support for 10 BPC should be still checked as
>> in this patch.
>>
>>> 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?
>> No, the link BW requirement is determined by the link BPP, not the pipe
>> BPP for which the minimum is set. The link BPP in DSC mode can be
>> lowered below that, based on the sink's minimum compressed BPP support.
>> So in the fallback case, where 30 BPP uncompressed mode is not
>> supported by the sink due to a BW limit, DSC is used instead lowering
>> the compressed link BPP as required.
> Although, it's still possible that the sink wouldn't support the minimum
> pipe BPP set here as a DSC input BPP. Setting a minimum (pipe/input) BPP
> in DSC mode isn't actually needed, since the highest possible BPP will
> be selected there anyway. So I think the actual condition for setting
> pipe.min_bpp = 30 above should be:
>
>          if (intel_dp_in_hdr_mode(conn_state) &&
>              intel_dp_supports_dsc(intel_dp, connector, crtc_state) &&
>              !dsc) {
>              ...

Hmm makes sense.

Perhaps we should also add a debug message right after pipe_bpp is 
finalized (and before the full link config dump) to make it clear when 
HDR is selected but the chosen input/pipe bpp ends up below 30 bpp.

Something like below, in intel_dp_compute_link_for_joined_pipes() before 
the link config dump:

if (intel_dp_in_hdr_mode(conn_state) && pipe_config->pipe_bpp < 30)
         drm_dbg_kms(display->drm,
             "HDR mode selected but pipe bpp is limited to %d\n",
              pipe_config->pipe_bpp);

This will help flag out the cases where HDR is enabled but the pipe 
can’t reach 10bpc due to sink or bandwidth limits.


Regards,

Ankit

>>> [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;

Re: [PATCH 1/2] drm/i915/dp: Fix pipe BPP clamping due to HDR

[Imre Deak]

On Mon, Feb 09, 2026 at 05:00:13PM +0530, Nautiyal, Ankit K wrote:
> 
> On 2/9/2026 3:39 PM, Imre Deak wrote:
> > On Mon, Feb 09, 2026 at 11:34:34AM +0200, Imre Deak wrote:
> > > On Mon, Feb 09, 2026 at 02:55:21PM +0530, Borah, Chaitanya Kumar wrote:
> > > > 
> > > > 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 <chaitanya.kumar.borah@intel.com>
> > > > > > > > Cc: <stable@vger.kernel.org> # v6.18+
> > > > > > > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > > > > > > > ---
> > > > > > > >     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 <ankit.k.nautiyal@intel.com>
> > > > > > > 
> > > > > > > 
> > > > > > > [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.
> > > I think the sink / source support for 10 BPC should be still checked as
> > > in this patch.
> > > 
> > > > 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?
> > > No, the link BW requirement is determined by the link BPP, not the pipe
> > > BPP for which the minimum is set. The link BPP in DSC mode can be
> > > lowered below that, based on the sink's minimum compressed BPP support.
> > > So in the fallback case, where 30 BPP uncompressed mode is not
> > > supported by the sink due to a BW limit, DSC is used instead lowering
> > > the compressed link BPP as required.
> > Although, it's still possible that the sink wouldn't support the minimum
> > pipe BPP set here as a DSC input BPP. Setting a minimum (pipe/input) BPP
> > in DSC mode isn't actually needed, since the highest possible BPP will
> > be selected there anyway. So I think the actual condition for setting
> > pipe.min_bpp = 30 above should be:
> > 
> >          if (intel_dp_in_hdr_mode(conn_state) &&
> >              intel_dp_supports_dsc(intel_dp, connector, crtc_state) &&
> >              !dsc) {
> >              ...
> 
> Hmm makes sense.
> 
> Perhaps we should also add a debug message right after pipe_bpp is finalized
> (and before the full link config dump) to make it clear when HDR is selected
> but the chosen input/pipe bpp ends up below 30 bpp.
> 
> Something like below, in intel_dp_compute_link_for_joined_pipes() before the
> link config dump:
> 
> if (intel_dp_in_hdr_mode(conn_state) && pipe_config->pipe_bpp < 30)
>         drm_dbg_kms(display->drm,
>             "HDR mode selected but pipe bpp is limited to %d\n",
>              pipe_config->pipe_bpp);
> 
> This will help flag out the cases where HDR is enabled but the pipe can’t
> reach 10bpc due to sink or bandwidth limits.

Ok, can also debug print the connector's HDR mode, like

	DP lane count ... bpp input x compressed y HDR-sink yes/no ...

at the end of intel_dp_compute_link_for_joined_pipes().

> 
> 
> Regards,
> 
> Ankit
> 
> > > > [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;

Re: [PATCH 1/2] drm/i915/dp: Fix pipe BPP clamping due to HDR

[Nautiyal, Ankit K]

On 2/9/2026 5:24 PM, Imre Deak wrote:
> On Mon, Feb 09, 2026 at 05:00:13PM +0530, Nautiyal, Ankit K wrote:
>> On 2/9/2026 3:39 PM, Imre Deak wrote:
>>> On Mon, Feb 09, 2026 at 11:34:34AM +0200, Imre Deak wrote:
>>>> On Mon, Feb 09, 2026 at 02:55:21PM +0530, Borah, Chaitanya Kumar wrote:
>>>>> 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 <chaitanya.kumar.borah@intel.com>
>>>>>>>>> Cc: <stable@vger.kernel.org> # v6.18+
>>>>>>>>> Signed-off-by: Imre Deak <imre.deak@intel.com>
>>>>>>>>> ---
>>>>>>>>>      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 <ankit.k.nautiyal@intel.com>
>>>>>>>>
>>>>>>>>
>>>>>>>> [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.
>>>> I think the sink / source support for 10 BPC should be still checked as
>>>> in this patch.
>>>>
>>>>> 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?
>>>> No, the link BW requirement is determined by the link BPP, not the pipe
>>>> BPP for which the minimum is set. The link BPP in DSC mode can be
>>>> lowered below that, based on the sink's minimum compressed BPP support.
>>>> So in the fallback case, where 30 BPP uncompressed mode is not
>>>> supported by the sink due to a BW limit, DSC is used instead lowering
>>>> the compressed link BPP as required.
>>> Although, it's still possible that the sink wouldn't support the minimum
>>> pipe BPP set here as a DSC input BPP. Setting a minimum (pipe/input) BPP
>>> in DSC mode isn't actually needed, since the highest possible BPP will
>>> be selected there anyway. So I think the actual condition for setting
>>> pipe.min_bpp = 30 above should be:
>>>
>>>           if (intel_dp_in_hdr_mode(conn_state) &&
>>>               intel_dp_supports_dsc(intel_dp, connector, crtc_state) &&
>>>               !dsc) {
>>>               ...
>> Hmm makes sense.
>>
>> Perhaps we should also add a debug message right after pipe_bpp is finalized
>> (and before the full link config dump) to make it clear when HDR is selected
>> but the chosen input/pipe bpp ends up below 30 bpp.
>>
>> Something like below, in intel_dp_compute_link_for_joined_pipes() before the
>> link config dump:
>>
>> if (intel_dp_in_hdr_mode(conn_state) && pipe_config->pipe_bpp < 30)
>>          drm_dbg_kms(display->drm,
>>              "HDR mode selected but pipe bpp is limited to %d\n",
>>               pipe_config->pipe_bpp);
>>
>> This will help flag out the cases where HDR is enabled but the pipe can’t
>> reach 10bpc due to sink or bandwidth limits.
> Ok, can also debug print the connector's HDR mode, like
>
> 	DP lane count ... bpp input x compressed y HDR-sink yes/no ...
>
> at the end of intel_dp_compute_link_for_joined_pipes().


That sounds good. IMHO, let's just drop '-sink' and just have HDR yes/no 
(HDR-sink might imply HDR capability of the sink)


Regards,

Ankit

>
>>
>> Regards,
>>
>> Ankit
>>
>>>>> [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;

Re: [PATCH 1/2] drm/i915/dp: Fix pipe BPP clamping due to HDR

[Imre Deak]

On Mon, Feb 09, 2026 at 06:15:45PM +0530, Nautiyal, Ankit K wrote:
> 
> On 2/9/2026 5:24 PM, Imre Deak wrote:
> > On Mon, Feb 09, 2026 at 05:00:13PM +0530, Nautiyal, Ankit K wrote:
> > > On 2/9/2026 3:39 PM, Imre Deak wrote:
> > > > On Mon, Feb 09, 2026 at 11:34:34AM +0200, Imre Deak wrote:
> > > > > On Mon, Feb 09, 2026 at 02:55:21PM +0530, Borah, Chaitanya Kumar wrote:
> > > > > > 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 <chaitanya.kumar.borah@intel.com>
> > > > > > > > > > Cc: <stable@vger.kernel.org> # v6.18+
> > > > > > > > > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > > > > > > > > > ---
> > > > > > > > > >      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 <ankit.k.nautiyal@intel.com>
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > [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.
> > > > > I think the sink / source support for 10 BPC should be still checked as
> > > > > in this patch.
> > > > > 
> > > > > > 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?
> > > > > No, the link BW requirement is determined by the link BPP, not the pipe
> > > > > BPP for which the minimum is set. The link BPP in DSC mode can be
> > > > > lowered below that, based on the sink's minimum compressed BPP support.
> > > > > So in the fallback case, where 30 BPP uncompressed mode is not
> > > > > supported by the sink due to a BW limit, DSC is used instead lowering
> > > > > the compressed link BPP as required.
> > > > Although, it's still possible that the sink wouldn't support the minimum
> > > > pipe BPP set here as a DSC input BPP. Setting a minimum (pipe/input) BPP
> > > > in DSC mode isn't actually needed, since the highest possible BPP will
> > > > be selected there anyway. So I think the actual condition for setting
> > > > pipe.min_bpp = 30 above should be:
> > > > 
> > > >           if (intel_dp_in_hdr_mode(conn_state) &&
> > > >               intel_dp_supports_dsc(intel_dp, connector, crtc_state) &&
> > > >               !dsc) {
> > > >               ...
> > > Hmm makes sense.
> > > 
> > > Perhaps we should also add a debug message right after pipe_bpp is finalized
> > > (and before the full link config dump) to make it clear when HDR is selected
> > > but the chosen input/pipe bpp ends up below 30 bpp.
> > > 
> > > Something like below, in intel_dp_compute_link_for_joined_pipes() before the
> > > link config dump:
> > > 
> > > if (intel_dp_in_hdr_mode(conn_state) && pipe_config->pipe_bpp < 30)
> > >          drm_dbg_kms(display->drm,
> > >              "HDR mode selected but pipe bpp is limited to %d\n",
> > >               pipe_config->pipe_bpp);
> > > 
> > > This will help flag out the cases where HDR is enabled but the pipe can’t
> > > reach 10bpc due to sink or bandwidth limits.
> > Ok, can also debug print the connector's HDR mode, like
> > 
> > 	DP lane count ... bpp input x compressed y HDR-sink yes/no ...
> > 
> > at the end of intel_dp_compute_link_for_joined_pipes().
> 
> That sounds good. IMHO, let's just drop '-sink' and just have HDR yes/no
> (HDR-sink might imply HDR capability of the sink)

Ok.

> Regards,
> 
> Ankit
> 
> > 
> > > 
> > > Regards,
> > > 
> > > Ankit
> > > 
> > > > > > [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;

Re: [PATCH 1/2] drm/i915/dp: Fix pipe BPP clamping due to HDR

[Borah, Chaitanya Kumar]

On 2/9/2026 3:39 PM, Imre Deak wrote:
> On Mon, Feb 09, 2026 at 11:34:34AM +0200, Imre Deak wrote:
>> On Mon, Feb 09, 2026 at 02:55:21PM +0530, Borah, Chaitanya Kumar wrote:
>>>
>>>
>>> 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 <chaitanya.kumar.borah@intel.com>
>>>>>>> Cc: <stable@vger.kernel.org> # v6.18+
>>>>>>> Signed-off-by: Imre Deak <imre.deak@intel.com>
>>>>>>> ---
>>>>>>>     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 <ankit.k.nautiyal@intel.com>
>>>>>>
>>>>>>
>>>>>> [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.
>>
>> I think the sink / source support for 10 BPC should be still checked as
>> in this patch.

Agreed.

>>
>>> 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?
>>
>> No, the link BW requirement is determined by the link BPP, not the pipe
>> BPP for which the minimum is set. The link BPP in DSC mode can be
>> lowered below that, based on the sink's minimum compressed BPP support.
>> So in the fallback case, where 30 BPP uncompressed mode is not
>> supported by the sink due to a BW limit, DSC is used instead lowering
>> the compressed link BPP as required.
> 
> Although, it's still possible that the sink wouldn't support the minimum
> pipe BPP set here as a DSC input BPP. Setting a minimum (pipe/input) BPP
> in DSC mode isn't actually needed, since the highest possible BPP will
> be selected there anyway. So I think the actual condition for setting
> pipe.min_bpp = 30 above should be:
> 
>          if (intel_dp_in_hdr_mode(conn_state) &&
>              intel_dp_supports_dsc(intel_dp, connector, crtc_state) &&
>              !dsc) {
>              ...
> 

I was trying to make it work within intel_dp_compute_link_config_wide() 
but this works too.

==
Chaitanya

>>> [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;
>>>>>
>>>