| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
|
|
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
|
|
|
|
Pointed out by Roel Kluin on dri-devel.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
While re-writing this for modesetting, I find we disable writeback on
resume.
|
|
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
(No, we don't build via right now.)
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
|
|
Doing my part to make DRM_DEBUG more chatty...
|
|
|
|
|
|
|
|
ifdef out all the gem stuff for now. Also, the msi stuff isn't portable
the way it is... I'll try and fix that up sometime soon.
|
|
|
|
We shuffled all the links around to disconnect the entry, but
never free it. We would incorrectly free the last entry in the
hash chain if nothing matched.
|
|
|
|
sarea_priv needs to be NULL before i915_initialized is called to
properly reset it. The stale value produces a panic any time something
opens/closes drm without calling initialize. i.e. version checking
|
|
|
|
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
This resolves the panic on FreeBSD during VT switch, without attempting
any of the more lofty goals for the time being.
|
|
This patch allows you to --enable-udev, and will avoid having libdrm
make device nodes. If you are using udev, you should really --enable-udev
your libdrm.
|
|
Corresponding DDX patch at http://people.freedesktop.org/~stuart/nv0x-nv4x_suspend/
|
|
This resolves and issue on amd64 FreeBSD and it looks like the
linux ioctl syscall should be unsigned long as well.
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
|
|
|
|
If a specific tasklet shares data with irq context,
it needs to take a private irq-blocking spinlock within
the tasklet itself.
|
|
Store the global name in global_name, don't overwrite the gem_handle.
|
|
|
|
thanks to malc0 for pointing it out
|
|
To build i915 driver pass OS_HAS_GEM=1 to make for now
|
|
|
|
|
|
|
|
Conflicts:
shared-core/i915_dma.c
This brings in kernel support and userland interface for intel GEM.
|
|
While the bufmgr isn't thread-safe at the moment, we need it to be for shared
objects between contexts.
|
|
the nvidia driver does this, and it stops the error message appearing on nv40
|
|
another name
|
|
|
|
When i915_gem_retire_request has a flush which matches an object write
domain, clear the write domain. This will move the object to the inactive
list rather than the flushing list, avoiding trouble with objects left stuck
on the flushing list.
|
|
In i915_gem_object_wait_rendering, if the object write domain is being
written by the GPU, the appropriate flushing commands are written to the
device and an additional request queued to mark that flush. Finally, the
function blocks on that new request.
The bug was that the write_domain in the object was cleared before the
function blocked.
If the wait is interrupted by a signal, the flushing commands may still be
pending. With the current write_domain information lost, the restarted
syscall will drop right through the write_domain test as that value was
lost, and so the function will not block at all. Oops.
Fixed by simply moving the write_domain clear until after the wait_request
succeeds. Note that the restarted system call will generate an additional
flush sequence and request, but that should be 'harmless', aside from a
slight performance impact.
Someday we'll track flushing more accurately and clear write_domains more
efficiently, but for now, this should suffice.
This bug was discovered in the 2d gem development by running x11perf
-copypixwin500 and noticing that the window got cleared accidentally.
|
