| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
|
|
modesetting-101
Conflicts:
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
|
|
modesetting-101
Conflicts:
shared-core/i915_dma.c
|
|
Texture uploads could hit the blitter coordinate limit, adjust the texture
offset when uploading the pieces. Make sure to check the end address of the
upload too.
|
|
|
|
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
|
|
|
|
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 makes sure each blit starts as early as possible, which may improve
texture upload performance in some cases.
|
|
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
|
|
There can still be other contexts that may use page flipping later on, so don't
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.
|
|
This is precursor to getting a TTM backend for this stuff, and also
allows the PCI table to be allocated at fb 0
|
|
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 .
|
|
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.
|
|
when enabling/disabling vertex programs
|
|
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.
|
|
|
|
remove a mach64 warning, align a lot of things from linux kernel
|
|
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.
|
|
When this succeeds, userspace can read the scratch register contents from the
mapped writeback page directly.
|
|
|
|
packet type for making it possible to address whole tcl vector space
and have a larger count)
|
|
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.
|
|
|
|
|
|
|
|
perfect but should be very safe... align some other kernel bits i810
align with kernel
|
|
|
