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.
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.
A check in drm_sysfs_connector_remove was supposed to allow it to be called
even with unregistered objects, to make cleanup paths a little simpler.
However, device_is_regsitered didn't always seem to return what we thought it
would, so we'd sometimes end up leaving objects lying around rather than
unregistering them.
Fix this situation up by requiring devices to be registered before being
removed. Any problems resulting from this change should be easier to track
down than the alternative (which is leaving kobjects registered after unload).
We need to initialize the edid_blob_ptr to NULL when we init a connector,
otherwise drm_mode_connector_update_edid_property may think there's a valid
EDID lying around and try to destroy it, causing a crash.
Idea being if you want to add new crtc/output/encoder dynamically later,
you just increase the generation counter and userspace should re-read
all the resources
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.
This reverts commit 6671ad1917.
The vblank ioctl needs to update the userspace parameters when interrupted by
a signal, which was prevented by this. Let's see if this breaks other ioctls...
