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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox