| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
IGPs
|
|
NV04 had a PFB_FIFO_DATA at the same address, which we don't use, so
remove it to reduce confusion
|
|
We also don't support anything old enough to need tsleep.
|
|
NV04 was completely busted. Push buffers were getting allocated at the
end of VRAM, overwriting PRAMIN. So, it turns out PRAMIN is in VRAM on
all chips. Question answered!
|
|
This also means dropping the DRM_ODD_MM_COMPAT case.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
|
|
|
|
|
|
|
|
-Remove the old TTM interface
-Move register definitions to i915_reg.h
-Rework the irq handler
|
|
|
|
Several nvidia-based systems don't support backlight control via the
standard ACPI control mechanisms. Instead, it's necessary for the driver
to modify the backlight control registers directly. This patch adds
support for determining whether the registers appear to be in use, and
if so registers a kernel backlight device to control them. The backlight
can then be controlled via existing userspace tools.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
NVIDIA do this fun little sequence after updating the PRAMIN page tables.
On 9xxx chips, none of the PRAMIN BAR bindings (except the initial one)
worked, hence the majority of the setup needed to create a channel
ended up in the wrong place, causing all sorts of fun.
This is done by NVIDIA on nv8x chips also, so we'll do it for them too,
even though they appear to work without it.
|
|
It won't work yet, just like the other 9xxx chips. Real soon now :)
|
|
I'm not 100% sure that the nv94 one we were using won't work. The context
layouts are identical (well.. same ctxprog, so of course!), only a couple
of registers differ. But, be safe until we actually get some 9xxx chips
working.
|
|
Suprisingly the card still worked without this...
|
|
Our PFIFO/PGRAPH context save/load functions don't really work well
(at all?) on nv5x yet. Depending on what random state the card is
in before the drm loads, fbcon probably won't work correctly.
Luckily we've setup the GPU in such a way that it'll actually do a
hw context switch for the first context. Not sure of how successful
this'd be currently on the older chips (actually, pretty sure it won't
work), so NV50 only for now.
|
|
Fixes nouveau_ioctl_mem_free Oops
|
|
Use of the new bits is guarded with a mm_enabled=0 hardcode.
|
|
|
|
Bug exposed by DDX change d9da090c
|
|
|
|
This patch tries to use the available fence count to figure out whether a
given batch can succeed or not (just like the aperture check).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
ctxprog seen in okias' trace identical to one we use on NV94, assuming
the initial context values for NV94 will work here too.
|
|
|
|
|
|
|
|
|
|
The values are really going to continue meaning pipe, not plane, and that's
what they're called in the kernel copy of the header. Userland hasn't ever
made the switch to pipe!=plane, since userland checks are based on DRM
version, which is still stuck at 1.6. However, Mesa did start using
plane[AB] names, so provide a compat define.
|
|
|
|
Add mode setting files to libdrm, including xf86drmMode.* and the new
drm_mode.h header. Also add a couple of tests to sanity check the
kernel interfaces and update code to support them.
|
|
This reverts commit 6656db10551bbb8770dd945b6d81d5138521f208.
We really just want the libdrm and ioctl bits, not all the driver
stuff.
|
|
|
|
|
|
I either messed up when I pulled these from a mmio-trace last time, or
the previous values didn't work on my card. Hopefully it's the former!
In any case, at least one of the original NV50 chipsets work now.
|
|
Since the TTM type isn't upstream yet, we need to make sure libdrm uses
what the kernel uses, which is _DRM_GEM = 6.
|
|
GEM is upstream, but TTM isn't, so _DRM_GEM needs to be 6, not 7.
|
|
|
|
into modesetting-gem
|
|
A small subset of CS need to be atomic (relocation+IB commit to
ring) right now, because of the way relocation are handled, we
need to protect the whole ioctl.
|
|
Conflicts:
libdrm/Makefile.am
libdrm/intel/intel_bufmgr.h
libdrm/intel/intel_bufmgr_fake.c
libdrm/intel/intel_bufmgr_gem.c
shared-core/drm.h
shared-core/i915_dma.c
shared-core/i915_irq.c
shared-core/radeon_cp.c
shared-core/radeon_drv.h
|
|
Add a drm_intel_gem_bo_map_gtt() function for mapping a buffer object
through the aperture rather than directly to its CPU cacheable memory.
|
|
|
|
This is to fill in the gaps left by the removal of
the hotplug ioctls. And they also look better :)
|
