| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
| |
consistantly. After a lengthy irc discussion it seems like we
shouldn't need to worry about them, but it's nice to know about.
MFC after: 3 days
|
|
|
|
|
|
|
|
| |
after vt switch or suspend. I can't really test this on Intel right now
but I think I've heard reports of it on radeon as well. I can't break
it on the radeon here.
MFC after: 3 days
|
|
|
|
|
|
|
| |
-Some irq/vblank related changes that hopefully will help.
-A little more cleanup while I'm here.
MFC after: 3 days
|
|
|
|
|
| |
Tested by: mav@
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
| |
We will use this method with nouveau
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
| |
We need this for nouveau
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
| |
I discovered that we were computing page_order differently than linux.
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
| |
Also, clean up some ifdef mess while I'm here.
MFC after: 3 days
|
|
|
|
|
|
|
| |
This is likely a NOOP for us, since I haven't ported the suspend/resume
code yet.
MFC after: 3 days
|
|
|
|
|
| |
Submitted by: vehemens <vehemens@verizon.net>
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
| |
resources during allocation, but not during map load. Also, zero the
buffers here.
MFC after: 3 days
|
|
|
|
|
|
|
| |
waiting for resources. It is really the load that we can't defer.
BUS_DMA_NOCACHE belongs on bus_dmamap_load() as well.
MFC after: 3 days
|
|
|
|
|
|
| |
-Calculate the scratch address correctly
MFC after: 10 days
|
|
|
|
| |
MFC after: 10 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tested on an HD3850 (RV670) on loan from Warren Block.
Currently, you need one of the following for this to be useful:
x11-drivers/xf86-video-radeonhd-devel (not tested)
xf86-video-ati from git (EXA works, xv is too fast)
xf86-video-radeonhd from git (EXA works, xv works)
There is no 3d support available from dri just yet.
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
|
| |
at irq install/uninstall time, but when we vt switch, we uninstall the
irq handler. When the irq handler is reinstalled, the modeset ioctl
happens first. The modeset ioctl is supposed to tell us that we can
disable vblank interrupts if there are no active consumers. This will
fail after a vt switch until another modeset ioctl is called via dpms
or xrandr. Leading to cases where either interrupts are on and can't
be disabled, or worse, no interrupts at all.
MFC after: 2 weeks
|
|
|
|
|
|
| |
Suggested by: jhb@
MFC after: 2 weeks
|
|
|
|
|
| |
Submitted by: jkim@
MFC after: 2 weeks
|
|
|
|
| |
MFC after: 2 Weeks
|
|
|
|
| |
MFC after: 2 weeks
|
|
|
|
|
|
| |
which report that they are capable of MSI, but don't work correctly.
MFC after: 2 weeks
|
|
|
|
| |
MFC after: 2 weeks
|
|
|
|
|
|
| |
with a localized version.
MFC after: 2 weeks
|
|
|
|
|
|
|
|
| |
- Remove the old TTM interface
- Move register definitions to i915_reg.h
- Overhaul the irq handler
MFC after: 2 weeks
|
|
|
|
|
|
|
| |
Now that it doesn't use it anymore, get right of the taskqueue
and locked task support.
MFC after: 2 weeks
|
|
|
|
| |
MFC after: 2 weeks
|
|
|
|
|
|
|
| |
When I was LOCK_PROFILING this was pretty high up and there is no
reason for it.
MFC after: 2 weeks
|
|
|
|
| |
MFC after: 2 weeks
|
|
|
|
|
| |
Approved by: kib
Obtained from: drm git
|
|
|
|
| |
Approved by: kib
|
|
|
|
|
| |
Approved by: kib@
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
| |
Intel 855 chips present the same pci id for both heads. This prevents
us from attaching to the dummy second head. All other chips that I
am aware of either only present a single pci id, or different ids
for each head so that we only match on the correct head.
Approved by: kib@
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
| |
ati pci gart to use bus_dma to handle the allocations. This fixes
a garbled screen issue on at least some radeons (X1400 tested). It is
also likely that this is the correct fix for PR# 119324, though that
is not confirmed yet.
Reviewed by: jhb@ (mentor, prior version)
Approved by: kib@
MFC after: 2 weeks
|
|
|
|
|
|
|
|
| |
rs400/rs480 should clear the RADEON_BUS_MASTER_DIS bit. This should get
the rs485 IGP chips going again.
Approved by: jhb (mentor)
Obtained from: drm git master
|
|
|
|
|
|
|
| |
rs400 is just like rs480
Approved by: jhb (mentor)
Obtained from: drm git
|
|
|
|
|
|
| |
This was causing the newer Intel video drivers to fail and abort X.
Approved by: jhb (mentor)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Olaf Kirch noticed that the i915_set_status_page() function of the i915
kernel driver calls ioremap with an address offset that is supplied by
userspace via ioctl. The function zeroes the mapped memory via memset
and tells the hardware about the address. Turns out that access to that
ioctl is not restricted to root so users could probably exploit that to
do nasty things. We haven't tried to write actual exploit code though.
It only affects the Intel G33 series and newer.
Approved by: bz (secteam)
Obtained from: Intel drm repo
Security: CVE-2008-3831
|
|
|
|
|
|
|
|
| |
but I inadvertently overwrote the change when I synced to git. Commit
the fix in both places, so this doesn't happen again.
Approved by: jhb (mentor)
MFC after: 2 weeks
|
|
|
|
|
|
|
|
| |
reintroduced it with the sync to git master. Commit the fix in both
places this time.
Approved by: jhb (mentor)
MFC after: 2 weeks
|