[Bug 47007] New: HDMI monitor polling causing 100ms rendering stalls

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47007

             Bug #: 47007
           Summary: HDMI monitor polling causing 100ms rendering stalls
    Classification: Unclassified
           Product: DRI
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/Radeon
        AssignedTo: dri-devel at lists.freedesktop.org
        ReportedBy: tvrtko.ursulin at onelan.co.uk


I am experiencing rendering stalls every ten seconds (drm_kms_helper output
connector poll interval) on a AMD G-T56N (Radeon HD 6310) box connected to the
monitor via HDMI connector.

Kernel is kernel.org's 3.3.0-rc6 kernel.

I've delved into the code a bit, sprayed some printks around, and found that
the culprit is the drm_get_edid call from radeon_dvi_detect where the former
takes more than 100ms. I suspect I2C transfers there are disabling interrupts
because I don't see any locks other than drm_device mode mutex being help at
that at least sounds harmless.

This function (radeon_dvi_detect) is a bit advanced for a newcomer in this
area, but, looking at the accompanying comment and the code, I am not sure it
could not be improved?

For example if monitor is connected, and we know it is a digital monitor, do we
need to discard and re-fetch complete EDID every time? Couldn't we just do a
quick probe to check for disconnection instead?

This is if I understand correctly that EDID probing must be done for
disconnection check?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.