On Mon, Apr 8, 2013 at 2:28 PM, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > On Sat, Apr 6, 2013 at 12:05 PM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: >> When inlining the actual hpd output probing in >> >> commit 69787f7da6b2adc4054357a661aaa1701a9ca76f >> Author: Daniel Vetter <daniel.vetter@xxxxxxxx> >> Date: Tue Oct 23 18:23:34 2012 +0000 >> >> drm: run the hpd irq event code directly >> >> the check for the drm_kms_hlper.poll module option was lost. This >> regressed systems where this option is used to work-around output >> probing issues (like irq storms). Restore the old behaviour. > > NAK. It's been a while since I looked at it, but the whole point of > this patch set was to be able to disabling polling independently of > hpd. If you add this check back, setting poll=0 disables both polling > and hpd. I'd suggest we add a separate hpd option to disable hpd. The point for me was that the _driver_ can separate hpd handling from polling. Which it still can with this patch applied. The issue at hand is that the old poll=0 also managed to paper over some hpd handling irq storms and so breaking that is a regression. To fix that we should imo apply this patch. We can revert this again once i915 has the hpd irq storm rate-limiting stuff applied (presuming there's no other bug report for other drivers). Also in 3.9 we have the reworked kms locking, so the usual reason that polling causes cursor/pageflip stalls to set poll=0 evaporated. So imo the only people who should still set poll=0 on 3.9 are those with irq storms. And we've just broken that part ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html