| Age | Commit message (Collapse) | Author |
|---|
|
New API, new version.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Scanout buffers need to be freed through the kernel as it holds a reference
to them; exposing this API allows applications allocating scanout buffers to
flag them as not reusable.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
Avoid failure to build on old kernels with CONFIG_BACKLIGHT_CLASS_DEVICE set
|
|
|
|
Add assertions to drm_intel_gem_bo_reference,
drm_intel_gem_bo_reference_locked and drm_intel_gem_bo_unreference_locked
that the object has not been freed (refcount > 0). Mistakes in refcounting
lead to attempts to insert a bo into a free list more than once which causes
application failure as empty free lists are dereferenced as buffer objects.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Fixes assertion failures on later use of the object.
|
|
|
|
|
|
|
|
Who needs 2.4.8 anyway?
|
|
|
|
This reverts commit cd5c66c659168cbe2e3229ebf8be79f764ed0ee1. It broke too
many kernel assumptions about the double ioctl (connector status, mode
fetching, etc.)
|
|
|
|
|
|
|
|
no idea if this is correct but it works so meh
|
|
This lets us do make distcheck as non-root.
|
|
They're writing to the read end of a pipe and failing.
|
|
|
|
This may prevent a possible panic on shutdown.
|
|
This patch speeds up drmModeGetConnector by pre-allocating mode &
property info space before calling into the kernel. In many cases this
pre-allocation will be sufficient to hold the returned values (it's easy
enough to tweak if the common case becomes larger), which means we don't
have to make the second call, which saves a lot of time.
Acked-by: Jakob Bornecrantz <wallbraker@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
|
|
This version includes GTT unmap support for the Intel bufmgr.
|
|
libdrm has some support for GTT mapping already, but there are bugs
with it (no surprise since it hasn't been used much).
In fixing 20803, I found that sharing bo_gem->virtual was a bad idea,
since a previously mapped object might not end up getting GTT mapped,
leading to corruption. So this patch splits the fields according to
use, taking care to unmap both at free time (but preserving the map
caching).
There's still a risk we might run out of mappings (there's a sysctl
tunable for max number of mappings per process, defaulted to 64k or so
it looks like) but at least GTT maps will work with these changes (and
some others for fixing PAT breakage in the kernel).
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
|
|
IGPs
|
|
NV04 had a PFB_FIFO_DATA at the same address, which we don't use, so
remove it to reduce confusion
|
|
|
|
|
|
|
|
|
|
- This was causing a significant memory leak.
|
|
bo_handle_ref on !mm_enabled treats handle as an offset, make
bo_handle_get do the same rather than failing.
|
|
drm_handle_t is defined to be a u32 on linux and a u64 on everything
else. This addresses an issue on FreeBSD amd64 where the map offsets
may be greater than 32bits. When the handle is cast to 32bit, mmap
cannot match the requested map and causes X to crash.
This should be a NOOP on linux since drm_handle_t is always 32bit.
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
disabled by default until the rest of the patches are in.
|
|
This also adds that ability to set device name from VPD, but that
doesn't seem to be working...
|
|
|
|
|
|
We also don't support anything old enough to need tsleep.
|
|
I noticed that we were computing drm_order differently than linux.
|
|
|
|
We can have more than 3 BARs to access.
|
|
This prevents some warnings with nouveau.
|
|
|
|
|
|
Allow it to sleep waiting for resources during the allocation stage.
Only use BUS_DMA_NOWAIT when loading the map.
|
|
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
NV04 was completely busted. Push buffers were getting allocated at the
end of VRAM, overwriting PRAMIN. So, it turns out PRAMIN is in VRAM on
all chips. Question answered!
|
