| Age | Commit message (Collapse) | Author | 
|---|
|  | 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. | 
|  | i915_add_request was calling schedule_delayed_work before adding the request
to the list; it makes more sense to do that last. | 
|  |  | 
|  | 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. | 
|  |  | 
|  | 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. | 
|  | This fixes a regression from commit d434b64f6a760d85295e32298a9a1f3624ee1b69
which could cause us to fail to wake up for user interrupts if we lost a race. | 
|  | We no longer need to use it to protect against shared ringbuffer access. | 
|  | This reduces the diff from Mesa and reduces the illegibility of what I did. | 
|  |  | 
|  | 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. | 
|  |  | 
|  | They are not unnecessary since the kernel's the only thing touching the ring. | 
|  |  | 
|  | 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. | 
|  |  | 
|  | The driver can know what hardware requires MI_BATCH_BUFFER vs
MI_BATCH_BUFFER_START; there's no reason to let user mode configure this. | 
|  | 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. | 
|  | This goes with the other hardware status page patch. | 
|  | Instead of throttling and execbuffer time, have the application ask to
throttle explicitly. This allows the throttle to happen less often, and
without holding the DRM lock. | 
|  | Place the buffer reuse links right into the dri_bo_gem object. | 
|  |  | 
|  | The code was discarding the dri_bo_gem structure and saving only the kernel
handle. This lost the mmap address, causing pain when the next buffer user
wanted to map the buffer. | 
|  | I couldn't get the re-allocated HWS to work on my 965GM, so I just gave up
and made it persist across the lifetime of the driver instead. | 
|  |  | 
|  |  | 
|  | This will be used by the X Server for VT switch. | 
|  | struct_mutex cannot be held while blocking on DRM lock. | 
|  |  | 
|  |  | 
|  |  | 
|  | Just renaming this function and related parameters to match terminology used
elsewhere in the driver. | 
|  | set_domain can block waiting for rendering to complete. If that process is
interrupted by a signal, it can return -EINTR. Catch this error in all
callers and correctly deal with the result. | 
|  | Conflicts:
	linux-core/Makefile.kernel
	shared-core/i915_drv.h
	shared-core/nouveau_state.c | 
|  | The problem was revealed where on 965, the display list vertex buffer would see:
create		      -> (CPU, CPU)
set_domain (CPU, CPU) -> (CPU, CPU)
set_comain (CPU, 0)   -> (CPU, 0) (no clflush occurred)
execbuf	   (GPU, 0)   -> (CPU+GPU, 0) (still no clflush)
instead of:
create		      -> (CPU, CPU)
set_domain (CPU, CPU) -> (CPU, CPU)
set_comain (CPU, 0)   -> (CPU, CPU)
execbuf	   (GPU, 0)   -> (CPU+GPU, 0) (clflushed) | 
|  |  | 
|  |  | 
|  | Otherwise, 965 constant state buffers get re-relocated every exec.  Ouch. | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | Also remove an unreachable unlock. | 
|  |  | 
|  |  | 
|  |  |