| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit 727d4f1d1667e43b3558bd5f6ed6dc2cd9c29401, somehow git
deleted the symlink and replaced it with the file.
|
|
When scheduled swaps occur, we need to blit between front & back buffers. If
the buffers are tiled, we need to set the appropriate XY_SRC_COPY tile bit, but
only on 965 chips, since it will cause corruption on pre-965 (e.g. 945).
Bug reported by and fix tested by Tomas Janousek <tomi@nomi.cz>.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
On 9xx chips, bus mastering needs to be enabled at resume time for much of the
chip to function. With this patch, vblank interrupts will work as expected
on resume, along with other chip functions. Fixes kernel bugzilla #10844.
Signed-off-by: Jie Luo <clotho67@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
|
|
|
|
|
|
- I do not fully understand these blobs, so i'm leaving it at this for the moment.
|
|
|
|
|
|
|
|
|
|
This reverts commit 13943fe5823c45759091c1a1f487a4abe377421e.
|
|
- intel_crt seems the only one to provide it, so init it there.
|
|
|
|
|
|
|
|
Leftover dev_priv from the move of the suspend/resume code into shared-core.
|
|
It would be nice if one day the DRM driver was the canonical source for
register definitions and core macros. To that end, this patch cleans things up
quite a bit, removing redundant definitions (some with different names
referring to the same register) and generally tidying up the header file.
|
|
|
|
|
|
A mis-spelled config option (was it spelled that way in the past?)
eliminated kmap_atomic_prot_pfn from core DRM.
|
|
Clean up queues, free objects. On the next entervt, unmark the hardware to
let the user try again (presumably after resetting the chip). Someday we'll
automatically recover...
|
|
Pin/copy_from_user/unpin through the GTT to eliminate clflush costs.
Benchmarks say this helps quite a bit.
|
|
|
|
|
|
|
|
|
|
- This avoids returning with a mode count of 0, thus not allocating space for the 2nd ioctl.
|
|
|
|
|
|
|
|
|
|
- I made it consistent with recent kernel fb code (maybe this is older bugged code?)
- Still i don't use this and i should leave it to others.
|
|
|
|
|
|
This tracks most of the interrupt-related status, including the
interrupt registers in the chip and the sequence number variables.
|
|
|
|
While waiting for the hardware to idle on leavevt or lastclose, poll
for the sync sequence number instead of waiting for an interrupt. This
allows the code to bail if the hardware hangs for some reason. Also, this
avoids issues with signals as the exisiting wait function is interruptible.
|
|
This adds gem_active, gem_flushing, gem_inactive, gem_request and gem_seqno
entries to monitor gem operation and help debug issues.
|
|
This allows device drivers to add proc files
|
|
find_or_create_page doesn't quite set up pages correctly; any newly created
pages aren't hooked into the shmem object quite right; user space mmaps of
those pages end up mapping pages full of zeros which then get written to the
real pages inappropriately. This patch requires that the kernel export
shmem_getpage.
|
|
When a software fallback has completed, usermode must notify the kernel so
that any scanout buffers can be synchronized. This ioctl should be called
whenever a fallback completes to flush CPU and chipset caches.
|
|
Need to overhaul the mess that is driver ioctls
|
|
believing userspace causes oopses
|
|
Got tired of not having my LCD actually turn off when I left the machine at the
console.
|
|
Core MSI code will BUG() if an interrupt handler is still registered when
pci_disable_msi() is called.
|
|
Lots of conflicts, seems to load ok, but I'm sure some bugs snuck in.
Conflicts:
linux-core/drmP.h
linux-core/drm_lock.c
linux-core/i915_gem.c
shared-core/drm.h
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
|
|
|
|
Normally when X is running, panic messages will be invisible and the machine
will just appear to hard hang. This patch adds support for switching back to
the fbcon framebuffer on panic (through the use of a panic notifier
registration) so we can see what happened.
Note that in order to be really useful, X will have to run its VT in something
other than KD_GRAPHICS mode. Also, not all kernel errors result in panics,
some go through BUG() which may trigger another type of event, not resulting in
a switch.
|
