- Apr 10, 2009
-
-
Jesse Barnes authored
-
Jesse Barnes authored
This reverts commit cd5c66c6. It broke too many kernel assumptions about the double ioctl (connector status, mode fetching, etc.)
-
- Apr 09, 2009
-
-
Kristian Høgsberg authored
-
Kristian Høgsberg authored
-
Kristian Høgsberg authored
-
- Apr 06, 2009
-
-
Dave Airlie authored
no idea if this is correct but it works so meh
-
Kristian Høgsberg authored
This lets us do make distcheck as non-root.
-
Kristian Høgsberg authored
They're writing to the read end of a pipe and failing.
-
Kristian Høgsberg authored
-
- Mar 31, 2009
-
-
Robert Noland authored
This may prevent a possible panic on shutdown.
-
- Mar 30, 2009
-
-
Jesse Barnes authored
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>
-
Stuart Bennett authored
-
Jesse Barnes authored
This version includes GTT unmap support for the Intel bufmgr.
-
- Mar 26, 2009
-
-
Jesse Barnes authored
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>
-
- Mar 25, 2009
-
-
Stuart Bennett authored
-
Stuart Bennett authored
-
Stuart Bennett authored
NV04 had a PFB_FIFO_DATA at the same address, which we don't use, so remove it to reduce confusion
-
- Mar 24, 2009
-
-
Ben Skeggs authored
-
- Mar 20, 2009
-
-
Ben Skeggs authored
-
Ben Skeggs authored
-
Ben Skeggs authored
-
- Mar 19, 2009
-
-
Maarten Maathuis authored
- This was causing a significant memory leak.
-
- Mar 18, 2009
-
-
Ben Skeggs authored
bo_handle_ref on !mm_enabled treats handle as an offset, make bo_handle_get do the same rather than failing.
-
- Mar 16, 2009
-
-
Robert Noland authored
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>
-
Robert Noland authored
disabled by default until the rest of the patches are in.
-
Robert Noland authored
This also adds that ability to set device name from VPD, but that doesn't seem to be working...
-
Robert Noland authored
-
Robert Noland authored
-
Robert Noland authored
We also don't support anything old enough to need tsleep.
-
Robert Noland authored
I noticed that we were computing drm_order differently than linux.
-
Robert Noland authored
-
Robert Noland authored
We can have more than 3 BARs to access.
-
Robert Noland authored
This prevents some warnings with nouveau.
-
- Mar 09, 2009
-
-
Robert Noland authored
-
Robert Noland authored
-
Robert Noland authored
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>
-
- Mar 05, 2009
-
-
Ben Skeggs authored
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!
-
Robert Noland authored
-
Robert Noland authored
-