| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
mach64_state.c: convert the DRM_MACH64_BLIT ioctl to submit a pointer to
user-space memory rather than a DMA buffer index, similar to DRM_MACH64_VERTEX.
This change allows the DDX to map the DMA buffers read-only and eliminate a
security problem where a client can alter the contents of the DMA buffer after
submission to the DRM.
This change also affects the DRI/DRM interface. Performace-wise, it basically
affects PCI mode where I get a ~12% speedup for some Mesa demos I tested.
This is mainly due to eliminating an ioctl for allocating the DMA buffer.
mach64_dma.c: move the responsibility for allocating memory for the DMA ring
in PCI mode to the DDX.
This change affects the DDX/DRM interface and unifies a couple of PCI/AGP code
paths for ring memory in the DRM.
Bump the mach64 DRM version major and date.
|
|
Add DRM_PCI_BUFFER_RO flag for mapping PCI DMA buffer read-only. An additional
flag is needed, since PCI DMA buffers do not have an associated map.
|
|
Factor out from mach64_dma_dispatch_vertex() the code to reclaim an unsed
buffer, in preperation for using it in mach64_dma_dispatch_blit() also.
|
|
Factor out from mach64_freelist_get() the code to reclaim a completed buffer,
this is to improve readability for me.
|
|
Map the DMA buffers from the same linear address as the vertex bufs. If
dev->agp_buffer_token is not set, mach64 drm maps the DMA buffers from
linear address 0x0.
|
|
|
|
|
|
This fixes issues on X server startup with versions of xf86-video-intel that
enable the IRQ before they have a context ID.
|
|
It looks like 'after a while', I915REG_INT_IDENTITY_R for some reason always has
VSYNC_PIPEB_FLAG set in the interrupt handler, even though pipe B is disabled.
So we only increase dev->vbl_received if the corresponding bit is also set in
dev->vblank_pipe.
|
|
|
|
|
|
|
|
When this flag is set and the target sequence is missed, wait for the next
vertical blank instead of returning immediately.
|
|
|
|
|
|
Initialize it to default value if it hasn't been set by the X server yet.
In i915_vblank_pipe_set(), only update dev_priv->vblank_pipe and call
i915_enable_interrupt() if the argument passed from userspace is valid to avoid
corrupting dev_priv->vblank_pipe on invalid arguments.
|
|
Handle relative as well as absolute target sequence numbers.
Return error if target sequence has already passed, so userspace can deal with
this situation as it sees fit.
On success, return the sequence number of the vertical blank when the buffer
swap is expected to take place.
Also add DRM_IOCTL_I915_VBLANK_SWAP definition for userspace code that may want
to use ioctl() instead of drmCommandWriteRead().
|
|
This makes it easier for userspace to know when it needs to allocate an ID.
Also free drawable information memory when it's no longer needed.
|
|
|
|
This uses the core facility to schedule a driver callback that will be called
ASAP after the given vertical blank interrupt with the HW lock held.
|
|
|
|
|
|
Also improve diagnostic output.
|
|
Actually make the existing ioctls for adding and removing drawables do
something useful, and add another ioctl for the X server to update drawable
information. The only kind of drawable information tracked so far is cliprects.
|
|
When the vertical blank interrupt is enabled for both pipes, pipe A is
considered primary and pipe B secondary. When it's only enabled for one pipe,
it's always considered primary for backwards compatibility.
|
|
|
|
|
|
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.
|
|
|
|
This helps us unbreak FreeBSD DRM from the 965 changes.
|
|
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.
|
|
smack my whitespace up.
|
|
This is a patch prepared by Guangdeng Liao based off of Tungsten Graphics's
final code drop.
|
|
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.
|
|
This allows using AGP after overriding to PCI mode in a previous session
without reloading the DRM.
|
|
Not doing this might waste bus bandwidth or even cause memory corruption or
system crashes on systems that check bus transfers. No such incident has been
reported though.
|
|
When this succeeds, userspace can read the scratch register contents from the
mapped writeback page directly.
|
|
|
|
Sort the merged file, remove the redundant explicit .ko lines and add
some generated symlinks.
|
|
32-bit physical device addresses are mapped directly to user-tokens. No
duplicate maps are allowed, and the addresses are assumed to be outside
of the range 0x10000000 through 0x30000000. The user-token is identical
to the 32-bit physical start-address of the map.
64-bit physical device addressed are mapped to user-tokens in the range
0x10000000 to 0x30000000 with page-size increments. The user_token should
not be interpreted as an address.
Other map types, like upcoming TTM maps are mapped to user-tokens in the
range
0x10000000 to 0x30000000 with page-size increments. The user_token should
not be interpreted as an address.
This keeps compatibility with buggy drivers, while still implementing a
hashed map lookup. The SiS and via device driver major bumps are
reverted.
|
|
0x10000000 to 0x90000000 in PAGE_SIZE increments.
Implement hashed map lookups.
This potentially breaks both 2D and 3D drivers. If so, the corresponding
2D and 3D driver should be fixed, and it's corresponding drm device driver
should have its major bumped as soon as possible.
Bump sis and via drm device driver majors.
The SiS and Unichrome 3D drivers are fixed in Mesa CVS HEAD and
mesa_6_4_branch.
|
|
|
|
|
