From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()
Date: Thu, 1 Mar 2018 12:51:45 +0200 [thread overview]
Message-ID: <20180301105145.GS5453@intel.com> (raw)
In-Reply-To: <1519862553.2444.12.camel@dk-H97M-D3H>
On Wed, Feb 28, 2018 at 11:38:56PM +0000, Pandiyan, Dhinakaran wrote:
>
>
>
> On Wed, 2018-02-28 at 22:38 +0200, Ville Syrjälä wrote:
> > On Wed, Feb 28, 2018 at 10:28:13PM +0200, Ville Syrjälä wrote:
> > > On Sat, Feb 24, 2018 at 03:24:55AM +0000, Pandiyan, Dhinakaran wrote:
> > > >
> > > >
> > > >
> > > > On Mon, 2018-02-19 at 10:07 +0100, Maarten Lankhorst wrote:
> > > > > Op 16-02-18 om 20:27 schreef Pandiyan, Dhinakaran:
> > > > > > On Fri, 2018-02-16 at 08:55 +0000, Chris Wilson wrote:
> > > > > >> Quoting Dhinakaran Pandiyan (2018-02-16 04:33:21)
> > > > > >>> Preparing a framebuffer should not require a flush. _post_plane_update()
> > > > > >>> takes care of flushing when a flip is scheduled, this should be
> > > > > >>> sufficient for PSR and FBC.
> > > > > >> Makes sense.
> > > > > >>
> > > > > > I also think this might speed up the flips a bit by avoiding flushes.
> > > > > >
> > > > > >>> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > > > > >>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > >>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > >>> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > > > >> Also
> > > > > >> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > >> to validate the flow through atomic.
> > > > > >> -Chris
> > > > > >>
> > > > > Page flips used to do intel_frontbuffer_flip_prepare here, followed by intel_frontbuffer_flip_complete. I think it would make sense to change the patch to do that?
> > > > >
> > > >
> > > > I have no context why it was removed, I'll have to understand that
> > > > change and get back to you.
> > >
> > > Since we supposedly have hw nuke for both fbc and psr there doesn't seem
> > > to be much need to do anything for flips. I guess DRRS is the only
> > > thing that kinda needs it (not really, just avoids flipping with the
> > > slow timings). But I think DRRS should really be tied into the vblank
> > > stuff somehow so that we switch to the fast timings whenever a vblank
> > > interrupts are enabled.
> >
> > Oh, I guess VLV/CHV PSR is what would need this. To do that properly
> > (ie. main link off) I think we'd basically need to do a full modeset
> > when exiting PSR, so it should probably handled somewhere higher up
> > during modeset, and for other uses the frontbuffer tracking
> > should perhaps just schedule a work to do the full modeset.
> >
> The mention of "full modeset" got me thinking. I believe you said full
> modeset because the link needs to be trained on PSR exit if it was off.
> But, link off isn't supported on VLV/CHV
>
> else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> /* On VLV and CHV only standby mode is supported. */
> dev_priv->psr.link_standby = true;
I think that's just because we've been lazy and done it. I think even
with the link off we'd need to reprogram all planes at least.
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-03-01 10:51 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-16 4:33 [PATCH 1/5] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display Dhinakaran Pandiyan
2018-02-16 4:33 ` [PATCH 2/5] drm/i915/psr: Use more PSR HW tracking Dhinakaran Pandiyan
2018-02-16 8:54 ` Chris Wilson
2018-03-07 3:54 ` Pandiyan, Dhinakaran
2018-02-16 4:33 ` [PATCH 3/5] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags Dhinakaran Pandiyan
2018-02-16 4:33 ` [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb() Dhinakaran Pandiyan
2018-02-16 8:55 ` Chris Wilson
2018-02-16 19:27 ` Pandiyan, Dhinakaran
2018-02-19 9:07 ` Maarten Lankhorst
2018-02-24 3:24 ` Pandiyan, Dhinakaran
2018-02-28 20:28 ` Ville Syrjälä
2018-02-28 20:38 ` Ville Syrjälä
2018-02-28 23:38 ` Pandiyan, Dhinakaran
2018-03-01 10:51 ` Ville Syrjälä [this message]
2018-03-01 11:22 ` Ville Syrjälä
2018-03-01 18:35 ` Rodrigo Vivi
2018-03-01 18:43 ` Ville Syrjälä
2018-03-01 19:00 ` Rodrigo Vivi
2018-03-01 19:21 ` Pandiyan, Dhinakaran
2018-03-01 19:24 ` Ville Syrjälä
2018-02-16 4:33 ` [PATCH 5/5] drm/i915/psr: Wait for PSR transition to complete before exiting Dhinakaran Pandiyan
2018-02-16 8:58 ` Chris Wilson
2018-02-16 18:58 ` Pandiyan, Dhinakaran
2018-02-16 4:38 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display Patchwork
2018-02-16 4:54 ` ✓ Fi.CI.BAT: success " Patchwork
2018-02-16 8:52 ` [PATCH 1/5] " Chris Wilson
2018-02-16 19:22 ` Pandiyan, Dhinakaran
2018-02-16 11:55 ` ✓ Fi.CI.IGT: success for series starting with [1/5] " 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=20180301105145.GS5453@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=dhinakaran.pandiyan@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=paulo.r.zanoni@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