Re: [PATCH 1/2] drm/i915/crt: Remove 0xa0 probe for CRT

[Chris Wilson <chris@chris-wilson.co.uk>]

On Mon, 04 Apr 2011 09:26:20 -0700, Keith Packard <keithp@keithp.com> wrote:
> On Mon, 04 Apr 2011 16:29:55 +0100, Chris Wilson <chris@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