| Age | Commit message (Collapse) | Author |
|---|
|
|
|
modesetting-101
Conflicts:
linux-core/drm_drv.c
linux-core/drm_fops.c
linux-core/drm_objects.h
linux-core/drm_stub.c
shared-core/i915_dma.c
|
|
|
|
Buffer object dereference cleanup.
Add a struct drm_device member to fence objects:
This can simplify code, particularly in drivers.
|
|
Add more debugging to help diagnose problems.
|
|
|
|
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>
|
|
|
|
|
|
|
|
Reported by Steve Wilkins / Michel Dänzer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit 6e860d08d0f5b1e9a2d711aaf9fd6b982aa8039e.
As I said not a good plan - this macro will have to stay for now,
trying to do the vbl code with the inline was a bit messy - may need specialised
drm wait on functions
|
|
This add support for CRTC2 vblank on radeon similiar to the i915 support
|
|
|
|
|
|
This cleans this code up a lot and uses the generic Linux idr which is
designed for this.
Signed-off-by: Dave Airlie <airlied@linux.ie>
|
|
Signed-off-by: Michel Dänzer <michel@tungstengraphics.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
|
|
This reverts commit 3fdef0dc2000308b16907b95f637c60acde80a74.
ditto not on master yet
|
|
This reverts commit 3dfc1400e9fc58c69292d7cf7c2e1653fa5e6991.
this shouldn't have gone on master yet
|
|
|
|
|
|
|
|
This is the first bunch of ioctls
|
|
This makes the drms use of the list handling macros a lot cleaner
and more along the lines of how they should be used.
|
|
also we should fail if we can't enable the device at resume time.
|
|
|
|
other drivers.
|
|
into origin/modesetting-101
Conflicts:
linux-core/drm_crtc.c - reconcile with locking changes
|
|
held across any operations that modify mode lists, crtc config, output
config, etc. It should be taken at high level entry points (currently just
initial config and user IOCTL).
Seems to work ok on my system, but needs more testing (with lockdep) and
review from some fresh eyes.
|
|
|
|
it a chance to allocate the memory from whichever buffer it wants to.
|
|
modesetting-101
Conflicts:
shared-core/i915_dma.c
|
|
|
|
|
|
|
|
|
|
into origin/modesetting-101
Conflicts:
linux-core/drm_crtc.c
linux-core/drm_fb.c
Lots of changes to merge with alanh's latest stuff:
o fix use of fb->pitch now that it has the right value
o add new helper for finding the CRTC given an FB
o fix new fb_probe/fb_remove functions to take a CRTC
o fixup callers of new FB routines
o port drm_fb changes to intel_fb
o check for errors after creating fb buffer object
o go back to using cfb_imageblit since the accel stubs aren't ready
|
|
Fix an overflow problem.
|
|
places).
Add new FB hooks to the drm driver structure and make i915 use them for an
Intel specific FB driver. This will allow acceleration and better handling
of the command stream.
|
