| Age | Commit message (Collapse) | Author |
|---|
|
of other fixes.
- Mark the correct RAMIN slots as free (oops)
- Remove a VRAM alloc that shouldn't have been there (oops)
- Move HT init out of firstopen() and into dma_init()
- Setup PFIFO_RAM{HT,FC,RO} in pfifo_init()
|
|
|
|
|
|
be committed soon after this. Without the change, MEMFORMAT_DMA_OUT appears
to have no effect.
|
|
|
|
|
|
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.
|
|
remove a mach64 warning, align a lot of things from linux kernel
|
|
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.
|
|
|
|
|
|
|
|
i915 vblanks can be generated from either pipe a or b, however a disabled
pipe generates no interrupts. This change allows the X server to select
which pipe generates vblank interrupts.
|
|
to lastclose.
|
|
|
|
-Remove out of memory error message.
-Move sman cleanup from final_context to lastclose.
-Add the P4VM800PRO (?) PCI ID.
|
|
|
|
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.
|
|
From: tilman
|
|
|
|
|
|
|
|
|
|
Linux, which broke on FreeBSD. DRM_COPY_*_IOCTL checks for the size
parameter matching the ioctl's command size there, since the copin/out
happened earlier.
|
|
|
|
|
|
perfect but should be very safe... align some other kernel bits i810
align with kernel
|
|
|
|
|
|
rv380, rv410), with the exception of the rs400 igps. Hopefully they no
longer lock up with new ddx, but no guarantees... (bug #5413)
|
|
|
|
|
|
|
