From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH 1/2] drm/i915/crt: Remove 0xa0 probe for CRT Date: Tue, 05 Apr 2011 10:18:52 +0100 Message-ID: <0d30dc$lnfcrn@orsmga001.jf.intel.com> References: <1301898405-6999-1-git-send-email-chris@chris-wilson.co.uk> <849307$cab831@azsmga001.ch.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id 1391B9E7A4 for ; Tue, 5 Apr 2011 02:19:11 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Keith Packard , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Mon, 04 Apr 2011 09:26:20 -0700, Keith Packard wrote: > On Mon, 04 Apr 2011 16:29:55 +0100, Chris Wilson 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