Conflicts:
linux-core/Makefile.kernel
linux-core/drm_stub.c
linux-core/i915_drv.c
shared-core/i915_dma.c
shared-core/i915_drv.h
Fixup suspend/resume conflicts (basically use what's in DRM master for now).
Also fix up a few other conflicts that snuck in (i915_dma changes etc.).
Make DRM devices use real Linux devices instead of class devices, which are
going away. While we're at it, clean up some of the interfaces to take
struct drm_device * or struct device * and use the global drm_class where
needed instead of passing it around.
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.
When the kernel driver is loaded it sets up a lot of stuff..
it tears down the same stuff on unload.
This add a new map type called DRM_DRIVER which means the driver will clean the mapping up
and fix up the map cleaner
Add refcounting of user waiters to the DRM hardware lock, so that we can use the
DRM_LOCK_CONT flag more conservatively.
Also add a kernel waiter refcount that if nonzero transfers the lock for the kernel context,
when it is released. This is useful when waiting for idle and can be used
for very simple fence object driver implementations for the new memory manager.
It also resolves the AIGLX startup deadlock for the sis and the via drivers.
i810, i830 still require that the hardware lock is really taken so the deadlock remains
for those two. I'm not sure about ffb. Anyone familiar with that code?
Initialize the spinlock unconditionally when struct drm_device is filled in,
and return early in drm_locked_tasklet() if the driver doesn't support IRQs.
Actually make the existing ioctls for adding and removing drawables do
something useful, and add another ioctl for the X server to update drawable
information. The only kind of drawable information tracked so far is cliprects.
(cherry picked from 29598e5253 commit)
Actually make the existing ioctls for adding and removing drawables do
something useful, and add another ioctl for the X server to update drawable
information. The only kind of drawable information tracked so far is cliprects.
Dave Airlie
Dave Airlie
Jerome Glisse
Thomas Hellstrom
Jesse Barnes
Jesse Barnes
Kristian Høgsberg
Alan Hourihane
David Airlie
Jesse Barnes
Michel Dänzer
Eric Anholt