On Wed, Sep 5, 2012 at 6:45 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> On Sun, 19 Aug 2012 21:12:56 +0200
> Daniel Vetter <daniel.vetter at ffwll.ch> 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 <daniel.vetter at ffwll.ch>
>> ---
>> 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
daniel.vetter at ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
