On Tue, 8 Jul 2014 15:56:04 +0200 Daniel Vetter <daniel@xxxxxxxx> 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@xxxxxxxxx> wrote: > > > > > On Tue, Oct 30, 2012 at 12:20 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > > > > On Tue, Oct 30, 2012 at 8:09 PM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx> > > > > > > > > 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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel