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@lists.freedesktop.org ReportedBy: tvrtko.ursulin@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?