2014/1/16 Daniel Vetter <daniel.vetter@xxxxxxxx>: > On Thu, Jan 16, 2014 at 4:24 PM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: >> Currently we're doing the reset handling a bit late, and we're doing >> it both in the driver load code and on resume. This makes it unusable >> for e.g. resetting the panel power sequence state like Paulo wants to. >> >> Instead of adding yet another single-use callback shuffle things >> around: >> - Output handling code is responsible to reset/init all state on its >> own at driver load time. >> - We call the reset functions much earlier, before we start using any >> of the modeset code. >> >> Compared to Paulo's new ->resume callback the only difference in >> placement is that ->reset is still called without dev->struct_mutex >> held. Which is imo a feature. >> >> Cc: Paulo Zanoni <przanoni@xxxxxxxxx> >> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > I've forgotten to mention: The LVDS restore code also wants these > semantics when we move the register restoring into intel_lvds.c. That doesn't apply on -nightly because of "drm/i915: Do not clobber config status after a forced restore of hw state", which is on -fixes. If I try to review this patch as-is, thinking that at some point we'll merge -fixes back into -next-queued, I keep wondering what your conflict resolution will look like. So could you please provide a patch on top of -nightly, so I can try to rewrite the enable_pipe patches on top of everything? Thanks, Paulo > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Paulo Zanoni _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
