From my reading of drm_kms_helper_poll and friends, this shouldn't make a difference, we should always be kicking off the 10s probe. Can you attach a drm.debug=6 dmesg for both with and without the video=:d?

Created attachment 61618 [details]
Kernel booted into console mode with defaults - no polling

Created attachment 61619 [details]
Kernel booted into console mode with a connector disable - polling runs

Oops, second log (connector disabled) actually is a cumulative log - so please look from the end of it, last boot is the relevant one.

With "video=DP-3:d", DP-3 status keeps oscillating between connected and disconnected.

First output_poll_execute calls connector->detect on it which says it is connected. Then because connector status has changed, this runs:

	if (changed) {
		/* send a uevent + call fbdev */
		drm_sysfs_hotplug_event(dev);
		if (dev->mode_config.funcs->output_poll_changed)
			dev->mode_config.funcs->output_poll_changed(dev);
	}

This calls drm_fb_helper_hotplug_event, then drm_helper_probe_single_connector_modes runs and again calls:

 1. connector->detect which this time says DP-3 is connected
 2. calls drm_kms_helper_poll_enable which re-arms output_poll_execute

And so on the loop continues.

So I guess root cause is connector status oscillating between connected and disconnected when "video=DP-3:d" is passed in.

Even rootier cause might be why is DP-3 in the connector table in the first place if kernel was told to ignore it?

Hm, that call to drm_kms_helper_poll_enable in drm_helper_probe_single_connector_modes looks pretty superflous. I guess we could just kill that.

Please test my hdp-mess branch from my personal git repo:

http://cgit.freedesktop.org/~danvet/drm/log/?h=hdp-mess
git://people.freedesktop.org/~danvet/drm

That should have patches to at least solve this problem here.

This looks good.

I've tested booting into fbcon on different connectors:

 * booting
 * repluging to the same connector
 * replugging to a different connector
 * replugging to another different connector

Between these connectors: HDMI, VGA over DVI-I and VGA over DVI-I with no HPD pin.

In all cases it got EDID and display came up fine.

Seems HPD pin is not critical for VGA hotplug on Intel hardware, I guess you do load detect for it which is nice.

output_poll_execute did not run in any test case.

"video=DP-3:d" did not change behaviour.

Only thing I did not test, which I could have on this board, is DVI-D over DVI-I, but I suppose it should behave similarly to HDMI meaning it most likely work just fine.

Break radeon unfortunately. Booted into fbcon with DVI-D over DVI-I fine, re-plugged the connector and it doesn't come up. This gets logged:

[  143.218100] [drm:drm_helper_hpd_irq_event], [CONNECTOR:13:DP-1] status updated from 2 to 2
[  143.219322] [drm:radeon_atombios_connected_scratch_regs], DFP2 disconnected
[  143.219336] [drm:radeon_atombios_connected_scratch_regs], CRT1 disconnected
[  143.219345] [drm:drm_helper_hpd_irq_event], [CONNECTOR:15:DVI-I-1] status updated from 2 to 2

I suspect HPD fired before I2C was possible to fetch EDID and the patch set possible removed the subsequent retry which would happen by scheduling the poll loop?

On deeper investigation it transpires radeon was broken in fbcon even before this patch series.

Polling should be fixed up now in 3.8 (you can grab the patches from the drm-next branch). Specifically:

commit 11e686855c81c2e5e647b3dcfabd2a4e473c46f0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Oct 23 18:23:38 2012 +0000

    drm: don't poll forced connectors

A patch referencing this bug report has been merged in Linux v3.8-rc1:

commit 905bc9ff6575f78aab24c0261e8785425b5a0397
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Oct 23 18:23:36 2012 +0000

    drm: don't start the poll engine in probe_single_connector