| Age | Commit message (Collapse) | Author |
|---|
|
Makes it build again.
|
|
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
|
|
Needed for the modesetting case where we initialize the ring at load time.
|
|
|
|
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
|
|
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
|
|
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
|
|
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).
|
|
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
|
|
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.
|
|
This splits a lot of the core modesetting code out into a file of
helper functions, that are only called from themselves and/or the driver.
The driver gets called into more often or can call these functions from itself
if it is a helper using driver.
I've broken framebuffer resize doing this but I didn't like the API for that
in any case.
|
|
Add code to get panel modes from the VBIOS if present and check whether certain
outputs exist. Should make our display detection code a little more robust.
|
|
To avoid bo memory manager being inited twice, it will be called
at firstopen when modeset is not enabled.
|
|
into modesetting-101
|
|
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.
|
|
|
|
moving modeset init code into one function and correct error
handling druing i915 init
|
|
We need to alloc a hw status page bo for G33 if modeset is enabled since the 2D
driver can't alloc gfx memory when working in drm modeset.
|
|
Fixup workqueue creation error handling and make sure we destroy the queue on
unload.
|
|
Map the VBIOS (and therefore VBT) at init time for use by various output
initialization routines.
|
|
Since it'll be freed at unload time, we should alloc devname rather than
pointing to the DRIVER_NAME string.
|
|
If the driver is 'modeset' enabled, it'll register it's interrupt
handler at load time. Set the devname in this case so that
/proc/interrupts makes sense.
|
|
|
|
if we are unloading the module, there is no master so therefore no lock
|
|
|
|
|
|
|
|
This change adds a driver feature that for i915 is controlled by a module
parameter. You now need to do insmod i915.ko modeset=1 to enable it the
modesetting paths.
It also fixes up lots of X paths. I can run my new DDX driver on this code
with and without modesetting enabled
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
linux-core/Makefile.kernel
linux-core/drm_bo.c
linux-core/drm_objects.h
|
|
|
|
We may want to make the old i915 memory manager obsolete eventually, and in the
meantime the takedown causes problems on unload so remove it for now.
|
|
Conflicts:
linux-core/drmP.h
linux-core/drm_bo.c
linux-core/drm_drv.c
linux-core/drm_objects.h
shared-core/drm.h
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
Mostly removing typedefs that snuck into the modesetting code and
updating to the latest TTM APIs. As of today, the i915 driver builds,
but there are likely to be problems, so debugging and bugfixes will
come next.
|
|
existing code.
This needs verifying.
|
|
|
|
modesetting-101
Conflicts:
linux-core/drm_drv.c
linux-core/drm_fops.c
linux-core/drm_objects.h
linux-core/drm_stub.c
shared-core/i915_dma.c
|
|
other drivers.
|
|
into origin/modesetting-101
Conflicts:
linux-core/drm_crtc.c
linux-core/drm_fb.c
Lots of changes to merge with alanh's latest stuff:
o fix use of fb->pitch now that it has the right value
o add new helper for finding the CRTC given an FB
o fix new fb_probe/fb_remove functions to take a CRTC
o fixup callers of new FB routines
o port drm_fb changes to intel_fb
o check for errors after creating fb buffer object
o go back to using cfb_imageblit since the accel stubs aren't ready
|
|
places).
Add new FB hooks to the drm driver structure and make i915 use them for an
Intel specific FB driver. This will allow acceleration and better handling
of the command stream.
|
|
|
|
I've commented out the framebuffer for now
|
|
into origin/modesetting-101
Conflicts:
shared-core/i915_init.c - reconcile with airlied's new code
|
