linux-toradex.git/drivers/gpu/drm/Makefile, branch v2.6.33.1 Linux kernel for Apalis and Colibri modules Merge branch 'drm-vmware-staging' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 2009-12-16T21:19:31+00:00 Linus Torvalds torvalds@linux-foundation.org 2009-12-16T21:19:31+00:00 5fa3577b1a1202972e6e419040438c29f39f59cc * 'drm-vmware-staging' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: drm/vmwgfx: Add DRM driver for VMware Virtual GPU drm/vmwgfx: Add svga headers for vmwgfx driver drm/ttm: Add more driver type enums 
* 'drm-vmware-staging' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
  drm/vmwgfx: Add DRM driver for VMware Virtual GPU
  drm/vmwgfx: Add svga headers for vmwgfx driver
  drm/ttm: Add more driver type enums
drm/vmwgfx: Add DRM driver for VMware Virtual GPU 2009-12-14T22:38:43+00:00 Jakob Bornecrantz jakob@vmware.com 2009-12-10T00:19:58+00:00 fb1d9738ca053ea8afa5e86af6463155f983b01c This commit adds the vmwgfx driver for the VWware Virtual GPU aka SVGA. The driver is under staging the same as Nouveau and Radeon KMS. Hopefully the 2D ioctls are bug free and don't need changing, so that part of the API should be stable. But there there is a pretty big chance that the 3D API will change in the future. Signed-off-by: Thomas Hellström <thellstrom@vmware.com> Signed-off-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com> 
This commit adds the vmwgfx driver for the VWware Virtual GPU aka SVGA.
The driver is under staging the same as Nouveau and Radeon KMS. Hopefully
the 2D ioctls are bug free and don't need changing, so that part of the
API should be stable. But there there is a pretty big chance that the 3D API
will change in the future.

Signed-off-by: Thomas Hellström <thellstrom@vmware.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/nouveau: Add DRM driver for NVIDIA GPUs 2009-12-11T11:29:34+00:00 Ben Skeggs bskeggs@redhat.com 2009-12-11T09:24:15+00:00 6ee738610f41b59733f63718f0bdbcba7d3a3f12 This adds a drm/kms staging non-API stable driver for GPUs from NVIDIA. This driver is a KMS-based driver and requires a compatible nouveau userspace libdrm and nouveau X.org driver. This driver requires firmware files not available in this kernel tree, interested parties can find them via the nouveau project git archive. This driver is reverse engineered, and is in no way supported by nVidia. Support for nearly the complete range of nvidia hw from nv04->g80 (nv50) is available, and the kms driver should support driving nearly all output types (displayport is under development still) along with supporting suspend/resume. This work is all from the upstream nouveau project found at nouveau.freedesktop.org. The original authors list from nouveau git tree is: Anssi Hannula <anssi.hannula@iki.fi> Ben Skeggs <bskeggs@redhat.com> Francisco Jerez <currojerez@riseup.net> Maarten Maathuis <madman2003@gmail.com> Marcin Kościelnicki <koriakin@0x04.net> Matthew Garrett <mjg@redhat.com> Matt Parnell <mparnell@gmail.com> Patrice Mandin <patmandin@gmail.com> Pekka Paalanen <pq@iki.fi> Xavier Chantry <shiningxc@gmail.com> along with project founder Stephane Marchesin <marchesin@icps.u-strasbg.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> 
This adds a drm/kms staging non-API stable driver for GPUs from NVIDIA.

This driver is a KMS-based driver and requires a compatible nouveau
userspace libdrm and nouveau X.org driver.

This driver requires firmware files not available in this kernel tree,
interested parties can find them via the nouveau project git archive.

This driver is reverse engineered, and is in no way supported by nVidia.

Support for nearly the complete range of nvidia hw from nv04->g80 (nv50)
is available, and the kms driver should support driving nearly all
output types (displayport is under development still) along with supporting
suspend/resume.

This work is all from the upstream nouveau project found at
nouveau.freedesktop.org.

The original authors list from nouveau git tree is:
Anssi Hannula <anssi.hannula@iki.fi>
Ben Skeggs <bskeggs@redhat.com>
Francisco Jerez <currojerez@riseup.net>
Maarten Maathuis <madman2003@gmail.com>
Marcin Kościelnicki <koriakin@0x04.net>
Matthew Garrett <mjg@redhat.com>
Matt Parnell <mparnell@gmail.com>
Patrice Mandin <patmandin@gmail.com>
Pekka Paalanen <pq@iki.fi>
Xavier Chantry <shiningxc@gmail.com>
along with project founder Stephane Marchesin <marchesin@icps.u-strasbg.fr>

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/intel: refactor DP i2c support and DP common header to drm helper 2009-12-07T23:24:23+00:00 Dave Airlie airlied@redhat.com 2009-12-04T00:55:24+00:00 ab2c0672984f7f7ebec6d5f615fd5a6ebad26f3d Both radeon and nouveau can re-use this code so move it up a level so they can. However the hw interfaces for aux ch are different enough that the code to translate from mode, address, bytes to actual hw interfaces isn't generic, so move that code into the Intel driver. Signed-off-by: Dave Airlie <airlied@redhat.com> 
Both radeon and nouveau can re-use this code so move it up a level
so they can. However the hw interfaces for aux ch are different
enough that the code to translate from mode, address, bytes
to actual hw interfaces isn't generic, so move that code into the
Intel driver.

Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/kms: fix kms helper license + Kconfig 2009-09-08T01:15:58+00:00 Dave Airlie airlied@redhat.com 2009-09-08T01:08:32+00:00 6fcefd56f5060ca99ab03c9f2ad1f17c3a543ca1 Allow the KMS module to work properly, and also rename it to KMS_HELPER so its clearer what its for. Signed-off-by: Dave Airlie <airlied@redhat.com> 
Allow the KMS module to work properly, and also rename
it to KMS_HELPER so its clearer what its for.

Signed-off-by: Dave Airlie <airlied@redhat.com>
drm: split crtc/fb helpers into a separate module 2009-09-07T05:45:33+00:00 Dave Airlie airlied@redhat.com 2009-09-07T05:45:33+00:00 13a8195b148615b15a4f4385f695f2a232095414 I really don't want to have core drm module rely on CONFIG_FB, so this is the easiest answer. Signed-off-by: Dave Airlie <airlied@redhat.com> 
I really don't want to have core drm module rely on CONFIG_FB,
so this is the easiest answer.

Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/kms: move driver specific fb common code to helper functions (v2) 2009-08-30T23:09:31+00:00 Dave Airlie airlied@redhat.com 2009-08-28T05:46:53+00:00 785b93ef8c309730c2de84ce9c229e40e2d01480 Initially I always meant this code to be shared, but things ran away from me before I got to it. This refactors the i915 and radeon kms fbdev interaction layers out into generic helpers + driver specific pieces. It moves all the panic/sysrq enhancements to the core file, and stores a linked list of kernel fbs. This could possibly be improved to only store the fb which has fbcon on it for panics etc. radeon retains some specific codes used for a big endian workaround. changes: fix oops in v1 fix freeing path for crtc_info Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com> 
Initially I always meant this code to be shared, but things
ran away from me before I got to it.

This refactors the i915 and radeon kms fbdev interaction layers
out into generic helpers + driver specific pieces.

It moves all the panic/sysrq enhancements to the core file,
and stores a linked list of kernel fbs. This could possibly be
improved to only store the fb which has fbcon on it for panics
etc.

radeon retains some specific codes used for a big endian
workaround.

changes:
fix oops in v1
fix freeing path for crtc_info

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/kms: slave encoder interface. 2009-08-04T04:10:51+00:00 Francisco Jerez currojerez@riseup.net 2009-08-02T02:19:17+00:00 2066facca4c7dfe9f5068ece0200a4dbf10f49e1 Define some helper functions to make easier to detach a KMS encoder implementation from the drm module of the GPU it's used in. This is mainly useful for some external I2C encoders known to be present on cards with GPUs from several different manufacturers. Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Dave Airlie <airlied@redhat.com> 
Define some helper functions to make easier to detach a KMS encoder
implementation from the drm module of the GPU it's used in. This is
mainly useful for some external I2C encoders known to be present on
cards with GPUs from several different manufacturers.

Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/radeon: fix driver initialization order so radeon kms can be builtin 2009-06-24T06:11:06+00:00 Jerome Glisse jglisse@redhat.com 2009-06-22T16:16:13+00:00 176f613e60b63f2d77e6c69f036cfc754f3aaac6 TTM need to be initialized before radeon if KMS is enabled otherwise the kernel will crash hard. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@linux.ie> 
TTM need to be initialized before radeon if KMS is enabled otherwise
the kernel will crash hard.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
drm: Add the TTM GPU memory manager subsystem. 2009-06-14T23:37:57+00:00 Thomas Hellstrom thellstrom@vmware.com 2009-06-10T13:20:19+00:00 ba4e7d973dd09b66912ac4c0856add8b0703a997 TTM is a GPU memory manager subsystem designed for use with GPU devices with various memory types (On-card VRAM, AGP, PCI apertures etc.). It's essentially a helper library that assists the DRM driver in creating and managing persistent buffer objects. TTM manages placement of data and CPU map setup and teardown on data movement. It can also optionally manage synchronization of data on a per-buffer-object level. TTM takes care to provide an always valid virtual user-space address to a buffer object which makes user-space sub-allocation of big buffer objects feasible. TTM uses a fine-grained per buffer-object locking scheme, taking care to release all relevant locks when waiting for the GPU. Although this implies some locking overhead, it's probably a big win for devices with multiple command submission mechanisms, since the lock contention will be minimal. TTM can be used with whatever user-space interface the driver chooses, including GEM. It's used by the upcoming Radeon KMS DRM driver and is also the GPU memory management core of various new experimental DRM drivers. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> 
TTM is a GPU memory manager subsystem designed for use with GPU
devices with various memory types (On-card VRAM, AGP,
PCI apertures etc.). It's essentially a helper library that assists
the DRM driver in creating and managing persistent buffer objects.

TTM manages placement of data and CPU map setup and teardown on
data movement. It can also optionally manage synchronization of
data on a per-buffer-object level.

TTM takes care to provide an always valid virtual user-space address
to a buffer object which makes user-space sub-allocation of
big buffer objects feasible.

TTM uses a fine-grained per buffer-object locking scheme, taking
care to release all relevant locks when waiting for the GPU.
Although this implies some locking overhead, it's probably a big
win for devices with multiple command submission mechanisms, since
the lock contention will be minimal.

TTM can be used with whatever user-space interface the driver
chooses, including GEM. It's used by the upcoming Radeon KMS DRM driver
and is also the GPU memory management core of various new experimental
DRM drivers.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>