On Wed, Sep 5, 2012 at 6:45 PM, Jesse Barnes <[email protected]> wrote: > On Sun, 19 Aug 2012 21:12:56 +0200 > Daniel Vetter <[email protected]> wrote: > >> Yikes! >> >> But yeah, we have to do this until someone volunteers to clean up the >> fb helper and rid it of its incetious relationship with the crtc >> helper code. >> >> Signed-off-by: Daniel Vetter <[email protected]> >> --- >> drivers/gpu/drm/i915/intel_display.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/intel_display.c >> b/drivers/gpu/drm/i915/intel_display.c >> index 3cedc89..4b2b17f 100644 >> --- a/drivers/gpu/drm/i915/intel_display.c >> +++ b/drivers/gpu/drm/i915/intel_display.c >> @@ -6933,6 +6933,12 @@ static int intel_crtc_set_config(struct drm_mode_set >> *set) >> if (!set->mode) >> set->fb = NULL; >> >> + /* The fb helper likes to play gross jokes with ->mode_set_config. >> + * Unfortunately the crtc helper doesn't do much at all for this case, >> + * so we have to cope with this madness until the fb helper is fixed >> up. */ >> + if (set->fb && set->num_connectors == 0) >> + return 0; >> + >> if (set->fb) { >> DRM_DEBUG_KMS("[CRTC:%d] [FB:%d] #connectors=%d (x y) (%i >> %i)\n", >> set->crtc->base.id, set->fb->base.id, > > I wonder if this belongs earlier in the series? But either way:
This one here should be right - we still implement the disable path like the crtc helper, so we automatically implement the semantics the fb helper expects. Only later patches need that. But you're right that some of the later bugfixes that I've added might slightly break bisect - I've tried hard to put them at the right spot, but maybe I've mislaid one ... Especially fixups like these to implement brain-dead crtc helper semantics are tricky to reason about :( -Daniel -- Daniel Vetter [email protected] - +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
