From: "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix mistake in intel_modeset_all_pipes condition
Date: Wed, 9 Aug 2023 12:07:49 +0300 [thread overview]
Message-ID: <ZNNXZYeTNdZVYalP@intel.com> (raw)
In-Reply-To: <87o7jgsi6y.fsf@intel.com>
On Wed, Aug 09, 2023 at 12:01:25PM +0300, Jani Nikula wrote:
> On Wed, 09 Aug 2023, "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com> wrote:
> > On Wed, Aug 09, 2023 at 11:38:08AM +0300, Jani Nikula wrote:
> >> On Wed, 09 Aug 2023, Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> wrote:
> >> > It is supposed to be "!intel_crtc_needs_modeset" - otherwise,
> >> > we are active exactly vice versa for active pipes: skipping if modeset
> >> > is needed and not skipping if not needed.
> >>
> >> If the crtc *already* needs a full modeset, there's no need to force a
> >> modeset on it.
> >>
> >> BR,
> >> Jani.
> >
> > We have curently some issue with that. There are multiple places from where
> > intel_modeset_all_pipes is called. One is that when we do detect that mbus join
> > state had changed. All the previous checks indicated that fastset is enough,
> > however once we detect mbus join state had changed in skl_watermarks.c we call
> > this function there as well and I think it might act in a wrong way then.
> >
> > So basically this condition checks whether we need to force a modeset, but not
> > if we need it, so no crtc's are supposed to escape this?
> > Could be then that we just calling that whole function there wrongly.
>
> Simplified, it's an optimization of:
>
> if (crtc_state->uapi.mode_changed)
> continue;
>
> crtc_state->uapi.mode_changed = true;
>
> With your change, it becomes:
>
> if (!crtc_state->uapi.mode_changed)
> continue;
>
> crtc_state->uapi.mode_changed = true;
>
> and intel_modeset_all_pipes() roughly becomes a no-op.
Okay, basically I was wrong in interpretation of intel_modeset_all_pipes - mine was that it is
supposed to modeset only pipes, which actually _need_ a full modeset, while the real one is supposed
to force a modeset on those which even don't need that.
Regarding mbus join, I think it could be just wrong to call it there rightaway.
Most likely we can live with fastset there, unless ddb allocations haven't changed(we could then just
update the mbus join state)
Stan
>
>
> BR,
> Jani.
>
> >
> > Stan
> >
> >>
> >> >
> >> > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> >> > ---
> >> > drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> >> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> >> > index 763ab569d8f32..4b1d7034078ca 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> >> > @@ -5439,7 +5439,7 @@ int intel_modeset_all_pipes(struct intel_atomic_state *state,
> >> > return PTR_ERR(crtc_state);
> >> >
> >> > if (!crtc_state->hw.active ||
> >> > - intel_crtc_needs_modeset(crtc_state))
> >> > + !intel_crtc_needs_modeset(crtc_state))
> >> > continue;
> >> >
> >> > drm_dbg_kms(&dev_priv->drm, "[CRTC:%d:%s] Full modeset due to %s\n",
> >>
> >> --
> >> Jani Nikula, Intel Open Source Graphics Center
>
> --
> Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2023-08-09 9:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-09 8:29 [Intel-gfx] [PATCH] drm/i915: Fix mistake in intel_modeset_all_pipes condition Stanislav Lisovskiy
2023-08-09 8:38 ` Jani Nikula
2023-08-09 8:48 ` Lisovskiy, Stanislav
2023-08-09 9:01 ` Jani Nikula
2023-08-09 9:07 ` Lisovskiy, Stanislav [this message]
2023-08-09 9:31 ` Jani Nikula
2023-08-09 9:50 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2023-08-09 9:50 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-08-09 10:02 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
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=ZNNXZYeTNdZVYalP@intel.com \
--to=stanislav.lisovskiy@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.