On Wed, 5 Sep 2012 12:50:26 -0700 Jesse Barnes <jbarnes at virtuousgeek.org> wrote: > On Wed, 5 Sep 2012 21:48:52 +0200 > Daniel Vetter <daniel.vetter at ffwll.ch> wrote: > > > On Wed, Sep 5, 2012 at 8:28 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote: > > > > > > The variables have me confused a little... I would have expected > > > update_state to take modeset_pipes rather than prepare_pipes. Could > > > you use either? Or will that not catch cases where we updated a pipe > > > that was already on? > > > > The abstract idea for these masks was the following: Any pipe that > > changes anything goes into prepare_pipes. For any pipe that also > > changes the mode, it goes in addition into the modeset_pipes mask, so > > the later is a subset of prepare pipes. The idea here was to avoid the > > modeset step where not necessary (e.g. when disabling the 2nd output > > of a cloned crtc we only need to disable/enable, not change anything > > with the mode or clocks). But after some in-depth discussion with > > Paulo Zanoni I think we'll move large parts of the mode_set step into > > the enable function (at least for hsw due to funky ordering > > requirements), so I think this disdinction doesn't make sense. > > > > The disable mask just contains those pipes that get fully disable (and > > which then also get removed from the prepares/modset masks). > > > > Hence I pass the prepares mask into update_states, not just the modeset mask. > > Ok, that makes some sense. Hopefully we can preserve the full mode set > vs simple update behavior even after the refactoring for HSW. > Reviewed-by: Jesse Barnes <jbarnes at virtuousgeek.org> -- Jesse Barnes, Intel Open Source Technology Center
