public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
* [PATCH] Improvements in edid detection timings (final)
@ 2011-10-17 13:12 Eugeni Dodonov
  2011-10-17 13:12 ` [PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there Eugeni Dodonov
  2011-10-17 13:12 ` [PATCH 2/2] Check if the bus is valid prior to discovering edid Eugeni Dodonov
  0 siblings, 2 replies; 10+ messages in thread
From: Eugeni Dodonov @ 2011-10-17 13:12 UTC (permalink / raw)
  To: intel-gfx; +Cc: dri-devel, Eugeni Dodonov

Those are two identical fixes for improving EDID detection timings, which
also fix extremely slow xrandr queries in case of phantom outputs
(https://bugs.freedesktop.org/show_bug.cgi?id=41059)

The first fix is a small change to drm_edid, which prevents it from talking to
non-existent adapters by detecting them faster.

The second fix replicates the first one within the i915 driver. It does the
same thing, but without touching core DRM files.

Those are some of the testing results from our QA team:

Regressions and functional testing:
         Machine+ports                  result
Ironlake(mobile) eDP/VGA                pass
Ironlake(desktop) DP/VGA                pass
Ironlake(mobile) LVDS/VGA/DP            pass
G45(desktop) VGA/HDMI                   pass
Pineview(mobile) LVDS/VGA               pass

xrandr performance:
                           Without patch   with patch
E6510(Ironlake mobile)     0.119           0.111
PK1(Ironlake desktop)      0.101           0.080
T410b(Ironlake mobile)     0.406           0.114
G45b( G45 desktop)         0.121           0.091
Pnv1(Pineview mobile)      0.043           0.040

Those are the results for machines affected by phantom outputs issue, based on
fd.o #41059 feedback:

xrandr performance:
                           Without patch   with patch
System 1                   0.840           0.290
System 2                   0.690           0.140
System 3                   0.315           0.280
System 4                   0.175           0.140
System 6 (original issue)  4s              0.184

We have observed no regressions in any cases, and performance improvements
of 20-30% for edid detection timing. Combining it with the results obtained
at https://bugs.freedesktop.org/show_bug.cgi?id=41059, besides those
improvements it also improves xrandr timing by up to 20x in the worst case
of phantom outputs.

I believe that the better way to fix this is via the drm_get_edid() fix, as
it is a one-line fix and could benefit all other chipsets. And we won't have
to reinvent the wheel with intel_drm_get_edid, which only duplicates the
existent functionality with no additional benefits.

Could we have any feedback or reviewed-by or from non-intel drm maintainers?

Thanks!

Eugeni Dodonov (2):
  Give up on edid retries when i2c tells us that bus is not there
  Check if the bus is valid prior to discovering edid.

 drivers/gpu/drm/drm_edid.c         |    5 ++++
 drivers/gpu/drm/i915/intel_crt.c   |   46 ++++++++++++++++++------------------
 drivers/gpu/drm/i915/intel_dp.c    |    4 +-
 drivers/gpu/drm/i915/intel_drv.h   |    3 +-
 drivers/gpu/drm/i915/intel_hdmi.c  |    4 +-
 drivers/gpu/drm/i915/intel_i2c.c   |   42 ++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_lvds.c  |    2 +-
 drivers/gpu/drm/i915/intel_modes.c |   29 +----------------------
 drivers/gpu/drm/i915/intel_sdvo.c  |    4 +-
 9 files changed, 80 insertions(+), 59 deletions(-)

-- 
1.7.7

^ permalink raw reply	[flat|nested] 10+ messages in thread
* [PATCH 0/2] RFC: Potential improvements in edid detection timings (v2)
@ 2011-10-07 22:00 Eugeni Dodonov
  2011-10-07 22:00 ` [PATCH 2/2] Check if the bus is valid prior to discovering edid Eugeni Dodonov
  0 siblings, 1 reply; 10+ messages in thread
From: Eugeni Dodonov @ 2011-10-07 22:00 UTC (permalink / raw)
  To: intel-gfx; +Cc: Eugeni Dodonov, dri-devel

(Resending with small improvements - also sending to dri-devel for feedback).

This is the the forth iteration of potential fixes for slow edid detection
issues over non-existent outputs
(https://bugs.freedesktop.org/show_bug.cgi?id=41059) - the previous versions
were posted to the bug and were used mostly for debugging the problem.

The problem I attempted to fix here is that some systems would take a very
long time trying to locate all the possible video outputs - in in cases
where such outputs were bogus, this lead to timing out after all the
possible delays were done.

After investigation, I came to think on two different ways to fix the issue:
 - The first patch does a one-line fix in drm_edid.c. I added a check for the
   return value of i2c_transfer - and, if it is -ENXIO, we give up on further
   attempts as the bus is not there. A drawback to this approach is that it
   affects all the devices out there which use drm_get_edid.  From my testing,
   the -ENXIO gave no false positives, but I haven't tested it on non-Intel
   cards. So I'd like to hear what other drm developers think about that.

 - The second patch does a similar procedure within the i915 driver, in case
   the proposed change to drm_edid.c won't be adequate for other drivers. It
   adds a new function - intel_drm_get_valid_edid - which attempts to do a
   simple i2c transfer over the bus prior to calling drm_get_edid. In case such
   transfer fails with -ENXIO, it is a signal that the bus is not there, so we
   shouldn't waste any time trying to communicate with it further.

Note that those patches provide lots of dmesg pollution - for the final
version those printk'ss should probably be removed, but I left them
intentionally with KERN_DEBUG in order to see when the adapters come and go
during the debugging and testing.

According to testing performed at
https://bugs.freedesktop.org/show_bug.cgi?id=41059, the following results
were obtained with those patches:

System1:
 (testing all possible outputs)
 ubuntu 3.0.0-12.19:       840ms
 3.0.0-12.19 +  drm patch: 290ms
 3.0.0-12.19 + i915 patch: 290ms
 (manually ignoring phantom outputs)
 ubuntu 3.0.0-12.19:       690ms
 3.0.0-12.19 +  drm patch: 140ms
 3.0.0-12.19 + i915 patch: 140ms

System2:
 (testing all possible outputs)
 ubuntu 3.0.0-12.19:       315ms
 3.0.0-12.19 +  drm patch: 280ms
 3.0.0-12.19 + i915 patch: 280ms
 (manually ignoring phantom outputs)
 ubuntu 3.0.0-12.19:       175ms
 3.0.0-12.19 +  drm patch: 140ms
 3.0.0-12.19 + i915 patch: 140ms



Eugeni Dodonov (2):
  Give up on edid retries when i2c tells us that bus is not there
  Check if the bus is valid prior to discovering edid.

 drivers/gpu/drm/drm_edid.c         |    5 +++++
 drivers/gpu/drm/i915/intel_dp.c    |    4 ++--
 drivers/gpu/drm/i915/intel_drv.h   |    2 ++
 drivers/gpu/drm/i915/intel_hdmi.c  |    4 ++--
 drivers/gpu/drm/i915/intel_i2c.c   |   33 +++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_lvds.c  |    2 +-
 drivers/gpu/drm/i915/intel_modes.c |    2 +-
 drivers/gpu/drm/i915/intel_sdvo.c  |    4 ++--
 8 files changed, 48 insertions(+), 8 deletions(-)

-- 
1.7.6.3

^ permalink raw reply	[flat|nested] 10+ messages in thread
* [PATCH 0/2] RFC: Potential improvements in edid detection timings
@ 2011-10-06 23:30 Eugeni Dodonov
  2011-10-06 23:30 ` [PATCH 2/2] Check if the bus is valid prior to discovering edid Eugeni Dodonov
  0 siblings, 1 reply; 10+ messages in thread
From: Eugeni Dodonov @ 2011-10-06 23:30 UTC (permalink / raw)
  To: intel-gfx; +Cc: Eugeni Dodonov

From: Eugeni Dodonov <eugeni.dodonov@intel.com>

This is the the forth iteration of potential fixes for slow edid detection
issues over non-existent outputs
(https://bugs.freedesktop.org/show_bug.cgi?id=41059) - the previous versions
were posted to the bug and were used mostly for debugging the problem.

After investigation, I came to think on two different ways to fix the issue:
in PATCH1, I added a check for the return value of i2c_transfer - and, if it
is -ENXIO, we give up on further attempts as the bus is not there. A
drawback to this approach is that it affects all the devices out there which
use drm_get_edid.  From my testing, the -ENXIO gave no false positives, but
I haven't tested it on non-Intel cards.

The second patch does a similar procedure within the i915 driver. It adds a
new function - intel_drm_get_valid_edid - which attempts to do a simple i2c
transfer over the bus prior to calling drm_get_edid. In case such transfer
fails with -ENXIO, it is a signal that the bus is not there, so we shouldn't
waste any time trying to communicate with it further.

Note that those patches provide lots of dmesg pollution - I just wanted to
send them out to get an overall feedback on the proposed approach.

Eugeni Dodonov (2):
  Give up on edid retries when i2c tells us that bus is not there
  Check if the bus is valid prior to discovering edid.

 drivers/gpu/drm/drm_edid.c         |    5 +++++
 drivers/gpu/drm/i915/intel_dp.c    |    4 ++--
 drivers/gpu/drm/i915/intel_drv.h   |    2 ++
 drivers/gpu/drm/i915/intel_hdmi.c  |    4 ++--
 drivers/gpu/drm/i915/intel_i2c.c   |   33 +++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_lvds.c  |    2 +-
 drivers/gpu/drm/i915/intel_modes.c |    2 +-
 drivers/gpu/drm/i915/intel_sdvo.c  |    4 ++--
 8 files changed, 48 insertions(+), 8 deletions(-)

-- 
1.7.6.3

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2011-10-31 19:45 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-17 13:12 [PATCH] Improvements in edid detection timings (final) Eugeni Dodonov
2011-10-17 13:12 ` [PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there Eugeni Dodonov
2011-10-17 20:41   ` Keith Packard
2011-10-17 21:07     ` Eugeni Dodonov
2011-10-17 22:41       ` Keith Packard
2011-10-18  0:06         ` Eugeni Dodonov
2011-10-31 19:45   ` [Intel-gfx] " Chris Wilson
2011-10-17 13:12 ` [PATCH 2/2] Check if the bus is valid prior to discovering edid Eugeni Dodonov
  -- strict thread matches above, loose matches on Subject: below --
2011-10-07 22:00 [PATCH 0/2] RFC: Potential improvements in edid detection timings (v2) Eugeni Dodonov
2011-10-07 22:00 ` [PATCH 2/2] Check if the bus is valid prior to discovering edid Eugeni Dodonov
2011-10-06 23:30 [PATCH 0/2] RFC: Potential improvements in edid detection timings Eugeni Dodonov
2011-10-06 23:30 ` [PATCH 2/2] Check if the bus is valid prior to discovering edid Eugeni Dodonov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox