[PATCH 2/2] drm/crtc-helper: clamp unknown connector status in the poll work

[Daniel Vetter]

On Thu, Jun 6, 2013 at 9:49 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Thu, Jun 06, 2013 at 12:17:26AM +0200, Daniel Vetter wrote:
>> On some chipset we try to avoid possibly invasive output detection
>> methods (like load detect which can cause flickering elsewhere) in the
>> output poll work. Drivers could hence return unknown when a previous
>> full ->detect call returned a different state.
>>
>> This change will generate a hotplug event, forcing userspace to do a
>> full scan. This in turn updates the connector->status field so that we
>> will _again_ get a state change when the hotplug work re-runs in 10
>> seconds.
>>
>> To avoid this ping-pong loop detect this situation and clamp the
>> connector state to the old value.
>>
>> Patch is inspired by a patch from Knut Peterson. Knut's patch
>> completely ignored connector state changes if either the old or new
>> status was unknown, which seemed to be a bit too agressive to me.
>>
>> References: http://lists.freedesktop.org/archives/dri-devel/2012-August/025975.html
>> Cc: Knut Petersen <Knut_Petersen at t-online.de>
>> Cc: Alex Deucher <alexander.deucher at amd.com>
>> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>
> Also Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
>
> I don't think this has any effect for i915, the circumstances where it
> might we return connector->status rather than Unknown, so we need some
> input from nouveau/radeon/architect as to our sanity.

Hm, now I'm confused. The case I've had in mind indeed already works
on i915.ko, but Knut's bug report was on a i915gm. The only place
where we return unknown is when force==true and we can't get a load
detect pipe. That shouldn't be able to ping-pong ...

Knut, can you please shed some clue on me here?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch