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@xxxxxxxxxxxxxxxxxxxxx ReportedBy: tvrtko.ursulin@xxxxxxxxxxxx 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
