Re: [PATCH] drm: reduce default drm vblank off delay to 50ms

From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	airlied@redhat.com
Subject: Re: [PATCH] drm: reduce default drm vblank off delay to 50ms
Date: Tue, 8 Jul 2014 09:38:44 -0700	[thread overview]
Message-ID: <20140708093844.2b9894b3@jbarnes-desktop> (raw)
In-Reply-To: <20140708135604.GH17271@phenom.ffwll.local>

On Tue, 8 Jul 2014 15:56:04 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:

> On Wed, Jul 02, 2014 at 01:42:38PM -0700, Jesse Barnes wrote:
> > On Wed, 2 Jul 2014 13:35:19 -0700
> > Stéphane Marchesin <stephane.marchesin@gmail.com> wrote:
> > 
> > > On Tue, Oct 30, 2012 at 12:20 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > On Tue, Oct 30, 2012 at 8:09 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > > >> People keep whining about this, but no one seems to send a patch.  This
> > > >> *ought* to be safe now that we've dealt with the hw races in Mario's
> > > >> updated code, and fixed the bugs we know about in VT switch, DPMS, and
> > > >> multi-head configuraions.
> > > >>
> > > >> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> > > >
> > > > Afaik the fundamental race of enabling the vblank is still there, so
> > > > this is just duct-tape. And our hw has the required registers (on
> > > > gen5+ at least) to close this race for real and abolish all "disable
> > > > vblank irq later to paper over races and smooth things out). Hence I
> > > > think we should dtrt and so
> > > 
> > > [digging an old thread]
> > > 
> > > So I'm looking at this machine where we can't get good PSR residency
> > > because the vblank_offdelay is so long. Therefore, I'm suddenly very
> > > interested in solving this issue :) Of course I can't seem to find
> > > logs of the fun IRC discussion you guys had, can you describe what the
> > > race is, and also what are the registers you're talking about?
> > 
> > Beyond that I don't see why this obvious and simple improvement should
> > be blocked on some other work.  Maybe it's a bit late now since Ville
> > may already have patches for what Daniel mentions above, but I still
> > find the nack to be totally misguided.
> > 
> > Dave, please just pick this up so everyone can benefit while we thrash
> > through an i915 fix (doubtless introducing some bugs) that lets us
> > disable immediately.
> 
> This needs an ack from Mario.
> 
> And I really don't see why we _now_ need to suddenly rush then when we
> have patches from Ville to address this properly. The blocker is only that
> it's not yet reviewed but meh.
> 
> And people with product ship dates looming over their head can always just
> apply this themselves.
> 
> Us sucking at reviewing is imo no reason at all to rush patches in.

This is just the most recent version:
http://lists.freedesktop.org/archives/dri-devel/2012-October/029648.html

IIRC there was one posted back in 2010 too.  So hardly rushing.

-- 
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel