Summary: | hotplug probing unconditionally checks all connectors | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Tvrtko Ursulin <tvrtko.ursulin> | ||||||
Component: | DRM/Intel | Assignee: | Daniel Vetter <daniel> | ||||||
Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
Severity: | normal | ||||||||
Priority: | medium | CC: | ben, chris, daniel, jbarnes, linuxhippy | ||||||
Version: | unspecified | ||||||||
Hardware: | All | ||||||||
OS: | Linux (All) | ||||||||
Whiteboard: | |||||||||
i915 platform: | i915 features: | ||||||||
Attachments: |
|
Description
Tvrtko Ursulin
2012-05-14 06:07:01 UTC
Created attachment 61612 [details] [review] Skip periodic probes if we have a hotplug-driven system Step 1 is to reduce the frequency of the polling. (In reply to comment #1) > Created attachment 61612 [details] [review] [review] > Skip periodic probes if we have a hotplug-driven system This won't work well in the field where VGA over DVI-I is used with cheap adapters which do not wire the HPD pin. > Step 1 is to reduce the frequency of the polling. Reduce as in eliminate or I am misreading it? :) If we don't specify that the connector is polled for CONNECTION/DISCONNECTION, then any current probing performed by the periodic helper is a bug. So from that pov, we aren't actually modifying existing behaviour (except for papering over a bug in the core) and just disabling the unused timer. However, I think the helper is buggy and so we are seeing unwanted polling of HPD connectors. Would you like me to test this patch, or it is to trivial? On a related note, what is the other thing which runs every ten seconds after output_poll_execute finishes? I have a situation on a different hardware where only that part runs every ten seconds, identical to lines from 438.402623 and below. X seems to be triggering that. But end result it it re-fetches EDID on the connected outputs which again results in glitching. (In reply to comment #4) > On a related note, what is the other thing which runs every ten seconds after > output_poll_execute finishes? I have a situation on a different hardware where > only that part runs every ten seconds, identical to lines from 438.402623 and > below. X seems to be triggering that. But end result it it re-fetches EDID on > the connected outputs which again results in glitching. Please disregards, it was an unrelated process doing this probing which I failed to identify and stop while doing the testing in a stripped down environment. (In reply to comment #4) > Would you like me to test this patch, or it is to trivial? If you can verify that it does what it says on the tin, that will be most helpful, thanks. Works as designed. But it also regresses when you switch video connectors - I just switched HDMI to VGA and it did not initialise it. Strange, I am pretty sure I was getting HPD events on this board. I have to inject some debug to be sure... Created attachment 62017 [details] [review] fixup polling for hotplug pins Chris' patch will break hotplug detection, so here's a new try. Please test (and if you can, please also check whether hotplug (and unplug) detection still works, i.e. whether the xrandr gui configuration tool of your desktop still pops up). Hmm.. the code is a bit confusing. I think the culprit is in this snippet: void drm_helper_hpd_irq_event(struct drm_device *dev) { if (!dev->mode_config.poll_enabled) return; dev->mode_config.poll_enabled is not set to true unless you call drm_kms_helper_poll_init and HPD events of course do not work. It feels strange to have this check in drm_helper_hpd_irq_event since it is not about polling. Perhaps the check should be removed? (In reply to comment #9) > Created attachment 62017 [details] [review] [review] > fixup polling for hotplug pins > > Chris' patch will break hotplug detection, so here's a new try. Please test > (and if you can, please also check whether hotplug (and unplug) detection still > works, i.e. whether the xrandr gui configuration tool of your desktop still > pops up). Who will now call connector->funcs->detect for HPD capable connectors, is that not necessary or I am missing something? Ok, I don't understand at all why that hotplug loop even gets run for your system every 10s. Can you please attach xrandr --verbose and full dmesg with drm.debug=0xe added to your kernel cmdline? Yeah, Dave Airlie arleady pointed out that not calling ->detect will break fbcon a bit. Userspace should be calling detect on all connectors already when getting a hotplug uevent, so that should work. Hence test this patch anyway, please. Loop doesn't run right now, it used to when we had "video=DP-3:d" passed to the kernel (see bug 49907). I think it was more a trigger on the wider topic on why all connectors are re-probed on a HPD event. (In reply to comment #13) > Yeah, Dave Airlie arleady pointed out that not calling ->detect will break > fbcon a bit. Userspace should be calling detect on all connectors already when > getting a hotplug uevent, so that should work. Hence test this patch anyway, > please. What if there is no userspace, and with that I mean no X? I don't think code should regress in that case. Ok, so the 10s loop was just due to broken userspace, and the issue here is that we run ->detect on all hotplug pins. Adjusting bug summary accordingly. *** Bug 26845 has been marked as a duplicate of this bug. *** Self-correction: The 10s loop is due to bug #49907 Spurious polling should be fixed in 3.8 (you can grab the patches from the drm-next git tree). Specifically for this case here: 905bc9ff6575f78aab24c0261e8785425b5a0397 drm: don't start the poll engine in probe_single_connector 69787f7da6b2adc4054357a661aaa1701a9ca76f drm: run the hpd irq event code directly 816da85a0990c2b52cfffa77637d1c770d6790e9 drm: handle HPD and polled connectors separately |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.