From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 4/8 v7] drm/i915/intel_i2c: use WAIT cycle, not STOP Date: Wed, 11 Apr 2012 22:04:34 +0200 Message-ID: <20120411200434.GS4296@phenom.ffwll.local> References: <1333108003-6341-1-git-send-email-djkurtz@chromium.org> <1333108003-6341-5-git-send-email-djkurtz@chromium.org> <20120410103746.GH4115@phenom.ffwll.local> <20120410104147.GI4115@phenom.ffwll.local> <20120410150304.GJ4115@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Daniel Kurtz Cc: Keith Packard , David Airlie , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Chris Wilson , Benson Leung , Yufeng Shen List-Id: dri-devel@lists.freedesktop.org On Thu, Apr 12, 2012 at 02:16:45AM +0800, Daniel Kurtz wrote: > On Tue, Apr 10, 2012 at 11:03 PM, Daniel Vetter wro= te: > > - atm the debug output is too noisy. I think we can leave the fallb= ack to > > =A0gpio bitbanging at info (or maybe error) level, but all the othe= r > > =A0messages should be tuned down to DRM_DEBUG_KMS - these can easil= y be hit > > =A0when userspace tries to probe the i2c with nothing connected or = if the > > =A0driver code tries to do the same. See: > > =A0https://bugs.freedesktop.org/show_bug.cgi?id=3D48248 >=20 > OK... we can change the logging level. > However, the log in the bug to which you link seems to indicate a mor= e > serious issue in this case. It says to me that something on his > system is trying to talk to the disabled dpc i2c port 5 times every 1= 0 > seconds. Each time it fails due with a time out, and each timeout > takes 50ms. I would argue that the INFO message here is pointing out > that the hotplug code might want to check the corresponding > PORT_ENABLED bit before attempting a read over a particular DP/HDMI > gmbus port. Perhaps I am mistaken, but if there was really nothing o= n > the bus, shouldn't that be a NAK, not a timeout? The issue is that there's no hotplug, so we run a polling loop which checks every 10s whether anything is connected. Part of that is trying = to read an edid. I dunno exactly why we don't get a NAK but a timeout. -Daniel --=20 Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48