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...
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.
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.
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.
This fixes registration when MSI is set up after the stub function fills in
dev->irq. Otherwise /proc/interrupts would report attachment to the fasteoi
interrupt. dev->irq is still exposed (and updated at IRQ setup)
for the drivers that use it for whatever reason.
In leavevt_ioctl, queue an MI_FLUSH and then block waiting for it to
complete. This will empty the active and flushing lists. That leaves only
the inactive list to evict.
Pin/unpin need to know whether to remove/add objects from the inactive list,
inactive objects cannot be in any GPU write domain as those would be on the
flushing list instead. However, inactive objects may be in the CPU write
domain.
Now that gem_object_unbind waits for rendering to complete, objects should
not be active when they are being pulled from the GTT. BUG_ON if this is
broken.
Record the last execbuffer sequence for each client.
Record that sequence in the throttle ioctl as the 'throttle sequence'.
Wait for the last throttle sequence in the throttle ioctl.
When i915_wait_request clears object from the active list, it may end up
freeing them and not moving them to the inactive list. This ends up
unbinding objects from the GTT without there ever being new objects visible
to i915_gem_evict_something on the inactive list. As the only success
condition required the presence of objects on the inactive list, this would
falsely assume that no GTT space had been made available, and end up
returning -ENOMEM to the application.
We want request retirement to occur about once a second when the request
queue is non-empty. This was done with a timer that queued a work_struct,
using a delayed_work instead makes a lot more sense.
Use GEM for ring buffer setup and framebuffer allocation. This means reworking
the hardware status page stuff a bit (just use the basic range allocator for
vram for now) and #ifdef'ing out the TTM & DRI2 code. Works well enough to
load/unload several times and display fbcon on my T61 (though there's still
some unexplained console corruption).
This is the create (may want location flags), pread/pwrite/mmap
(performance tuning hints), and set_domain (will 32 bits be enough for
everyone?) ioctls. Left in the generic set are just flink/open/close.
The 2D driver must be updated for this change, and API but not ABI is broken
for 3D. The driver version is bumped to mark this.
Use new GEM based ring buffer initialization. Still need to init GEM & use it
for framebuffer allocation etc.
Conflicts:
shared-core/i915_dma.c
shared-core/i915_drv.h
This requires that the X Server use the execbuf interface for buffer
submission, as it no longer has direct access to the ring. This is
therefore a flag day for the gem interface.
This also adds enter/leavevt ioctls for use by the X Server. These would
get stubbed out in a modesetting implementation, but are required while
in an environment where the device's state is only managed by the DRM while
X has the VT.
Port over EDID quirks from X.Org so we can handle more monitors. This meant
adding size info to the drm_display_mode struct, but other than that the
changes were isolated to the DRM EDID handling code (as they should be).
Without the user IRQ running constantly, there's no wakeup when the ring
empties to go retire requests and free buffers. Use a 1 second timer to make
that happen more often.
