[Intel-gfx] [PATCH] drm/kms-helper: disable hpd_irq handling when poll=0
Daniel Vetter
daniel.vetter at ffwll.ch
Mon Apr 8 14:43:01 CEST 2013
On Mon, Apr 8, 2013 at 2:28 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
> On Sat, Apr 6, 2013 at 12:05 PM, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
>> When inlining the actual hpd output probing in
>>
>> commit 69787f7da6b2adc4054357a661aaa1701a9ca76f
>> Author: Daniel Vetter <daniel.vetter at ffwll.ch>
>> 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
More information about the Intel-gfx
mailing list