On Tue, 4 Sep 2012 21:33:22 +0200 Daniel Vetter <daniel.vetter at ffwll.ch> wrote: > Passing in the old fb, having overwritten the current fb, leads to > some neatly convoluted code. It's much simpler if we defer the > crtc->fb update to the place that updates the hw, in pipe_set_base. > This way we also don't need to restore anything in case something > fails - we only update crtc->fb once things have succeeded. > > The real reason for this change is that now we keep the old fb > assigned to crtc->fb, which allows us to finally move the crtc disable > case into the common low-level set_mode function in the next patch. > > Also don't clobber crtc->x and crtc->y, we neatly pass these down the > callchain already. Unfortunately we can't do the same with crtc->mode, > because that one is being used in the mode_set callbacks. > > v2: Don't restore the drm_crtc object any more on failed modesets, > since we've lose an fb reference otherwise. Also (and this is the > reason this has been found), this totally confused the modeset state > tracking, since it clobbers crtc->enabled. Issue reported by Paulo > Zanoni. Ok obviously missed the leak. Reviewed-by: Jesse Barnes <jbarnes at virtuousgeek.org> -- Jesse Barnes, Intel Open Source Technology Center
