From: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: linux-kernel@vger.kernel.org, Imre Deak <imre.deak@intel.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>
Subject: 3.8.2->3.8.3 i915 regression: GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5
Date: Thu, 14 Mar 2013 21:36:24 +0100 [thread overview]
Message-ID: <201303142136.24917.a.miskiewicz@gmail.com> (raw)
Hello.
After upgrading from 3.8.2 to 3.8.3 I'm getting regression :
diff:
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
+ [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5
fbcon: inteldrmfb (fb0) is primary device
- Console: switching to colour frame buffer device 180x56
+ Console: switching to colour frame buffer device 128x48
i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
i915 0000:00:02.0: registered panic notifier
acpi device:01: registered as cooling_device0
console becomes weird, ends up in 2/3 of screen, X when starts gets tiny fonts etc.
Machine is Thinkpad T400 with gm45 GPU
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller])
Subsystem: Lenovo Device [17aa:2112]
Reverting bisected commit from 3.8.3 fixes the problem
2a9810441fcc26cf3f006f015f8a62094fe57a90 is the first bad commit
commit 2a9810441fcc26cf3f006f015f8a62094fe57a90
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat Dec 1 21:03:22 2012 +0100
drm/i915: reorder setup sequence to have irqs for output setup
commit 52d7ecedac3f96fb562cb482c139015372728638 upstream.
Otherwise the new&shiny irq-driven gmbus and dp aux code won't work that
well. Noticed since the dp aux code doesn't have an automatic fallback
with a timeout (since the hw provides for that already).
v2: Simple move drm_irq_install before intel_modeset_gem_init, as
suggested by Ben Widawsky.
v3: Now that interrupts are enabled before all connectors are fully
set up, we might fall over serving a HPD interrupt while things are
still being set up. Instead of jumping through massive hoops and
complicating the code with a separate hpd irq enable step, simply
block out the hotplug work item from doing anything until things are
in place.
v4: Actually, we can enable hotplug processing only after the fbdev is
fully set up, since we call down into the fbdev from the hotplug work
functions. So stick the hpd enabling right next to the poll helper
initialization.
v5: We need to enable irqs before intel_modeset_init, since that
function sets up the outputs.
v6: Fixup cleanup sequence, too.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
:040000 040000 26e83b14e8d49da8c451dc2c837646a337a79085 fa2cbfcf159808ce188675115888242245e4e69d M drivers
relevant dmesg:
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to userspace modesetting.
i915 0000:00:02.0: setting latency timer to 64
i915 0000:00:02.0: irq 47 for MSI/MSI-X
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5
fbcon: inteldrmfb (fb0) is primary device
i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
i915 0000:00:02.0: registered panic notifier
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
--
Arkadiusz Miśkiewicz, arekm / maven.pl
next reply other threads:[~2013-03-14 20:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-14 20:36 Arkadiusz Miskiewicz [this message]
2013-03-14 22:19 ` 3.8.2->3.8.3 i915 regression: GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 Michael Leun
2013-03-18 20:20 ` Greg Kroah-Hartman
2013-03-16 10:35 ` Arkadiusz Miskiewicz
2013-03-17 19:40 ` Daniel Vetter
2013-03-17 20:10 ` Arkadiusz Miskiewicz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201303142136.24917.a.miskiewicz@gmail.com \
--to=a.miskiewicz@gmail.com \
--cc=daniel.vetter@ffwll.ch \
--cc=gregkh@linuxfoundation.org \
--cc=imre.deak@intel.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox