| Age | Commit message (Collapse) | Author |
|---|
|
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!
|
|
|
|
|
|
Intel 855 chips present the same pci id for both heads. This prevents
us from attaching to the dummy second head. All other chips that I
am aware of either only present a single pci id, or different ids
for each head so that we only match on the correct head.
|
|
ati pci gart to use bus_dma to handle the allocations. This fixes
a garbled screen issue on at least some radeons (X1400 tested).
|
|
This also means, that DRM_FULL_MM_COMPAT is always defined,
so it is dropped, too.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
This also means dropping the DRM_ODD_MM_COMPAT case.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
