On Mon, 04 Apr 2011 09:26:20 -0700, Keith Packard <[email protected]> wrote: > On Mon, 04 Apr 2011 16:29:55 +0100, Chris Wilson <[email protected]> > 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 _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
