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.
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.
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.
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.
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.
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.
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.
Without kernel modesetting, this requires cooperation of the userspace
modesetting driver. We may have to leave the vblank interrupt enabled otherwise
to avoid problems.
Only compensate when the driver counter actually appears to have moved
backwards.
The compensation deltas need to be incremental instead of absolute; drop the
vblank_offset field and just use atomic_sub().
Turns out the radeon driver is affected by the same problem that prompted i915
to revert to less useful counter flipping at the end of the vblank interval. In
the long term, we can hopefully implement more reliable methods to achieve
counter flipping at the beginning of vblank, but otherwise this should be an
acceptable workaround.
Eric Anholt
Jerome Glisse
Ian Romanick
Alex Deucher
Dave Airlie
Robert Noland
Dave Airlie
Robert Noland
Keith Packard
Dennis Kasprzyk
Michel Dänzer