On Mon, Apr 8, 2013 at 2:28 PM, Alex Deucher alexdeucher@gmail.com wrote:
On Sat, Apr 6, 2013 at 12:05 PM, Daniel Vetter daniel.vetter@ffwll.ch wrote:
When inlining the actual hpd output probing in
commit 69787f7da6b2adc4054357a661aaa1701a9ca76f Author: Daniel Vetter daniel.vetter@ffwll.ch Date: Tue Oct 23 18:23:34 2012 +0000
drm: run the hpd irq event code directlythe 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