| Age | Commit message (Collapse) | Author |
|---|
|
This extra increase was causing fence leaks on my system, due to create/user add already increasing it twice no need for a 3rd go.
|
|
|
|
|
|
This patch removes some obviously dead code spotted by the Coverity
checker.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
|
|
Debug print fix in drm_release().
Forgotten local variable init in drm_setversion().
Unnecessary put_user() in drm_addmap_ioctl().
ioctl->cmd check broken in drm_ioctl(); workaround.
|
|
|
|
|
|
The data is now in kernel space, copied in/out as appropriate according to the
This results in DRM_COPY_{TO,FROM}_USER going away, and error paths to deal
with those failures. This also means that XFree86 4.2.0 support for i810 DRM
is lost.
|
|
As a fallout, replace filp storage with file_priv storage for "unique
identifier of a client" all over the DRM. There is a 1:1 mapping, so this
should be a noop. This could be a minor performance improvement, as everything
on Linux dereferenced filp to get file_priv anyway, while only the mmap ioctls
went the other direction.
|
|
This was used to make all ioctl handlers return -errno on linux and errno on
*BSD. Instead, just return -errno in shared code, and flip sign on return from
shared code to *BSD code.
|
|
|
|
|
|
With this, all modules build again.
|
|
Fix by Simon Farnsworth, Bugzilla Bug #11542
http://bugs.freedesktop.org/show_bug.cgi?id=11542
|
|
|
|
|
|
This might break something, stdint.h inclusion in drm.h maybe required
but I'm not sure yet what platforms have it what ones don't.
|
|
|
|
Actually a NV04-NV50 ttm backend for both PCI and PCIEGART, but PCIGART
support for G8X using the current mm has been hacked on top of it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
libdrm/xf86drm.c
linux-core/drm_bo.c
linux-core/drm_fence.c
|
|
ioctl wrapper
|
|
Should be OK on G84 for a single channel, multiple channels *almost* work.
Untested on G80.
|
|
|
|
|
|
Dave Airlie pointed out on IRC that idr_replace lets us know if the ID hasn't
been allocated, so we don't need a special pointer value for allocated IDs that
don't have valid information yet.
|
|
There's a difference between a drawable ID not having valid drawable
information and not being allocated at all. Not making the distinction would
break i915 DRM swap scheduling with older X servers that don't push drawable
cliprect information to the DRM.
|
|
|
|
|
|
|
|
Buffer object dereference cleanup.
Add a struct drm_device member to fence objects:
This can simplify code, particularly in drivers.
|
|
|
|
For various reasons, this ioctl was a bad idea.
At channel creation we now automatically create DMA objects covering
available VRAM and GART memory, where the client used to do this themselves.
However, there is still a need to be able to create DMA objects pointing at
specific areas of memory (ie. notifiers). Each channel is now allocated a
small amount of memory from which a client can suballocate things (such as
notifiers), and have a DMA object created which covers the suballocated area.
The NOTIFIER_ALLOC ioctl exposes this functionality.
|
|
Earlier NV1X chips use the NV04 code, see previous commits about NV10 RAMFC
entry size.
|
|
|
|
|
|
Commit 9b01bd5b284bbf519b726b39f1352023cb5e9e69 introduced a
compat_ioctl handler for RADEON_SETPARAM, the sole purpose of which was
to handle the fact that on i386, alignof(uint64_t)==4.
Unfortunately, this handler was installed for _all_ 64-bit
architectures, instead of only x86_64 and ia64. And thus it breaks
32-bit compatibility on every other arch, where 64-bit integers are
aligned to 8 bytes in 32-bit mode just the same as in 64-bit mode.
Arnd has a cunning plan to use 'compat_u64' with appropriate alignment
attributes according to the 32-bit ABI, but for now let's just make the
compat_radeon_cp_setparam routine entirely disappear on 64-bit machines
whose 32-bit compat support isn't for i386. It would be a no-op with
compat_u64 anyway.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
|
|
|
