[Intel-gfx] [PATCH 1/2] drm: give up on edid retries when i2c bus is not responding

Eugeni Dodonov eugeni at dodonov.net
Thu Jan 5 16:37:50 CET 2012


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.html>


More information about the Intel-gfx mailing list