| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
radeon-ttm
Conflicts:
linux-core/ati_pcigart.c
linux-core/drmP.h
linux-core/radeon_buffer.c
|
|
|
|
ioctl wrapper
|
|
|
|
|
|
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
|
|
- use a timer for disabling vblank events to avoid enable/disable calls too
often
- make i915 work with pre-965 chips again (would like to structure this
better, but this hack works on my test system)
|
|
If the driver doesn't support vertical blank interrupts, it won't call
drm_vblank_init(), and dev->num_crtcs will be 0.
Also fix an off-by-one test against dev->num_crtcs.
|
|
|
|
- use correct refcount variable in get/put routines
- extract counter update from drm_vblank_get
- make signal handling callback per-crtc
- update interrupt handling logic, drivers should use drm_handle_vblank
- move wakeup and counter update logic to new drm_handle_vblank routine
- fixup usage of get/put in light of counter update extraction
- fix longstanding bug in signal code, update pending counter only
*after* we're sure we'll setup signal handling
|
|
- move pre/post modeset ioctl to core
- fixup i915 buffer swap
- fix outstanding signal count code
- create new core vblank init routine
- test (works with glxgears)
- simplify i915 interrupt handler
|
|
of vblank interrupt in order to save power.
|
|
|
|
ttm test runs with it at least, needs to do more testing on it
|
|
|
|
|
|
Conflicts:
shared-core/radeon_drv.h
|
|
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 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>
|
|
This makes the drms use of the list handling macros a lot cleaner
and more along the lines of how they should be used.
|
|
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
|
|
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.
|
|
|
|
|
|
|
|
|
|
We need to keep a list of user created fbs to nuke on master exit.
We also need to use the bo properly.
|
|
|
|
|
|
X.org calls this crtc_config but this is a bad name and will confuse ppl later
(and me now :-)
|
|
The IGPGART setup code was traced using mmio-trace on fglrx by myself
and Phillip Ezolt <phillipezolt@gmail.com> on dri-devel.
This code doesn't let the 3D driver work properly as the card has no
vertex shader support.
Thanks to Matthew Garrett + Ubuntu for providing me some hardware to do this
work on.
|
|
fixup drm_crtc.c so it matches VGA and other outputs properly.
make drm_crtc.c less verbose.
add function declarations in drm_crtc.h for other files.
|
|
|
|
|
|
|
|
|
|
|
|
This code doesn't enable a variable aperture it just modifies the codebase
to allow me fix it up later
|
|
|
|
|
|
Fix up some header incompatibilities in drm_fence.c caused by the previous
commit.
|
|
|
|
|
|
|
|
Add refcounting of user waiters to the DRM hardware lock, so that we can use the
DRM_LOCK_CONT flag more conservatively.
Also add a kernel waiter refcount that if nonzero transfers the lock for the kernel context,
when it is released. This is useful when waiting for idle and can be used
for very simple fence object driver implementations for the new memory manager.
It also resolves the AIGLX startup deadlock for the sis and the via drivers.
i810, i830 still require that the hardware lock is really taken so the deadlock remains
for those two. I'm not sure about ffb. Anyone familiar with that code?
|
|
Fixed memory, pinned buffers and unmappable memory now seems
fully functional.
|
