From: Imre Deak <imre.deak@intel.com>
To: Jonathan Cavitt <jonathan.cavitt@intel.com>
Cc: <intel-gfx@lists.freedesktop.org>, <alex.zuo@intel.com>
Subject: Re: [PATCH] drm/i915/display: Do not check crtc_state when initializing BW limits
Date: Tue, 22 Sep 2026 15:27:01 +0300 [thread overview]
Message-ID: <arJ0FUdbC8ed5CuL@ideak-desk.lan> (raw)
In-Reply-To: <20260921184617.609564-1-jonathan.cavitt@intel.com>
On Tue, Sep 22, 2026 at 02:46:17AM +0800, Jonathan Cavitt wrote:
> In intel_link_bw_init_limits, we call intel_atomic_get_new_crtc_state to
> grab an intel_crtc_state pointer. This pointer is later used to set the
> max_bpp_x16 value for the given pipe. There is a check here for if the
> return value of the intel_atomic_get_new_crtc_state function returns
> NULL, but this is not checked in any other place where this function is
> used.
The other places using intel_atomic_get_new_crtc_state() can omit the
check, since at those places it's guaranteed that the CRTC state for the
crtc passed to the function is part of the atomic state, hence
intel_atomic_get_new_crtc_state() is guaranteed to return a non-NULL
pointer.
> Removing this check makes the code more consistent and prevents
> confusion from static analyzers.
>
> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_link_bw.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_link_bw.c b/drivers/gpu/drm/i915/display/intel_link_bw.c
> index e71e76d6fd3e0..2a20a12de9e0a 100644
> --- a/drivers/gpu/drm/i915/display/intel_link_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_link_bw.c
> @@ -64,8 +64,7 @@ void intel_link_bw_init_limits(struct intel_atomic_state *state,
> intel_atomic_get_new_crtc_state(state, crtc);
> int forced_bpp_x16 = get_forced_link_bpp_x16(state, crtc);
>
> - if ((state->base.duplicated && crtc_state) ||
> - intel_dp_mst_stream_disconnected(state, crtc)) {
> + if (state->base.duplicated || intel_dp_mst_stream_disconnected(state, crtc)) {
The loop goes through all pipes (i.e. CRTCs) and it's not guaranteed
that all CRTCs are part of the atomic state. Hence the crtc_state==NULL
is required here unless intel_dp_mst_stream_disconnected() returns true,
in which case that return value also guarantees that the CRTC is in the
atomic state and hence crtc_state is guaranteed to be non-NULL.
So the above condition in the existing code is correct.
> limits->max_bpp_x16[pipe] = crtc_state->max_link_bpp_x16;
> if (intel_dsc_enabled_on_link(crtc_state))
> limits->link_dsc_pipes |= BIT(pipe);
> --
> 2.53.0
>
prev parent reply other threads:[~2026-09-22 12:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 18:46 [PATCH] drm/i915/display: Do not check crtc_state when initializing BW limits Jonathan Cavitt
2026-09-21 19:25 ` ✓ i915.CI.BAT: success for " Patchwork
2026-09-22 3:55 ` ✗ i915.CI.Full: failure " Patchwork
2026-09-22 12:27 ` Imre Deak [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=arJ0FUdbC8ed5CuL@ideak-desk.lan \
--to=imre.deak@intel.com \
--cc=alex.zuo@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jonathan.cavitt@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox