[Intel-gfx] [PATCH 1/2] drm/i915/crt: Remove 0xa0 probe for CRT
Chris Wilson
chris at chris-wilson.co.uk
Tue Apr 5 11:18:52 CEST 2011
On Mon, 04 Apr 2011 09:26:20 -0700, Keith Packard <keithp at keithp.com> wrote:
> On Mon, 04 Apr 2011 16:29:55 +0100, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>
> > Yes. I'm saying that that the controller accepts a write to port 0xa0.
>
> So it's the GMBUS controller itself then, I guess. Weird.
>
> Let me see if I understand how it used to work and why fixing the GMBUS
> reset causes it to break in this case.
It also requires just the right combination of hardware to reproduce:
in my case a 915GM (pre-CRT hotplug detect I think is the critical factor).
> In the distant past (pre-GMBUS)
>
> 1) Some previous DDC transaction would fail, but without GMBUS
> this would not break the bus
> 2) The 0xA0 transaction would fail as there wasn't anyone
> listening on the DDC bus.
Not quite. In this case, it fails because the core i2c bitbanging algo
doesn't seem to handle a solitary write message and reports EREMOTEIO.
Whereas using GMBUS to drive the i2c xfer, the hardware completes the
message without reporting an error.
> 3) The 0x50 transaction would also fail, again because no-one
> was listening
> 4) The monitor would be reported as disconnected.
>
> In the recent past (post-GMBUS):
>
> 1) Some previous DDC transaction would fail, wedging the GMBUS
> 2) The 0xA0 transaction would then fail due to the GMBUS breakage
On my test hardware, there happens to be no previous NAK and so it reports
"CRT detected via DDC:0xa0" anyway. But a NAK here can only explain how
the regressions were only reported after 7f58aabc.
> 3) The 0x50 transaction would also fail as the GMBUS was wedged
> 4) The VGA port would be reported as disconnected
>
> With the GMBUS reset:
>
> 1) Some previous DDC transaction would fail, but the GMBUS would get
> reset
> 2) The 0xA0 transaction would now succeed.
> 3) The VGA port would be reported as connected.
Technically as unknown, since although we decided that there was a
connection, we could not retrieve an EDID.
> Do we have any idea what ports the GMBUS controller is listening
> internally for? And, whether this differs from chip to chip?
As Dave suggested, using 0xa0 was fubar. And in this case the controller
was just presumably accepting a write to 0x50, when I expected it to be
NAKed due to no attached slave listening on that address.
Of course, in testing, I choose a combination of hardware (915GM and an
old VGA panel) that proved impossible to retrieve the EDID for, whether
using bitbanging i2c or GMBUS. (I'm seeing the same invalid checksum on a
SugarBar, so it is probably not timing related - but I think this is a
regression in itself.) That did prevent testing a few of the other cases
since even when connected, we could do no better than unknown.
So what I am less clear on is how it actually worked if the GMBUS was
NAKed, and so proceeded past the 0xa0 probe to the real EDID probe and
yet appear to work.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list