dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Reim <reimth@googlemail.com>
To: Dave Airlie <airlied@redhat.com>, Alex Deucher <alexdeucher@gmail.com>
Cc: Thomas Reim <rdratlos@yahoo.co.uk>, dri-devel@lists.freedesktop.org
Subject: [PATCH 0/2] drm_radeon_kms: Some Regression Fixes for Extended DDC Probe
Date: Mon, 28 Nov 2011 17:20:08 +0100	[thread overview]
Message-ID: <1322497210-16331-1-git-send-email-reimth@gmail.com> (raw)

Since Linux 3.2-rc2 the following two patches have changed the DDC detect and
and probe behaviour of the radeon driver:
- drm/radeon/kms: always do extended edid probe
- drm/radeon/kms: remove useless radeon_ddc_dump()

The first patch makes an EDID header check mandatory during DDC detection/probe.
The second patch removes the DDC check during Radeon device setup, that was done
before the actual connector detection. The log output of this check confused
users with DP, eDP, or DP bridge connectors.

Found regression:
(1) The stop of DDC detection for floating connectors, i. e. connectors with
    improperly wired/terminated i2c bus, of RS690/RS740 family chipsets does
    not work anymore.
(2) HW bugs that result in the DDC being available, but unusable EDID (header)
    do now lead to connectors silently probed via i2c but not being used. There
    is no notification to the user (via kernel logs). Even with drm debugging
    enabled at kernel boot time, there is no information. No chance for a user
    to identify the root cause of the connector being probed but not being
    used.
    
The attached two fixes restore the RS690/RS740 floating connectors quirk,
i. e. stop of DDC detection. In addition, the detection of such floating
connectors is now more comprehensive: Also floating connectors with a few (<= 8)
random byte values other than zero reported during i2c transaction are now
properly detected.

During discussion of patch "drm/radeon/kms: remove useless radeon_ddc_dump()"
(see http://www.spinics.net/lists/dri-devel/msg15523.html) the proposal was
made to include the log information of the removed function radeon_ddc_dump()
into function drm_fb_helper_initial_config(). Further investigations showed,
that during intial framebuffer configuration the connector (type) specific
detect function will be called surrounded by kernel debug log message output.
In the here important radeon DVI connector case function radeon_dvi_detect()
is called. As this function is anyway touched by the present patch,
I decided to move the unusable EDID logging there. Counter radeon_connector->
broken_edid_header_counter will ensure, that kernel logs are not flooded, as
it was the case before implementation of extended DDC/EDID probe.


Thomas Reim (2):
  drm: Improve detection of floating connectors
  drm/radeon/kms: wrap-up handling of floating connectors and connector
    unavailability status logging

 drivers/gpu/drm/drm_edid.c                 |   13 ++++++-
 drivers/gpu/drm/radeon/radeon_connectors.c |   54 +++++++++++++++++++++++-----
 drivers/gpu/drm/radeon/radeon_i2c.c        |    7 +++-
 drivers/gpu/drm/radeon/radeon_mode.h       |    3 ++
 4 files changed, 65 insertions(+), 12 deletions(-)

             reply	other threads:[~2011-11-28 16:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-28 16:20 Thomas Reim [this message]
2011-11-28 16:20 ` [PATCH 1/2] drm: Improve detection of floating connectors Thomas Reim
2011-11-28 16:20 ` [PATCH 2/2] drm/radeon/kms: wrap-up handling of floating connectors and connector unavailability status logging Thomas Reim
2011-11-29 14:50   ` Alex Deucher
2011-11-29 18:06     ` Thomas Reim
2011-11-29 20:53       ` Alex Deucher
2011-11-30 10:54         ` Thomas Reim
2011-12-01 14:10           ` Alex Deucher
2011-11-29 18:33   ` Thomas Reim
2011-11-28 16:34 ` [PATCH 0/2] drm_radeon_kms: Some Regression Fixes for Extended DDC Probe Thomas Reim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1322497210-16331-1-git-send-email-reimth@gmail.com \
    --to=reimth@googlemail.com \
    --cc=airlied@redhat.com \
    --cc=alexdeucher@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=rdratlos@yahoo.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox