On Thu, Jan 05, 2012 at 09:34:28AM -0200, Eugeni Dodonov wrote: > 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 <chris at hchris-wilson.co.uk> > Reviewed-by: Keith Packard <keithp at keithp.com> > Tested-by: Sean Finney <seanius at seanius.net> > Tested-by: Soren Hansen <soren at linux2go.dk> > Tested-by: Hernando Torque <sirius at sonnenkinder.org> > Tested-by: Mike Lothian <mike at fireburn.co.uk> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059 > Signed-off-by: Eugeni Dodonov <eugeni.dodonov at intel.com> Imo it's too late for such a change with decent potential to blow up to land in 3.3. I think this needs some decent shakeout time in Dave's drm-next tree (despite all r-b's and tested-bys it already gathered) and hence is imo 3.4 material at this stage. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
