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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #15 from Tvrtko Ursulin <tvrtko.ursulin at onelan.co.uk> 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.