Signed-off-by: Hannes Eder <hannes@hanneseder.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@linux.ie>
We haven't seen this in practice, but it was visible when looking at a bug
report from when i915_gem_evict_everything() was broken and would always
return error.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
This is required by the display plane, and fixes 1400x1050 laptop displays.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The replace fb ioctl replaces the backing buffer object for a modesetting
framebuffer object. This can be acheived by just creating a new
framebuffer backed by the new buffer object, setting that for the crtcs
in question and then removing the old framebuffer object.
Signed-off-by: Kristian Hogsberg <krh@redhat.com>
Acked-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Use the new core GEM object mapping code to allow GTT mapping of GEM
objects on i915. The fault handler will make sure a fence register is
allocated too, if the object in question is tiled.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is step one towards having multiple masters sharing a drm
device in order to get fast-user-switching to work.
It splits out the information associated with the drm master
into a separate kref counted structure, and allocates this when
a master opens the device node. It also allows the current master
to abdicate (say while VT switched), and a new master to take over
the hardware.
It moves the Intel and radeon drivers to using the sarea from
within the new master structures.
Signed-off-by: Dave Airlie <airlied@redhat.com>
On PAE systems, GEM allocates pages using shmem, and passes these
pages to be bound into AGP, however the AGP interfaces + the x86
set_memory interfaces all take unsigned long not dma_addr_t.
The initial fix for this was a mess, so we need to do this correctly
for 2.6.29.
Signed-off-by: Dave Airlie <airlied@redhat.com>
These buffers don't have active rendering still occurring to them, they just
need either a flush to be emitted or a retire_requests to occur so that we
notice they're done. Return unbusy so that one of the two occurs. The two
expected consumers of this interface (OpenGL and libdrm_intel BO cache) both
want this behavior.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Since applying the fix suggested by the errata (disabling MSI), we've had
issues with interrupts being stuck on despite IIR being 0 on GM965 hardware.
Most reporters of the issue have confirmed that turning MSI back on fixes
things, and given the difficulties experienced in getting reliable MSI working
on Linux, it's believable that the errata was about software issues and not
actual hardware issues.
Signed-off-by: Dave Airlie <airlied@redhat.com>
It's only for flushing caches appropriately for GTT access, not for actually
getting it there. Prevents potential smashing of cpu read/write domains on
unbound objects.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If we fail to pin all of the buffers in an execbuffer request, go through
and clear the GTT and try again to see if its just a matter of fragmentation
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This eliminates the dev_set_domain function and just in-lines it
where its used, with the goal of moving the manipulation and use of
invalidate_domains and flush_domains closer together. This also
avoids calling add_request unless some domain has been flushed.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Now that the CPU and GTT domain operations are isolated to their own
functions, the previously general-purpose set_domain function is now used
only to set GPU domains. It also has no failure cases, which is important as
this eliminates any possible interruption of the computation of new object
domains and subsequent emmission of the flushing instructions into the ring.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fixes several domain management bugs, including potential lack of cache
invalidation for pread, potential failure to wait for set_domain(CPU, 0),
and more, along with producing more intelligible code.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fixes failure to flush caches in the relocation update path, and
failure to wait in the set_domain ioctl, each of which could lead to incorrect
rendering.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise, we would leave the objects in an inconsistent state, such as
write_domain == 0 but on the flushing list.
Signed-off-by: Dave Airlie <airlied@redhat.com>
obj_priv->write_domain is "write domain if the GPU went idle now", not
"write domain at this moment." By postponing the clear, we confused the
concept, required more storage, and potentially emitted more flushes than
are required.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fixes readpixels and buffer corruption when swapped out and in by
disabling tiling on them.
Now that we know that the bit 17 mode isn't just a mistake of older chipsets,
we'll need to work on a clever fix so that we can get the performance of
tiling on these chipsets, but that will require intrusive changes targeted
at the next kernel release, not this one.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drivers/gpu/drm/i915/i915_irq.c: In function 'i915_disable_pipestat':
drivers/gpu/drm/i915/i915_irq.c:101: warning: control may reach end of non-void function 'i915_pipestat' being inlined
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It fixes suspend/resume failure of xf86-video-intel dri2
branch. As dri2 branch doesn't call I830DRIResume() to restore
hardware status page anymore, we need to preserve
this register across suspend/resume.
Signed-off-by: Peng Li <peng.li@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm vblank initialization keeps track of the changes in driver-supplied
frame counts across vt switch and mode setting, but only if you let it by
not tearing down the drm vblank structure.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Before we had the notion of pinning objects, we had a kludge around to make
sure all of the objects were still resident in the GTT before we committed
to executing a batch buffer. We don't need this any longer, and it sticks an
error return in the middle of object domain computations that must be
associated with a subsequent flush/invalidate emmission into the ring.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Because we write pipestat before iir, it's possible that a pipestat
interrupt will occur between the pipestat write and the iir write. This
leaves pipestat with an interrupt status not visible in iir. This may cause
an interrupt flood as we never clear the pipestat event.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The old code was wandering through the active list looking for pinned
buffers; there may be other pinned buffers around. Fortunately, we keep a
count of the total amount of pinned memory and can use that instead.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Instead, just warn that bad things are happening and do our best to clean up
the mess without the GPU's help.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The IMR masking was a technique recommended for avoiding getting stuck with
no interrupts generated again in MSI mode. It kept new IIR bits from getting
set between the IIR read and the IIR write, which would have otherwise
prevented an MSI from ever getting generated again. However, this caused a
problem for vblank as the IMR mask would keep the pipe event interrupt from
getting reflected in IIR, even after the IMR mask was brought back down.
Instead, just check the state of IIR after we ack the interrupts we're going
to handle, and restart if we didn't get IIR all the way to zero.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The pipestat fields affect reporting of all vblank-related interrupts, so we
have to reset them during the irq_handler, and while enabling vblank
interrupts. Otherwise, if a pipe status field had been set to non-zero
before enabling reporting, we would never see an interrupt again.
This patch adds i915_enable_pipestat and i915_disable_pipestat to abstract
out the steps needed to change the reported interrupts.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Addresses in the hardware status page below index 0x20 are reserved for use
by the hardware. The legacy breadcrumb was sitting at index 5. Move it to
index 0x21, and make sure everyone uses the defined value instead of
hard-coded constants.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
When userland detected that this ioctl was supported (by version number check),
it used it in a racy way -- dispatch delayed swap, wait for vblank, continue
rendering. As there was no mechanism for it to wait for the swap to finish,
sometimes it would render before the swap and garbage would be displayed on
the screen.
By removing the ioctl and returning -EINVAL, userland returns to its previous,
correct rendering path of waiting for a vblank then dispatching a swap. The
only path that could have used this ioctl correctly was page flipping, which
relied on only one client running and emitting wait-for-vblank-before-rendering
in the command stream. That path also falls back correctly, at the performance
cost of not being able to queue up rendering before the flip occurs.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
This probably just means the chipset doesn't support MSI, which is fine.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
This could return early when reading after writing a buffer, if somebody
had already put it on the flushing list (write domains are 0, but still
active), leading to glReadPixels failure.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
This corresponds to the setup of the sarea pointers in DMA initialization,
though neither is exactly the point at which the sarea is set up or torn down.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
This register is set by the 2D driver to prevent lockups, and so it needs to
be preserved across suspend/resume too. This makes my X200s work.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
* 'io-mappings-for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
io mapping: clean up #ifdefs
io mapping: improve documentation
i915: use io-mapping interfaces instead of a variety of mapping kludges
resources: add io-mapping functions to dynamically map large device apertures
x86: add iomap_atomic*()/iounmap_atomic() on 32-bit using fixmaps
This will let userland know when to submit its batchbuffers, before they get
too big to fit in the aperture.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Impact: optimize/clean-up the IO mapping implementation of the i915 DRM driver
Switch the i915 device aperture mapping to the io-mapping interface, taking
advantage of the cleaner API to extend it across all of the mapping uses,
including both pwrite and relocation updates.
This dramatically improves performance on 64-bit kernels which were using
the same slow path as 32-bit non-HIGHMEM kernels prior to this patch.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
drivers/gpu/drm/i915/i915_opregion.c:340: error: implicit declaration of function ‘register_acpi_notifier’
drivers/gpu/drm/i915/i915_opregion.c:361: error: implicit declaration of function ‘unregister_acpi_notifier’
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm: Avoid oops in DRM_IOCTL_RM_DRAW if a bad handle is supplied.
drm: Add 32-bit compatibility for DRM_IOCTL_UPDATE_DRAW.
drm/i915: use pipes, not planes to label vblank data
drm/i915: hold dev->struct_mutex and DRM lock during vblank ring operations
i915: Fix format string warnings on x86-64.
i915: Don't dereference HWS in /proc debug files when it isn't initialized.
i915: Enable IMR passthrough of vblank events before enabling it in pipestat.
drm: Remove two leaks of vblank reference count in error paths.
drm: fix leak of cliprects in drm_rmdraw()
i915: Disable MSI on GM965 (errata says it doesn't work)
drm: Set cliprects to NULL when changing drawable to having 0 cliprects.
i915: Protect vblank IRQ reg access with spinlock
vblank in the kernel is far simpler if it deals with pipes instead of
planes, so we're changing both user and kernel side.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
To synchronize clip lists with the X server, the DRM lock must be held while
looking at drawable clip lists. To synchronize with other ring access, the
ring mutex must be held while inserting commands into the ring. Failure to
do the first resulted in easy visual corruption when moving windows, and the
second could have corrupted the ring with DRI2.
Grabbing the DRM lock involves using the DRM tasklet mechanism, grabbing the
ring mutex means potentially sleeping. Deal with both of these by always
running the tasklet from a work handler.
Also, protect from clip list changes since the vblank request was queued by
making sure the window has at least one rectangle while looking inside,
preventing oopses .
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise, if we lost the race, the pipestat bit would be set without being
reflected in IIR, and we would never clear the pipestat bit so the pipe
event would never be generated again, and all vblank waits would time out.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If the failing paths were hit, the vblank IRQ would never get turned off
again.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Current Intel errata for the GM965 says that using MSI may cause interrupts
to be delayed or lost. The only workaround offered is to not use it.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This uses the same spinlock as the user_irq code as it shares the same
register, ensuring that interrupt registers are updated atomically.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Hannes Eder