[Intel-gfx] [PATCH] drm/i915: Add a hotplug connector property

[Daniel Vetter]

On Mon, Jun 10, 2013 at 12:27 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> It is these machines that require the per-connector quirk to turn off
> hotplug detection anyway. And there are users that need to turn off all
> hotplug detection (hardware and polling) on certain connectors whilst
> plugged into their kvm.

I think it'd be useful to take one step back and lock at the intended
result (i.e. use-cases) a bit first, so cut out all the other
discussion.

Pondering this a bit more I see a bunch of things we could aim for:
- Giving userspace more rope to make even horribly broken systems
useful. We have the hpd storm stuff and the connector state forcing,
but atm the story is still imcomplete there I think. I guess it would
be useful to expose the connector->force attribute (maybe through
sysfs, tends to be easier to set correctly with scripts), so that
users with really flaky hw could update the forced state at runtim.
Then we could make the EDID firmware loading a bit more flexible
(again maybe expose the firmware filename in sysfs per-connector) and
users would be able to fake any setup. The last missing puzzle piece
would be to add a new FORCE_INTEGRATED mode which also eschews the
repeated ->get_modes calls when ->num_modes > 0 or so.

- Allowing some fine-tuning of the hpd storm detection engine. Since
we don't yet have much real-world usage data I'm not sure what we
could want here, so probably best to postpone for now.

- Disabling polling. Presuming we have the pimped connector forcing
infrastructure described above I'm not sure whether we really need
more than what the global tunable already affords us. Thanks to
locking reworks and a few other things the poll work is really
unobtrusive nowadays (especially if all outputs claim to support
hotplug).

- Better caching of EDID data and connector state. My favourite
approach for this would be some opportunistic caching for e.g. 1
second in the ->fill_modes callback. Hotplug interrupts would
invalidate the caching (and since we already filter hotplug interrupts
to only touch relevant outputs with Egbert's latest patches, that
should be fairly good). Of course caching the edid like this in a
reality with horribly unreliable hpd will add new races and
inconsistencies between reality and what the kernel reports. But in
those cases hotplug reporting is already horribly racy, so not really
a real degration. Like the poll intervall we could make that tuneable.

- Full EDID caching when the hotplug interrupt is actually reliable. I
think that this is the case for native DP outputs, at least I'm not
aware of any bug report. And maybe we'll figure out the few holdouts
for HDMI hpd handling. If we have the opportunistic caching
infrastructure from the previous point we could simply disable the
time-based invalidation for those, and only invalidate the
edid/connector state on a hotplug event. But even for DP I think it's
better if the kernel is in charge of setting this, since e.g. plugging
in a DP->VGA converter means that we need to disable full caching and
switch back to opportunistic caching. And then back again if a native
DP monitor is plugged in.

Hopefully this dump here is useful to broaden the discussion a bit. Thoughts?

Cheers, Daniel

--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch