Nouveau - May 2013 - Commit "drm: run the hpd irq event code directly" causes stutter from repeated EDID retrievals

On Sun, May 26, 2013 at 5:38 PM, Gard Spreemann <gspreemann at gmail.com>
wrote:
> Hi,
>
> If I should contact a list instead of you directly, I sincerely apologize!
You should have cc'ed relevant lists at least ;-) Fixed up.
> After a recent kernel upgrade, I found that my system (using Nouveau) would
> stutter whenever eDP-1 was turned off. That display being turned off
apparently
> causes repeated EDID retrievals and failed checksums. I did a git bisect
which
> lead me to
> ***
> 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
>
>     All drivers already have a work item to run the hpd code, so we
don't
>     need to launch a new one in the helper code. Dave Airlie mentioned
>     that the cancel+re-queue might paper over DP related hpd ping-pongs,
>     hence why this is split out.
>
>     Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>     Reviewed-by: Alex Deucher <alexander.deucher at amd.com>
>     Signed-off-by: Dave Airlie <airlied at redhat.com>
> ***
> as the first bad commit, and I was advised to contact you as well as file a
bug
> with the Nouveau project [1].
>
> I don't have enough insight into the code in question to understand the
> problem, but your discussion on April 6 [2] seems relevant.
>
> Please let me know if there's anything I can do to help.
>
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=64858
> [2] https://patchwork.kernel.org/patch/2402211/
My guess is that you've worked around these edid stalls with
drm_kms_helper.poll=0 and the above commit breaks that w/a. That patch
was shot down unfortunately. If you can't reproduce these stalls on
older kernels when removing the poll=0 option, then something else
broke.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

On Sunday 26 May 2013 18:14:06 Daniel Vetter wrote:
> My guess is that you've worked around these edid stalls with
> drm_kms_helper.poll=0 and the above commit breaks that w/a. That patch
> was shot down unfortunately. If you can't reproduce these stalls on
> older kernels when removing the poll=0 option, then something else
> broke.
You are correct. Before that commit, the stuttering behavior is present with 
poll=1, but not with poll=0. Starting with that commit, the behavior is 
present nomatter the poll setting.

Am I correct in thinking that this is a problem without a clear solution?

- Gard

On Sun, May 26, 2013 at 6:25 PM, Gard Spreemann <gspreemann at gmail.com>
wrote:
> On Sunday 26 May 2013 18:14:06 Daniel Vetter wrote:
>> My guess is that you've worked around these edid stalls with
>> drm_kms_helper.poll=0 and the above commit breaks that w/a. That patch
>> was shot down unfortunately. If you can't reproduce these stalls on
>> older kernels when removing the poll=0 option, then something else
>> broke.
>
> You are correct. Before that commit, the stuttering behavior is present
with
> poll=1, but not with poll=0. Starting with that commit, the behavior is
> present nomatter the poll setting.
>
> Am I correct in thinking that this is a problem without a clear solution?
It's a problem with a solution rejected by Dave and Alex, and I tend
to agree with them a bit. The real solution is to grow nouveau/radeon
hpd storm mitigation code (i915 already has it in 3.10), since it's
much better to cut of the issue at the source (by disasbling hpd
interrupts completely for such problematic outputs) instead of trying
to work around the worst side-effects of getting too many.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch