| Age | Commit message (Collapse) | Author |
|---|
|
this at least parses the DDX stream and lets me run gnome-terminal/metacity
|
|
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.
|
|
|
|
|
|
|
|
RS400 (intel based IGP) and RS480 (AMD based IGP) have
different MC and GART setups. Currently we only support
RS480.
|
|
|
|
Similar (broken) code in mesa needs to be removed
|
|
|
|
|
|
|
|
|
|
|
|
first step in merging rs4xx/rs6xx gart setup
|
|
|
|
This needs to be tested thoroughly before pushing to the
kernel.
|
|
This updated microcode is not in use yet.
|
|
This is the correct fix for the RS690 and hopefully the dma coherent work.
For now we limit everybody to a 32-bit DMA mask but it is possible for
RS690 to use a 40-bit DMA mask for the GART table itself,
and the PCIE cards can use 40-bits for the table entries.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
The docs state bits 4-11 represent bits 32-39 of a 40-bit address
|
|
This adds support for configuring the RS690 GART.
|
|
As DRM_DEBUG macro already prints out the __FUNCTION__ string (see
drivers/char/drm/drmP.h), it is not worth doing this again. At some
other places the ending "\n" was added.
airlied:- I cleaned up a few that this patch missed also
|
|
|
|
|
|
fix up a range that may be needed for r500 mesa
|
|
|
|
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.
|
|
Kernel "cleanfile" script run.
|
|
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.
|
|
The data is now in kernel space, copied in/out as appropriate according to the
This results in DRM_COPY_{TO,FROM}_USER going away, and error paths to deal
with those failures. This also means that XFree86 4.2.0 support for i810 DRM
is lost.
|
|
As a fallout, replace filp storage with file_priv storage for "unique
identifier of a client" all over the DRM. There is a 1:1 mapping, so this
should be a noop. This could be a minor performance improvement, as everything
on Linux dereferenced filp to get file_priv anyway, while only the mmap ioctls
went the other direction.
|
|
This was used to make all ioctl handlers return -errno on linux and errno on
*BSD. Instead, just return -errno in shared code, and flip sign on return from
shared code to *BSD code.
|
|
|
|
|
|
|
|
|
|
This add support for CRTC2 vblank on radeon similiar to the i915 support
|
|
|
|
|
|
|
|
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.
|
|
This is precursor to getting a TTM backend for this stuff, and also
allows the PCI table to be allocated at fb 0
|
|
This code doesn't enable a variable aperture it just modifies the codebase
to allow me fix it up later
|
|
The overflows could lead to the AGP aperture overlapping the framebuffer area
in the card's address space when the latter is located at the very end of the
32 bit address space, which would result in a freeze on X server startup,
probably because the card read commands from the framebuffer instead of from
AGP.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392915 .
|
|
|
|
This reverts af7b89d7246efbed7d05c38fcaa6a13c4b89db90 commit. It causes an oops
on X server shutdown here, and for the reporter of bug #7629 as well.
|
|
Commit 2a47f6bfecea5dabcbf79d5e1aaf271f50070b89 caused the CHIP_IS_AGP flag to
get 'restored' with PCI(e) cards. I can't think of a way to fix this without
introducing a (otherwise redundant) CHIP_IS_PCI flag.
|
|
|
|
The latter seems to be a read-only mirror of the former.
|
