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.
The interrupt identity register must be writen before any work occurs lest
we drop an interrupt on the floor. This patch just shuffles code around to
make sure that IIR is written as early as possible.
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.
In the short-circuit code for the breadcrumb already being new enough, we
need to update the sarea_priv copy of the breadcrumb just as if we had
waited. Otherwise userland error checking will notice that we returned
too early based on its wrong information, and call wait_irq again (leading
to spinning until someone else comes along and updates the sarea_priv).
This bug was hidden when we had interrupt masking disabled, such as in
master, since the interrupt handler would update sarea_priv.
Thanks to Thomas Hellstrom for catching the issue, no thanks to the kernel
developer who authoritatively told me that they would get restarted on their
own.
This was insufficient once we started masking interrupts to only when someone
was waiting for them (and would thus retire requests themselves). It was
replaced by the retire_timer.
This patch should fixe hard lockup and convert them in
softlockup (ie you can ssh the box but the gpu is busted
and we are waiting in loop for it to come back to reason).
We need a version to depend on from the other components that require GEM and
the bufmgr code. Some interfaces will be removed before the 2.4.0 release.
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).
This seems to be the key to getting at least some radeon
cards working. Most, if not all drivers need it enabled,
so just request it once the driver has attached.
Keith Packard
Robert Noland
Eric Anholt
Jerome Glisse
Ian Romanick
Jesse Barnes
Alex Deucher
Jesse Barnes
Dave Airlie
Robert Noland
Dave Airlie