On Fri, Feb 22, 2013 at 04:36:38PM +0200, Ville Syrjälä wrote: > On Fri, Feb 22, 2013 at 01:31:35PM +0000, Chris Wilson wrote: > > On Fri, Feb 22, 2013 at 02:17:24PM +0200, [email protected] > > wrote: > > > From: Ville Syrjälä <[email protected]> > > > > > > Point crtc->fb the the new framebuffer only after we know that the flip > > > was succesfully queued. > > > > > > While at it, move the intel_fb and obj assignments a bit close to where > > > they're used. > > > > > > Cc: [email protected] > > > Signed-off-by: Ville Syrjälä <[email protected]> > > > > Hmm, that exposes us to a FlipDone interrupt seeing the old crtc->fb. > > That looks safe enough, but can you see how ugly restoring the old_fb > > looks in comparison? > > I don't think anyone should be poking at crtc->fb w/o holding the crtc > mutex. Except that intel_update_fbc() actually does. That thing would > appear to be just broken since it crawls around in the crtc state w/o > proper protection. The fb could even disappear from under it.
You'll find not a lot of argument from me here, just suggesting that we avoid the semantic change unless we are confident there are no surprises. > But if you prefer the set/restore approach I'll send out a version > doing that. I think I would prefer that approach for stable@ -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
