summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_lvds.c
diff options
context:
space:
mode:
authorChris Wilson <chris@chris-wilson.co.uk>2011-04-05 16:04:39 +0100
committerKeith Packard <keithp@keithp.com>2011-04-05 09:05:34 -0700
commit0de009c900e7ebd21097797f723a40813e953879 (patch)
tree48a314a677088da01022e7f3ff119353cc55c861 /drivers/gpu/drm/i915/intel_lvds.c
parent7f58aabc369014fda3a4a33604ba0a1b63b941ac (diff)
downloadtalos-op-linux-0de009c900e7ebd21097797f723a40813e953879.tar.gz
talos-op-linux-0de009c900e7ebd21097797f723a40813e953879.zip
drm/i915/crt: Remove 0xa0 probe for VGA
This is a moral revert of 6ec3d0c0e9c0c605696e91048eebaca7b0c36695. Following the fix to reset the GMBUS controller after a NAK, we finally utilize the 0xa0 probe for a CRT connection. And discover that the code is broken. Shock. There are a number of issues, but following a key insight from Dave Airlie, that 0xA0 is an invalid address on a 7-bit bus (though not if we were to enable 10-bit addressing), and would look like the EDID port 0x50, it is possible to see where the confusion starts. In short, a write to 0xA0 is accepted by the GMBUS controller which we interpreted as meaning the existence of a connection (a slave on the other end of the wire ACKing the write). That was false. During testing with a broken GMBUS implementation, which never reset an earlier NAK, this test always reported a NAK and so we proceeded on to the next test. Reported-and-tested-by: Sitsofe Wheeler <sitsofe@yahoo.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35904 Reported-and-tested-by: Riccardo Magliocchetti <riccardo.magliocchetti@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32612 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Dave Airlie <airlied@linux.ie> Signed-off-by: Keith Packard <keithp@keithp.com>
Diffstat (limited to 'drivers/gpu/drm/i915/intel_lvds.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud