[resubmit] Add GEM to i915 DRM driver

[Eric Anholt]

This patch series brings a long-awaited kernel memory manager to the i915
driver.  This will allow us to do correct composited OpenGL, speed up
OpenGL-based compositing, and enable framebuffer objects and other "new"
OpenGL extensions.  This patchset is also being built to enable kernel
modesetting for a non-root, flicker-free X Server.

This is a re-submit of the changes for DRM-GEM.  It relies on patches submitted
by airlied which are currently queued in linux-next.  The tree still has all
the changes required, based off of 2.6.27-rc4.

git://people.freedesktop.org/~anholt/linux-2.6 on the drm-gem-merge branch
http://cgit.freedesktop.org/~anholt/linux-2.6/log/?h=drm-gem-merge

New in this edition since the original submission:

- Exporting kmap_atomic_pfn.
  (The previous submission was slow because it was checking for the
  drm_compat.c version of this function from the external tree)
- shmem_getpage usage replaced with read_mapping_page.
- fixes for software fallbacks on tiled buffers.
- speedups for software fallbacks.
- replaced pci_read_base usage with using the MCHBAR mirror aperture
- fixed some issues on X server exit

What's not new in this edition:

Still using shmem_file_setup.  We need to be able to allocate objects from
the kernel, and didn't get any clear agreement that doing a VFS dance would be
preferable to letting us behave like other kernel subsystems and use the
function.

Still using small integers to identify our objects rather than fds.
We need more than just basic syscalls on the objects -- the alternate mmap
issue is more serious than before, for X pixmap usage.  There are also the
ioctls for cache management for software fallbacks.  And the issue of
getting high fds and large numbers of them still remained.

Still have an issue with PAT on x86_64 -- initialization fails because
ioremap() apparently has different semantics there than on x86 or non-PAT
x86_64 (if somebody has mapped the space and there's a WC MTRR, the ioremap
that defaults to UC- ends up conflicting on it and failing even though it
seems like it's not supposed to).


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/