diff mbox

drm/i915: Reset GMBUS controller after NAK

Message ID b7da2f$qu61s6@fmsmga001.fm.intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

Chris Wilson March 31, 2011, 3:20 p.m. UTC
None

Comments

Steven Newbury April 2, 2011, 9:50 p.m. UTC | #1
----- Original message -----
> ----- Original message -----
> > On Thu, 31 Mar 2011 16:16:27 +0100, Steven Newbury
> > <steve@snewbury.org.uk> wrote:
> > > ----- Original message -----
> > > > On Wed, 30 Mar 2011 17:07:11 +0100
> > > > Chris Wilson <chris@chris-wilson.co.uk> 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 <chris@chris-wilson.co.uk>
> > > > > ---
> > > > 
> > > > 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
diff mbox

Patch

diff --git a/drivers/gpu/drm/i915/intel_i2c.c
b/drivers/gpu/drm/i915/intel_i2c.c
index d3b903b..ef9f664 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -401,7 +401,7 @@  int intel_setup_gmbus(struct drm_device *dev)
                bus->reg0 = i | GMBUS_RATE_100KHZ;
 
                /* XXX force bit banging until GMBUS is fully debugged */
-               if (IS_GEN2(dev))
+               if (1)
                        bus->force_bit = intel_gpio_create(dev_priv, i);
        }