From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Souza, Jose" <jose.souza@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"De Marchi, Lucas" <lucas.demarchi@intel.com>
Subject: Re: [Intel-gfx] [PATCH v4 5/6] drm/i915/display: Check if pipe fastset is allowed by external dependencies
Date: Fri, 20 Dec 2019 14:58:53 +0200 [thread overview]
Message-ID: <20191220125853.GI1208@intel.com> (raw)
In-Reply-To: <e7beb2ca3c2aef85e22876671860ca51584d29ee.camel@intel.com>
On Thu, Dec 19, 2019 at 08:39:26PM +0000, Souza, Jose wrote:
> On Wed, 2019-12-18 at 20:33 +0000, Souza, Jose wrote:
> > On Wed, 2019-12-18 at 22:26 +0200, Ville Syrjälä wrote:
> > > On Wed, Dec 18, 2019 at 08:19:15PM +0000, Souza, Jose wrote:
> > > > On Wed, 2019-12-18 at 21:39 +0200, Ville Syrjälä wrote:
> > > > > On Wed, Dec 18, 2019 at 10:59:09AM -0800, José Roberto de Souza
> > > > > wrote:
> > > > > > Check if fastset is allowed by external dependencies like
> > > > > > other
> > > > > > pipes
> > > > > > and transcoders.
> > > > > >
> > > > > > Right now this patch only forces a fullmodeset in MST slaves
> > > > > > of
> > > > > > MST
> > > > > > masters that needs a fullmodeset but it will be needed for
> > > > > > port
> > > > > > sync
> > > > > > as well.
> > > > > >
> > > > > > v3:
> > > > > > - moved handling to intel_atomic_check() this way is
> > > > > > guarantee
> > > > > > that
> > > > > > all pipes will have its state computed
> > > > > >
> > > > > > v4:
> > > > > > - added a function to return if MST master neeeds modeset to
> > > > > > simply
> > > > > > code in intel_atomic_check()
> > > > > >
> > > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > Cc: Manasi Navare <manasi.d.navare@intel.com>
> > > > > > Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/display/intel_display.c | 53
> > > > > > +++++++++++++++-
> > > > > > ----
> > > > > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 14 ++++++
> > > > > > drivers/gpu/drm/i915/display/intel_dp_mst.h | 3 ++
> > > > > > 3 files changed, 57 insertions(+), 13 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > index a4f252d05b37..2a406891567b 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > @@ -13903,19 +13903,6 @@ static void
> > > > > > intel_crtc_check_fastset(const
> > > > > > struct intel_crtc_state *old_crtc_sta
> > > > > >
> > > > > > new_crtc_state->uapi.mode_changed = false;
> > > > > > new_crtc_state->update_pipe = true;
> > > > > > -
> > > > > > - /*
> > > > > > - * If we're not doing the full modeset we want to
> > > > > > - * keep the current M/N values as they may be
> > > > > > - * sufficiently different to the computed values
> > > > > > - * to cause problems.
> > > > > > - *
> > > > > > - * FIXME: should really copy more fuzzy state here
> > > > > > - */
> > > > > > - new_crtc_state->fdi_m_n = old_crtc_state->fdi_m_n;
> > > > > > - new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
> > > > > > - new_crtc_state->dp_m2_n2 = old_crtc_state->dp_m2_n2;
> > > > > > - new_crtc_state->has_drrs = old_crtc_state->has_drrs;
> > > > > > }
> > > > > >
> > > > > > static int intel_crtc_add_planes_to_state(struct
> > > > > > intel_atomic_state *state,
> > > > > > @@ -14083,6 +14070,46 @@ static int intel_atomic_check(struct
> > > > > > drm_device *dev,
> > > > > > any_ms = true;
> > > > > > }
> > > > > >
> > > > > > + /**
> > > > > > + * Check if fastset is allowed by external dependencies
> > > > > > like
> > > > > > other
> > > > > > + * pipes and transcoders.
> > > > > > + *
> > > > > > + * Right now it only forces a fullmodeset when the MST
> > > > > > master
> > > > > > + * transcoder did not changed but the pipe of the
> > > > > > master
> > > > > > transcoder
> > > > > > + * needs a fullmodeset so all slaves also needs to do a
> > > > > > fullmodeset.
> > > > > > + */
> > > > > > + for_each_new_intel_crtc_in_state(state, crtc,
> > > > > > new_crtc_state,
> > > > > > i) {
> > > > > > + enum transcoder master = new_crtc_state-
> > > > > > > mst_master_transcoder;
> > > > > > +
> > > > > > + if
> > > > > > (!intel_dp_mst_is_slave_trans(new_crtc_state) ||
> > > > > > + needs_modeset(new_crtc_state))
> > > > > > + continue;
> > > > > > +
> > > > > > + if
> > > > > > (intel_dp_mst_master_trans_needs_modeset(state,
> > > > > > master)) {
> > > > >
> > > > > I think this has the loops the opposite way of what I was
> > > > > thinking,
> > > > > but should work fine I think... OK. I'm convinced your way is
> > > > > in
> > > > > fact
> > > > > better.
> > > > >
> > > > > > + new_crtc_state->uapi.mode_changed =
> > > > > > true;
> > > > > > + new_crtc_state->update_pipe = false;
> > > > > > + }
> > > > > > + }
> > > > > > +
> > > > > > + for_each_oldnew_intel_crtc_in_state(state, crtc,
> > > > > > old_crtc_state,
> > > > > > + new_crtc_state, i)
> > > > > > {
> > > > > > + if (needs_modeset(new_crtc_state))
> > > > > > + continue;
> > > > >
> > > > > I suppose there isn't any way we should have crtcs in the state
> > > > > that
> > > > > neither have update_pipe or needs_modeset flagged here. Could
> > > > > maybe
> > > > > WARN_ON(!update_pipe) here if we're being paranoid.
> > > >
> > > > Adding the WARN_ON
>
> Ah we can't add this WARN_ON(), is most atomic states the previous CRTC
> states is added even if it dont need any modification.
>
> Those are handled here:
>
> for_each_oldnew_intel_crtc_in_state(state, crtc,
> old_crtc_state,
> new_crtc_state, i) {
> if (!needs_modeset(new_crtc_state)) {
> /* Light copy */
> intel_crtc_copy_uapi_to_hw_state_nomodeset(new_
> crtc_state);
>
> continue;
> }
After further consideration we only want the copy for fastset crtcs
(ie. ones with update_pipe==true). Crtcs added for pure plane updates
should not do the copy (well, in that case the old and new states
really should match, but I still think it's a bit dubious). So
I guess we should check for '!needs_modeset() && update_pipe'.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-12-20 12:58 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-18 18:59 [Intel-gfx] [PATCH v4 1/6] drm/i915/display: Share intel_connector_needs_modeset() José Roberto de Souza
2019-12-18 18:59 ` [Intel-gfx] [PATCH v4 2/6] drm/i915/tgl: Select master transcoder for MST stream José Roberto de Souza
2019-12-18 19:24 ` Ville Syrjälä
2019-12-18 20:06 ` Souza, Jose
2019-12-18 20:16 ` Ville Syrjälä
2019-12-18 18:59 ` [Intel-gfx] [PATCH v4 3/6] drm/i915/display: Always enables MST master pipe first José Roberto de Souza
2019-12-18 19:27 ` Ville Syrjälä
2019-12-18 18:59 ` [Intel-gfx] [PATCH v4 4/6] drm/i915/dp: Fix MST disable sequences José Roberto de Souza
2019-12-18 20:08 ` Ville Syrjälä
2019-12-18 21:25 ` Souza, Jose
2019-12-18 21:33 ` Ville Syrjälä
2019-12-18 18:59 ` [Intel-gfx] [PATCH v4 5/6] drm/i915/display: Check if pipe fastset is allowed by external dependencies José Roberto de Souza
2019-12-18 19:39 ` Ville Syrjälä
2019-12-18 20:11 ` Ville Syrjälä
2019-12-18 20:19 ` Souza, Jose
2019-12-18 20:26 ` Ville Syrjälä
2019-12-18 20:33 ` Souza, Jose
2019-12-19 20:39 ` Souza, Jose
2019-12-20 12:58 ` Ville Syrjälä [this message]
2019-12-18 20:41 ` Manasi Navare
2019-12-18 20:57 ` Souza, Jose
2019-12-18 23:45 ` Manasi Navare
2019-12-18 18:59 ` [Intel-gfx] [PATCH v4 6/6] drm/i915/display: Add comment to a function that probably can be removed José Roberto de Souza
2019-12-18 21:12 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v4,1/6] drm/i915/display: Share intel_connector_needs_modeset() 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=20191220125853.GI1208@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jose.souza@intel.com \
--cc=lucas.demarchi@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.