Age | Commit message (Collapse) | Author |
|
|
|
|
|
This code relied on the CPU and GPU address for the aperture being the same,
On some r5xx hardware I was playing with I noticed that this isn't always true.
I wonder if this will fix some of those r4xx DRI issues we've seen in the past.
|
|
Conflicts:
linux-core/Makefile.kernel
linux-core/drm_stub.c
linux-core/i915_drv.c
shared-core/i915_dma.c
shared-core/i915_drv.h
Fixup suspend/resume conflicts (basically use what's in DRM master for now).
Also fix up a few other conflicts that snuck in (i915_dma changes etc.).
|
|
A bad idea, ABI-wise, but we're going to be changing this structure anyway
before we merge upstream, so just fix the build for now.
|
|
|
|
|
|
|
|
This mapping allows cached objects to be mapped in/out of the TT space
with the appropriate flushing calls.
It should put back the old CACHED functionality for snooped mappings
|
|
|
|
|
|
Conflicts:
linux-core/drmP.h
linux-core/drm_drv.c
linux-core/drm_irq.c
shared-core/i915_drv.h
shared-core/i915_irq.c
shared-core/mga_drv.h
shared-core/mga_irq.c
shared-core/radeon_drv.h
shared-core/radeon_irq.c
Merge in the latest master bits and update the remaining drivers (except
mach64 which math_b is working on). Also remove the 9xx hack from the i915
driver; it seems to be correct.
|
|
|
|
|
|
Use clflush on Intel hardware to flush cached objects.
|
|
|
|
These need to be kmalloc'd separately anyway or we may hit kmalloc size
limits.
|
|
early cards.
|
|
modesetting-101
Conflicts:
linux-core/Makefile.kernel
linux-core/drmP.h
shared-core/radeon_cp.c
shared-core/radeon_drv.h
shared-core/radeon_irq.c
modified: linux-core/Makefile.kernel
modified: linux-core/ati_pcigart.c
modified: linux-core/drmP.h
new file: linux-core/radeon_buffer.c
modified: linux-core/radeon_drv.c
new file: linux-core/radeon_fence.c
modified: shared-core/radeon_cp.c
modified: shared-core/radeon_drm.h
modified: shared-core/radeon_drv.h
modified: shared-core/radeon_irq.c
modified: tests/ttmtest/src/ttmtest.c
|
|
Add suspend/resume support to the i915 driver. Moves some of the
initialization into the driver load routine, and fixes up places where we
assumed no dev_private existed in some of the cleanup paths. This allows
us to suspend/resume properly even if X isn't running.
|
|
surface destination.
|
|
This is currently only compile tested.
|
|
Conflicts:
linux-core/Makefile.kernel
linux-core/drm_bo.c
linux-core/drm_objects.h
|
|
Set bo init minor to 0.
Add the version function to header.
|
|
Implement a version check IOCTL for drivers that don't use
drmMMInit from user-space.
Remove the minor check from the kernel code. That's really up
to the driver.
Bump major.
|
|
|
|
|
|
|
|
|
|
|
|
modesetting-101
|
|
|
|
|
|
of a hardware lock.
|
|
|
|
|
|
Add interface entry cleaning a memory type without touching NO_EVICT buffers.
|
|
Fix i915 since last commit.
|
|
Remove need for lock for now.
May create races when we clean memory areas or on takedown.
Needs to be fixed.
Really do a validate on buffer creation in order to avoid problems with
fixed memory buffers.
|
|
set pinning."
This reverts cf2d569daca6954d11a796f4d110148ae2e0c827 commit.
|
|
This reverts e7bfeb3031374653f7e55d67cc1b5c823849359f commit.
|
|
|
|
|
|
modesetting-101
Conflicts:
linux-core/drm_bo.c
linux-core/drm_objects.h
shared-core/i915_dma.c
shared-core/i915_drv.h
|
|
We now always create a drm_ref_object for user objects and this is then the only
things that holds a reference to the user object. This way unreference on will
destroy the user object when the last drm_ref_object goes way.
|
|
The buffer object type is still tracked internally, but it is no longer
part of the user space visible ioctl interface. If the bo create ioctl
specifies a non-NULL buffer address we assume drm_bo_type_user,
otherwise drm_bo_type_dc. Kernel side allocations call
drm_buffer_object_create() directly and can still specify drm_bo_type_kernel.
Not 100% this makes sense either, but with this patch, the buffer type
is no longer exported and we can clean up the internals later on.
|
|
|
|
|
|
|
|
|