drm: give up on edid retries when i2c bus is not responding
This allows to avoid talking to a non-responding bus repeatedly until we
finally timeout after 15 attempts. We can do this by catching the -ENXIO
error, provided by i2c_algo_bit:bit_doAddress call.
Within the bit_doAddress we already try 3 times to get the edid data, so
if the routine tells us that bus is not responding, it is mostly pointless
to keep re-trying those attempts over and over again until we reach final
number of retries.
This change should fix https://bugs.freedesktop.org/show_bug.cgi?id=41059
and improve overall edid detection timing by 10-30% in most cases, and by
a much larger margin in case of phantom outputs (up to 30x in one worst
case).
Timing results for i915-powered machines for 'time xrandr' command:
Machine 1: from 0.840s to 0.290s
Machine 2: from 0.315s to 0.280s
Machine 3: from +/- 4s to 0.184s
Timing results for HD5770 with 'time xrandr' command:
Machine 4: from 3.210s to 1.060s
Reviewed-by: Chris Wilson <email address hidden>
Reviewed-by: Keith Packard <email address hidden>
Tested-by: Sean Finney <email address hidden>
Tested-by: Soren Hansen <email address hidden>
Tested-by: Hernando Torque <email address hidden>
Tested-by: Mike Lothian <email address hidden>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059
Signed-off-by: Eugeni Dodonov <email address hidden>
Signed-off-by: Dave Airlie <email address hidden>
Please test and report if this does not resolve the problem for you. In some instances we may need to teach the application to use RRGetScreenResourcesCurrent rather than RRGetScreenResources.
In airlied/drm-next:
commit 9292f37e1f5c794 00254dca46f8331 3488093825
Author: Eugeni Dodonov <email address hidden>
Date: Thu Jan 5 09:34:28 2012 -0200
drm: give up on edid retries when i2c bus is not responding
This allows to avoid talking to a non-responding bus repeatedly until we bit:bit_ doAddress call.
finally timeout after 15 attempts. We can do this by catching the -ENXIO
error, provided by i2c_algo_
Within the bit_doAddress we already try 3 times to get the edid data, so
if the routine tells us that bus is not responding, it is mostly pointless
to keep re-trying those attempts over and over again until we reach final
number of retries.
This change should fix https:/ /bugs.freedeskt op.org/ show_bug. cgi?id= 41059
and improve overall edid detection timing by 10-30% in most cases, and by
a much larger margin in case of phantom outputs (up to 30x in one worst
case).
Timing results for i915-powered machines for 'time xrandr' command:
Machine 1: from 0.840s to 0.290s
Machine 2: from 0.315s to 0.280s
Machine 3: from +/- 4s to 0.184s
Timing results for HD5770 with 'time xrandr' command:
Machine 4: from 3.210s to 1.060s
Reviewed-by: Chris Wilson <email address hidden> /bugs.freedeskt op.org/ show_bug. cgi?id= 41059
Reviewed-by: Keith Packard <email address hidden>
Tested-by: Sean Finney <email address hidden>
Tested-by: Soren Hansen <email address hidden>
Tested-by: Hernando Torque <email address hidden>
Tested-by: Mike Lothian <email address hidden>
Bugzilla: https:/
Signed-off-by: Eugeni Dodonov <email address hidden>
Signed-off-by: Dave Airlie <email address hidden>
Please test and report if this does not resolve the problem for you. In some instances we may need to teach the application to use RRGetScreenReso urcesCurrent rather than RRGetScreenReso urces.