There can still be other contexts that may use page flipping later on, so do
just unilaterally 'clean it up', which could lead to the wrong page being
displayed, e.g. when running 3D apps with a GLX compositing manager such as
compiz using page flipping.
Signed-off-by: Dave Airlie <airlied@linux.ie>
radeon: make PCI GART aperture size variable, but making table size variable
This is precursor to getting a TTM backend for this stuff, and also
allows the PCI table to be allocated at fb 0
radeon: add support for reverse engineered xpress200m
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.
Signed-off-by: Dave Airlie <airlied@linux.ie>
Replace r300_check_offset() with generic radeon_check_offset(), which doesn't
reject valid offsets when the framebuffer area is at the very end of the card's
32 bit address space. Make radeon_check_and_fixup_offset() use
radeon_check_offset() as well.
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=7697 .
only allow specific type-3 packets to pass the verifier instead of all for r100/r200 as others might be unsafe (r300 already does this), and add checking for these we need but aren't safe. Check the RADEON_CP_INDX_BUFFER packet on both r200 and r300 as it isn't safe neither.
Signed-off-by: Dave Airlie <airlied@linux.ie>
This takes up two more ring buffer entries per rectangle blitted but makes sure
the blit is performed top to bottom, reducing the likelyhood of tearing.
Signed-off-by: Dave Airlie <airlied@linux.ie>
The overflows could cause valid offsets to get rejected under some
circumstances, e.g. when the framebuffer resides at the very end of the card's
address space.
Signed-off-by: Dave Airlie <airlied@linux.ie>
When this succeeds, userspace can read the scratch register contents from th mapped writeback page directly.
Signed-off-by: Dave Airlie <airlied@linux.ie>
The radeon requires a VAP state flush when enabling/disabling
vertex programs on the r200 cards.
Signed-off-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add support for r200 vertex programs (R200_EMIT_VAP_PVS_CNTL, and new
packet type for making it possible to address whole tcl vector space
and have a larger count)
From: Roland Scheidegger (DRM CVS)
Signed-off-by: Dave Airlie <airlied@linux.ie>
Do a tcl state flush before accessing tcl vector space. This fixes some
more problems with flickering (bug #6637). drm may not be appropriate
place for this, since doing that flush there might both be overkill and
insufficient in some cases. However, it's hard to figure out when that
flush is needed, so this has to suffice. There does not seem to be a
performance penalty associated with it.
From: Roland Scheidegger (DRM CVS)
Signed-off-by: Dave Airlie <airlied@linux.ie>
If these were valid checks, we'd have already oopsed several
lines above where we were already dereferencing them.
DA: these used to be valid but other changes made them unnecessary.
Coverity: 776,777,778
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
This code reworks the radeon memory map so it works better
for newer r300 chips and for a lot of older PCI chips.
It really requires a new X driver in order to take advantage of this code.
From: Ben Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dave Airlie <airlied@linux.ie>
From: Andrew Morton <akpm@osdl.org>
drivers/char/drm/radeon_state.c: In function `radeon_cp_dispatch_texture':
drivers/char/drm/radeon_state.c:1653: warning: int format, different type arg
(arg 3)
drivers/char/drm/radeon_state.c:1661: warning: int format, different type arg
(arg 3)
drivers/char/drm/radeon_state.c:1689: warning: int format, different type arg
(arg 3)
sizeof() doesn't return an int.
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Dave Airlie <airlied@linux.ie>
This patch pull in a lot of changes from CVS to the main core DRM,
and updates the radeon driver to 1.21.0 that supports r300 texrect
and radeon card type ioctl.
Signed-off-by: Dave Airlie <airlied@linux.ie>
Rename the driver hooks in the DRM to something a little more understandable:
preinit -> load
postinit -> (removed)
presetup -> firstopen
postsetup -> (removed)
open_helper -> open
prerelease -> preclose
free_filp_priv -> postclose
pretakedown -> lastclose
postcleanup -> unload
release -> reclaim_buffers_locked
version -> (removed)
postinit and version were replaced with generic code in the Linux DRM (drivers
now set their version numbers and description in the driver structure, like on
BSD). postsetup wasn't used at all. Fixes the savage hooks for
initializing and tearing down mappings at the right times. Testing involved at
least starting X, running glxgears, killing glxgears, exiting X, and repeating.
Tested on: FreeBSD (g200, g400, r200, r128)
Linux (r200, savage4)
From: Eric Anholt <anholt@freebsd.org>
Signed-off-by: Dave Airlie <airlied@linux.ie>
I've been threatening this for a while, so no point hanging around.
This lindents the DRM code which was always really bad in tabbing department.
I've also fixed some misnamed files in comments and removed some trailing
whitespace.
Signed-off-by: Dave Airlie <airlied@linux.ie>
Add support for Radeon PCI Express cards (needs a new X.org DDX)
Also allows PCI GART table to be stored in VRAM for non PCIE cards
Signed-off-by: Dave Airlie <airlied@linux.ie>
Add support for GL_ATI_fragment_shader, new packets R200_EMIT_PP_AFS_0/1,
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)
From: Roland Scheidegger, David Airlie
Signed-off-by: David Airlie <airlied@linux.ie>
This adds initial r300 3D support to the radeon DRM.
From: Nicolai Haehnle, Vladimir Dergachev, and others.
Signed-off-by: David Airlie <airlied@linux.ie>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Michel Dänzer