[PATCH 08/12] drm/i915/display: Add guardband check for feature latencies

Nautiyal, Ankit K ankit.k.nautiyal at intel.com
Sun Aug 24 04:22:24 UTC 2025


On 8/22/2025 5:01 PM, Jani Nikula wrote:
> On Wed, 20 Aug 2025, Ankit Nautiyal <ankit.k.nautiyal at intel.com> wrote:
>> +	if (HAS_VRR(display) && intel_vrr_possible(crtc_state)) {
> Nitpick, and a tangential to designing stuff:
>
> intel_vrr_possible() never returns true for !HAS_VRR(). The HAS_VRR()
> check is redundant. Adding redundant checks adds uncertainty about what
> intel_vrr_possible() can return. "Whoa, can it return true even for
> !HAS_VRR()? Why?" And then it reinforces the mentality that everything
> needs redundancy and double checking.

Hi Jani,

Thanks for the review! You're right : since flipline is only set when 
HAS_VRR() is true, the extra check was unnecessary.

I'll drop the HAS_VRR() check and update the patch.

>
> This is not about just that one check and one line. The idea is that for
> most "has feature" checks that enable something in the crtc state, you
> do that check in very few places, and the fields in crtc state dictate
> the rest. You're not supposed to have to second guess what crtc state
> has.

That makes sense - checking for HAS_* at some places and then trusting 
the crtc state keeps things cleaner.

I noticed a couple of places, where HAS_VRR() and intel_vrr_possible are 
used together. I will go through those and send a follow-up patch to 
simplify them.

I'll also keep this principle in mind while writing and reviewing code 
going forward.

Thanks for the insight!

Regards,

Ankit

>
> Food for though.
>
>
> BR,
> Jani.
>
>


More information about the Intel-gfx mailing list