On Thu, Jan 5, 2012 at 12:43, Daniel Vetter <daniel at ffwll.ch> wrote: > 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. > I'd be happy to include it into any kernel out there, 3.4 would be fine. I originally sent it for 3.1 merge though, and so far it haven't been picked up by any tree. So I am a bit lost about what to do with this next, besides re-sending the same patch over and over again... -- Eugeni Dodonov <http://eugeni.dodonov.net/> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120105/31fa87ff/attachment.htm>
