Reinette Chatre reports a frozen system (with blinking keyboard LEDs)
when switching from graphics mode to the text console, or when
suspending (which does the same thing). With netconsole, the oops
turned out to be
BUG: unable to handle kernel NULL pointer dereference at 0000000000000084
IP: [<ffffffffa03ecaab>] i915_driver_irq_handler+0x26b/0xd20 [i915]
and it's due to the i915_gem.c code doing drm_irq_uninstall() after
having done i915_gem_idle(). And the i915_gem_idle() path will do
i915_gem_idle() ->
i915_gem_cleanup_ringbuffer() ->
i915_gem_cleanup_hws() ->
dev_priv->hw_status_page = NULL;
but if an i915 interrupt comes in after this stage, it may want to
access that hw_status_page, and gets the above NULL pointer dereference.
And since the NULL pointer dereference happens from within an interrupt,
and with the screen still in graphics mode, the common end result is
simply a silently hung machine.
Fix it by simply uninstalling the irq handler before idling rather than
after. Fixes
http://bugzilla.kernel.org/show_bug.cgi?id=13819
Reported-and-tested-by: Reinette Chatre <reinette.chatre@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
eDP is exclusive connector too, and add missing crtc_mask
setting for TV.
This fixes
http://bugzilla.kernel.org/show_bug.cgi?id=14139
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Reported-and-tested-by: Carlos R. Mafra <crmafra2@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This adds some rv350+ register for LTE/GTE discard,
and enables the rv515 two sided stencil register.
It also disables the DEPTHXY_OFFSET register which
can be used to workaround the CS checker.
Moves rs690 to proper place in rs600 and uses correct
table on rs600.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Remember to release the local reference if we fail to wait on
the rendering.
(Also whilst in the vicinity add some whitespace so that the phasing of
the operations is clearer.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Some i915/i945 platforms have a fairly high memory latency in certain
situations, so increase our constant a bit to avoid FIFO underruns.
The effect should be positive on other platforms as well; we'll have a
bit more insurance against a busy memory subsystem due to the extra
FIFO entries.
Fixes fdo bug #23368. Needed for 2.6.31.
Tested-by: Sven Arvidsson <sa@whiz.se>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Use VBT information to determine which DDC bus to use for CRTDCC.
Fall back to GPIOA if VBT info is not available.
Signed-off-by: David Müller <d.mueller@elsoft.ch>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Tested on: 855 (David), and 945GM, 965GM, GM45, and G45 (anholt)
Based on Bspec each encoder has different sharing pipe property,
i.e. Integrated or SDVO TV both will occupy one pipe exclusively,
and sdvo-non-tv and crt are allowed to share one. The patch moves
sharing judgment into differnet output functions, and sets the right
clone bit.
This fixes both HDMI outputs choosing the same pipe.
https://bugs.freedesktop.org/show_bug.cgi?id=22247
Signed-off-by: Ma Ling <ling.ma@intel.com>
Reviewed-by : Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
After the following commit is shipped, the SDVO C detection will depend on
the SDVO_C/DP detion bit.
commit 13520b051e
Author: Kristian Høgsberg <krh@redhat.com>
Date: Fri Mar 13 15:42:14 2009 -0400
drm/i915: Read the right SDVO register when detecting SVDO/HDMI.
According to the spec we should continue to detect the SDVO_B/C based on
the SDVO_B detection bit. The new detection bit on G4X platform is for
the HDMI_C detection rather than SDVO_C detection.
https://bugs.freedesktop.org/show_bug.cgi?id=20639
Signed-off-by: Ma Ling <ling.ma@intel.com>
Acked-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Commit 0c2e39525b is not sufficient to
get fd.o bug #20115 fixed.
In addition intel_find_best_PLL() must not only rely on BIOS settings
for i9xx chips but also for i8xx, so drop the IS_I9XX() check.
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
http://bugs.freedesktop.org/show_bug.cgi?id=21417
Signed-off-by: Sean Young <sean@mess.org>
Reviewed-by: Zhao Yakui <yakui.zhao@intel.com>
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
The drm sysfs class suspend / resume methods could not distinguish
between different device types wich could lead to illegal type casts.
Use struct device_type and make sure the class suspend / resume callbacks
are aware of those. There is no per device-type suspend / resume. Only
new-style PM.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The previous patch assumes the ioctl already existed, when
it actually didn't.
It also didn't return the correct error code.
Signed-off-by: Dave Airlie <airlied@redhat.com>
If userspace destroys a framebuffer that is in use on a crtc,
don't just null it out, tear down the crtc properly so the
hw gets turned off.
Signed-off-by: Dave Airlie <airlied@redhat.com>
The fallback case wasn't getting executed properly if there
was no TV table, which my T42 M7 hasn't got.
Signed-off-by: Dave Airlie <airlied@redhat.com>
LVDS always requests RMX_FULL, we need to fix it so that doesn't happen
before we can enable LVDS on crtc 1.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This implements the busy ioctl along with a current domain check.
returns 0 or -EBUSY
puts the current domain no matter what the answer.
Signed-off-by: Dave Airlie <airlied@redhat.com>
We really don't want to be doing all these indirects, updating
the GPU gart table is something we do often so the less overhead the
better.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes 3D apps timing out in the WAIT_VBLANK ioctl.
AVIVO bits compile-tested only.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
this syncs the versioning check with the code the X server uses.
Reported-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Dave Airlie <airlied@redhat.com>
rs690 is r3xx 3D engine with AVIVO modesetting so we need to allow
AVIVO register for vline synchronization. This add a specific table
to rs690 to handle that. Thanks to Marc (marvin24) for debugging
this and kudos to Andre (taiu1) for spotting the origin of the bugs.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some applications/hardware combinations are triggering the message "failed to
acquire vblank counter" to be issued up to 20 times a second, which makes it
both useless and dangerous, as this may hide other important messages.
This changes makes it only appear when people are debugging.
Signed-off-by: Paul Rolland <rol@as2917.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Lost-twice-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The code which takes probed modes and adds them to a connector eliminates
duplicate modes by comparing them using drm_mode_equal. That function
doesn't consider the type bits, which means that any modes which differ only
in the type field will be lost.
One of the bits in the mode->type field is the DRM_MODE_TYPE_PREFERRED bit.
If the mode with that bit is lost, then higher level code will not know
which mode to select, causing a random mode to be used instead.
This patch simply merges the two mode type bits together; that seems
reasonable to me, but perhaps only a subset of the bits should be used? None
of these can be user defined as they all come from looking at just the
hardware.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
we should align the GTT after VRAM no matter what, as we can
come back from resume and put in a different place and bad things happen.
Signed-off-by: Dave Airlie <airlied@redhat.com>
GTT object can either be cached,uncached or wc just let core ttm
pick the best mode according to how the bo driver and GTT memory
type was initialized.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
dev_priv->saveSWF1 is a 16 element array, but this reads up to index 22,
and restored values from the wrong registers.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Check whether index is within bounds before grabbing the element.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Check whether index is within bounds before grabbing the element.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If there are multiple simultaneous waiters for the same buffer object,
a temporary reference to its sync object may be leaked.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
On some architectures the comparison may cause a compilation failure.
Original partial fix Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This was caught by Weiss. Also added some comments to the
fb_changed and mode_changed variables to explain what they do.
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Tested-by: Thomas White <taw@bitwiz.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Match the logic to the comments in the debug message
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This corresponds to a fix to UMS back in 2007. Fixes fd.o bug #20115.
Signed-off-by: Ma Ling <ling.ma@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
The patch fixed a bug on MP965-D. When VGA is connected to a DVI-I connector,
it incorrectly shows sdvo dvi as connected.
Signed-off-by: Ma Ling <ling.ma@intel.com>
[anholt: hand-resolved against previous commit and fixed up commit message]
Signed-off-by: Eric Anholt <eric@anholt.net>
Baed on Eric's idea in order to handle multiple sdvo encoders
we implement another approach to dynamically chose real one
encoder after detection, which is contrasted with patch -
drm/i915:Construct all possible sdvo outputs for sdvo encoder.
Signed-off-by: Ma Ling <ling.ma@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
In order to get best possible quality image we chose 640x480 for
NTSC, PAL and 480p, 1280x720 for 720p, 1920x1080 for 1080i/p
TV format respectively.
Signed-off-by: Ma Ling <ling.ma@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
I had one report of flicker due to FIFO underruns on 845G. Scott was
kind enough to test a few patches and report success with this one.
Looks like 845G measures FIFO size slightly differently than other
chips, and we were also clobbering the FIFO burst length. Fixing both
of those issues gives him a healthy machine again.
Note that we still only adjust plane A's watermark in the 830/845
case. If someone is willing to test we could support a bigger variety
of dual-head 830/845 configurations with a bit more code.
Fixes fdo bug #19304 (again).
Reported-by: Scott Hansen <scottandchrystie@comcast.net>
Tested-by: Scott Hansen <scottandchrystie@comcast.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Check FORCE_DETECT bit to be clear for the finish
of hotplug detect process. Also check possible mono
monitor which should also be marked as connected.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Linus Torvalds