Age | Commit message (Collapse) | Author |
|
requires --enable-radeon-experimental-api for now
|
|
This reverts commit 6656db10551bbb8770dd945b6d81d5138521f208.
We really just want the libdrm and ioctl bits, not all the driver
stuff.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
take code from Jerome munge into a TTM IB re-use
|
|
This is an initial import of the atom bios parser with modesetting support
for r500 hw using atombios. It also includes a simple memory manager
layer that translates a radeon GEM style interface onto TTM internally.
So far this memory manager has only been used for pinned object allocation
for the DDX to test modesetting.
|
|
modesetting-101
Conflicts:
shared-core/i915_dma.c
shared-core/i915_drv.h
|
|
|
|
Conflicts:
linux-core/Makefile.kernel
linux-core/drm_compat.c
linux-core/drm_fops.c
linux-core/drm_lock.c
shared-core/drm.h
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
This interface was defined completely wrong, however userspace has only
ever used 4 values from it (0x1, 0x2, 0x3 and 0x6), so fix the interface to do what userspace actually expected but define new defines for new users to use
it properly.
|
|
Limit frag address to 8 bits
|
|
|
|
Conflicts:
linux-core/drmP.h
shared-core/i915_dma.c
shared-core/i915_drm.h
shared-core/radeon_drv.h
|
|
Add a new get param to get the fb location into userspace. Mesa currently
hits MMIO to do this, but this isn't always possible.
|
|
Conflicts:
linux-core/drm_bufs.c
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
Kernel "cleanfile" script run.
|
|
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
|
|
|
|
Conflicts:
shared-core/radeon_drv.h
|
|
This add support for CRTC2 vblank on radeon similiar to the i915 support
|
|
|
|
This is precursor to getting a TTM backend for this stuff, and also
allows the PCI table to be allocated at fb 0
|
|
packet type for making it possible to address whole tcl vector space
and have a larger count)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
R200_EMIT_PP_TXCTLALL_0-5 (replaces R200_EMIT_PP_TXFILTER_0-5, 2 more
regs) and R200_EMIT_ATF_TFACTOR (replaces R200_EMIT_TFACTOR_0 (8 consts
instead of 6)
|
|
the driver already knew their correct value. For example the physical
address of the framebuffer and registers.
|
|
with BSD fix from jkim and the r300_reg.h license from Nicolai Haehnle.
Big thanks to everyone involved!
|
|
r200
|
|
cube maps (since it also requires a version bump) at the same time.
|
|
drm. Add new ioctls to manage surfaces which cover the tiled areas
|
|
clear and z buffer compression are working correctly, hierarchical-z is
not.
|
|
helping
2D operations.
Ups radeon to version 1.12.0, Vladimir, you might want to add any extra
pciids...
Approved-by: Dave Airlie <airlied@linux.ie>
|
|
weren't Lindent's because their comments didn't convert very well. A
bunch of other minor clean up with no code implact included.
|
|
dev_priv live always, and add AGP detection in kernel patch:
radeon-pre-2.patch From: Jon Smirl
|
|
|
|
GL_EXT_blend_func_separate and GL_EXT_blend_equation_separate on r200
|
|
|
|
allows the mesa drivers to use a single definition of the DRM
sarea/IOCTLS located in the drm driver directory. Adjustments were made
to the 2D drivers to not include these changes. Changes to the mesa
copy of DRM were copied to the DRI copy. XFree86 bug: Reported by:
Submitted by: Reviewed by: Obtained from:
|
|
the 2D driver initializes MC_FB_LOCATION and related registers sanely
the DRM deduces the layout from these registers
clients use the new SETPARAM ioctl to tell the DRM where they think the
framebuffer is located in the card's address space
the DRM uses all this information to check client state and fix it up if
necessary
This is a prerequisite for things like direct rendering with IGP chips and
video capturing.
|
|
appropriate
|