From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Newbury Subject: Re: [PATCH] drm/i915: Reset GMBUS controller after NAK Date: Sat, 02 Apr 2011 22:50:12 +0100 Message-ID: <1301781012.1996.2.camel@Nokia-N900> References: <1301501231-27133-1-git-send-email-chris@chris-wilson.co.uk> <20110330130520.49891faf@jbarnes-desktop> <1301584587.2051.2.camel@Nokia-N900> <1301585609.2051.5.camel@Nokia-N900> Reply-To: Steven Newbury Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by gabe.freedesktop.org (Postfix) with ESMTP id D1F9D9E748 for ; Sat, 2 Apr 2011 14:50:07 -0700 (PDT) In-Reply-To: <1301585609.2051.5.camel@Nokia-N900> Content-ID: <1301781011.1996.1.camel@Nokia-N900> 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: Chris Wilson , Jesse Barnes Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org ----- Original message ----- > ----- Original message ----- > > On Thu, 31 Mar 2011 16:16:27 +0100, Steven Newbury > > wrote: > > > ----- Original message ----- > > > > On Wed, 30 Mar 2011 17:07:11 +0100 > > > > Chris Wilson wrote: > > > > > > > > > Once a NAK has been asserted by the slave, we need to reset the > > > > > GMBUS controller in order to continue. This is done by asserting > > > > > the Software Clear Interrupt bit and then clearing it again to > > > > > restore operations. > > > > > > > > > > If we don't clear the NAK, then all future GMBUS xfers will fail, > > > > > including DDC probes and EDID retrieval. > > > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35781 > > > > > Signed-off-by: Chris Wilson > > > > > --- > > > > > > > > This one fixes the issue I was seeing on my HP test machine; LVDS > > > > DDC probing seems to work ok once this fix is applied. > > > > > > > > -- > > > Could this be related to my inability to successfully probe the > > > ch7036 with the ChromeOS Chrontel driver? Is it worth me testing it > > > again with this patch applied? (I'm currently waiting to hear back > > > from Zotac, my board supplier) > > > > Hmm. Depends, but unlikely. I would have thought the nm10_gpio driver > > you were using used it's only bitbanging on the GPIO lines rather than > > GMBUS. If in doubt, disable the use of GMBUS by > > > The GPIO is only used for HDMI hotplug detection, chip communication > goes via i2c, or at least would if I could get it working... :-( Since I pulled in drm-fixes I get different behaviour when probing for the ch7036, in my kernel log I now get: [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [drm] GMBUS timed out, falling back to bit banging on pin 4 [i915 gmbus dpc] [drm] GMBUS timed out, falling back to bit banging on pin 5 [i915 gmbus dpb] [drm] GMBUS timed out, falling back to bit banging on pin 6 [i915 gmbus reserved] [drm] GMBUS timed out, falling back to bit banging on pin 7 [i915 gmbus dpd] The probe still fails, on some i2c buses I get as before: XAUTHORITY=/home/mythtv/.Xauthority ./ch7036_monitor -v -p -d/dev/i2c-2 ./ch7036_monitor: starts Found device ID 0xff ./ch7036_monitor: Fatal: Device ID 0xff not the expected 0x56 whilst on others: XAUTHORITY=/home/mythtv/.Xauthority ./ch7036_monitor -v -p -d/dev/i2c-4 ./ch7036_monitor: starts Write byte fail (3, 03, 04): No such device or addressFound device ID 0xffffffff ./ch7036_monitor: Fatal: Device ID 0xffffffff not the expected 0x56