https://bugs.freedesktop.org/show_bug.cgi?id=47007 --- Comment #15 from Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxx> 2012-03-13 04:44:04 PDT --- Bad news from a different motherboard. This one has DVI-D and DP connectors. With a DVI monitor connected stalls are still there due to the shared_ddc being true (DDC shared between DVI and VGA). Connectors look like this here: [drm] Radeon Display Connectors [drm] Connector 0: [drm] DisplayPort [drm] HPD1 [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY [drm] Connector 1: [drm] DVI-D [drm] HPD2 [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [drm] Encoders: [drm] DFP2: INTERNAL_UNIPHY [drm] Connector 2: [drm] VGA [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 If I remove the shared_ddc check from the patch that removes the 100ms stall in radeon_dvi_detect. However in this configuration there is another 60ms stall from drm_get_edid in radeon_vga_detect now. Also, radeon_dp_getsinktype from radeon_dp_detect adds another 3ms for the disconnected DP port. Recap of latency contributors on this hardware: 1. radeon_dvi_detect * 100ms when connected from drm_get_edid Can be fixed with the patch like the above, but with shared_ddc check criteria removed if that is OK? That would then work for both motherboards that I tested on. HDMI on the first one, and DVI on this one. 2. radeon_vga_detect * not connected * 5ms from radeon_ddc_probe * 60ms from drm_get_edid Not sure how to improve this without making the code a lot smarter. It would have to consider who is sharing DDC with who, and if another connector is connected it would imply this one can not be and then skip the EDID fetch? Also perhaps 5ms from radeon_ddc_probe could be saved by somehow passing the header to drm_get_edid, if I gather correctly that the latter re-fetches the same header radeon_ddc_probe retrieved. 3. radeon_dp_detect * 8ms when not connected from radeon_dp_getsinktype * haven't tested the connected case - that is unreliable anyway, bug 46711 Not sure if this would be passable if it remained the only latency source. It's not ideal that's for sure. Does it need to do the radeon_dp_getsinktype call in the absence of a HPD interrupt though? If not could we short-circuit it in some way similar to radeon_dvi_detect? Call it after radeon_hpd_sense only if something is connected? However looking at the code it doesn't suggest all latency is avoidable since it doesn't seem to trust HPD sense. Same story with OEM wiring reliability? -- 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
