| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
-Remove the old TTM interface
-Move register definitions to i915_reg.h
-Rework the irq handler
|
|
|
|
This reverts commit 6656db10551bbb8770dd945b6d81d5138521f208.
We really just want the libdrm and ioctl bits, not all the driver
stuff.
|
|
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
|
|
This allows us to not crash X when using newer Intel ddx drivers.
|
|
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.
|
|
Conflicts:
libdrm/Makefile.am
libdrm/dri_bufmgr.h
linux-core/drm_irq.c
linux-core/drm_sysfs.c
linux-core/drm_ttm.c
shared-core/i915_dma.c
shared-core/i915_irq.c
shared-core/nouveau_drv.h
shared-core/radeon_cp.c
|
|
|
|
|
|
ifdef out all the gem stuff for now. Also, the msi stuff isn't portable
the way it is... I'll try and fix that up sometime soon.
|
|
sarea_priv needs to be NULL before i915_initialized is called to
properly reset it. The stale value produces a panic any time something
opens/closes drm without calling initialize. i.e. version checking
|
|
|
|
This resolves the panic on FreeBSD during VT switch, without attempting
any of the more lofty goals for the time being.
|
|
|
|
Conflicts:
libdrm/xf86drm.c
linux-core/Makefile.kernel
linux-core/drmP.h
linux-core/drm_compat.h
linux-core/drm_drv.c
linux-core/drm_stub.c
linux-core/drm_vm.c
shared-core/i915_dma.c
shared-core/r300_cmdbuf.c
shared-core/radeon_drv.h
|
|
Conflicts:
shared-core/i915_dma.c
This brings in kernel support and userland interface for intel GEM.
|
|
Conflicts:
linux-core/Makefile.kernel
linux-core/drmP.h
linux-core/drm_mm.c
linux-core/drm_stub.c
linux-core/i915_gem.c
linux-core/i915_opregion.c
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
This reverts commit 965a72202b439068e62ac341990f51953457b202.
Please re-do over properly
|
|
Conflicts:
linux-core/Makefile.kernel
linux-core/ati_pcigart.c
linux-core/drm_compat.h
linux-core/drm_irq.c
linux-core/drm_lock.c
linux-core/i915_drv.c
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
shared-core/nouveau_mem.c
shared-core/radeon_cp.c
shared-core/radeon_drv.h
|
|
|
|
This removes all the TTM userspace API and all userspace objects.
It also removes the drm_bo_lock.c code
|
|
|
|
|
|
Conflicts:
linux-core/Makefile.kernel
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
This resolves a panic on FreeBSD which was caused by trying
to re-initialize the swap lock. It's just much easier to
initialize all of the locks at load time. It should also
ensure that the vblank structures are available earlier.
|
|
modifications to make it work correctly on my test hardware (altered the
backlight write function, made it enable the legacy backlight controller
interrupts on mobile hardware, sorted the interrupt function so we don't
get an excessive number of vblank interrupts). This lets the backlight
keys on my T61 work properly, though there's a 750msec or so delay
between the request and the brightness actually changing - this sounds
awfully like the hardware spinning waiting for a status flag to become
ready, but as far as I can tell they're all set correctly. If anyone can
figure out what's wrong here, it'd be nice to know.
Some of the functions are still stubs and just tell the hardware that
the request was successful. These can be filled in as kernel modesetting
gets integrated. I think it's worth getting this in anyway, since it's
required for backlight control to work properly on some new platforms.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
|
Various chips have exciting interactions between the CPU and the GPU's
different ways of accessing interleaved memory, so we need some kernel
assistance in determining how it works.
Only fully tested on GM965 so far.
|
|
Conflicts:
linux-core/drmP.h
linux-core/drm_drv.c
linux-core/drm_stub.c
linux-core/i915_drv.c
linux-core/i915_gem.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
It would be nice if one day the DRM driver was the canonical source for
register definitions and core macros. To that end, this patch cleans things up
quite a bit, removing redundant definitions (some with different names
referring to the same register) and generally tidying up the header file.
|
|
When a software fallback has completed, usermode must notify the kernel so
that any scanout buffers can be synchronized. This ioctl should be called
whenever a fallback completes to flush CPU and chipset caches.
|
|
Lots of conflicts, seems to load ok, but I'm sure some bugs snuck in.
Conflicts:
linux-core/drmP.h
linux-core/drm_lock.c
linux-core/i915_gem.c
shared-core/drm.h
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
This fixes registration when MSI is set up after the stub function fills in
dev->irq. Otherwise /proc/interrupts would report attachment to the fasteoi
interrupt. dev->irq is still exposed (and updated at IRQ setup)
for the drivers that use it for whatever reason.
|
|
Record the last execbuffer sequence for each client.
Record that sequence in the throttle ioctl as the 'throttle sequence'.
Wait for the last throttle sequence in the throttle ioctl.
|
|
We want request retirement to occur about once a second when the request
queue is non-empty. This was done with a timer that queued a work_struct,
using a delayed_work instead makes a lot more sense.
|
|
This was insufficient once we started masking interrupts to only when someone
was waiting for them (and would thus retire requests themselves). It was
replaced by the retire_timer.
|
|
Use GEM for ring buffer setup and framebuffer allocation. This means reworking
the hardware status page stuff a bit (just use the basic range allocator for
vram for now) and #ifdef'ing out the TTM & DRI2 code. Works well enough to
load/unload several times and display fbcon on my T61 (though there's still
some unexplained console corruption).
|
|
This is the create (may want location flags), pread/pwrite/mmap
(performance tuning hints), and set_domain (will 32 bits be enough for
everyone?) ioctls. Left in the generic set are just flink/open/close.
The 2D driver must be updated for this change, and API but not ABI is broken
for 3D. The driver version is bumped to mark this.
|
|
Use new GEM based ring buffer initialization. Still need to init GEM & use it
for framebuffer allocation etc.
Conflicts:
shared-core/i915_dma.c
shared-core/i915_drv.h
|
|
This requires that the X Server use the execbuf interface for buffer
submission, as it no longer has direct access to the ring. This is
therefore a flag day for the gem interface.
This also adds enter/leavevt ioctls for use by the X Server. These would
get stubbed out in a modesetting implementation, but are required while
in an environment where the device's state is only managed by the DRM while
X has the VT.
|
|
Passed the compile test; it's ready to ship.
Conflicts:
libdrm/Makefile.am
linux-core/Makefile.kernel
linux-core/drmP.h
linux-core/drm_memrange.c
linux-core/drm_stub.c
shared-core/drm.h
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
|
|
The driver can know what hardware requires MI_BATCH_BUFFER vs
MI_BATCH_BUFFER_START; there's no reason to let user mode configure this.
|
|
The driver can know what hardware requires MI_BATCH_BUFFER vs
MI_BATCH_BUFFER_START; there's no reason to let user mode configure this.
|
|
Without the user IRQ running constantly, there's no wakeup when the ring
empties to go retire requests and free buffers. Use a 1 second timer to make
that happen more often.
|
|
This goes with the other hardware status page patch.
|
|
Instead of throttling and execbuffer time, have the application ask to
throttle explicitly. This allows the throttle to happen less often, and
without holding the DRM lock.
|
|
I couldn't get the re-allocated HWS to work on my 965GM, so I just gave up
and made it persist across the lifetime of the driver instead.
|
