Allocating multiple pages of memory for data that is coming
from user space may fail. To fix memory allocation failures
the buffer object should be split to multiple independ pages.

drm buffer provides generic interface to copy and process
large data arrays from user space.

Interface includes allocation and free functions to allocate
the buffer object and data storage pages.

All access operations are performed relative to a internal
pointer which is advanced with drm_buffer_advance function.

The buffer can be accessed using drm_buffer_pointer_to_XXX
functions if it is known that requested object doesn't split
over a page boundary. These functions don't do any error
checking to maximize performance.

If there is large object which could be split there is special
drm_buffer_read_object function. drm_buffer_read_object takes
a pointer as argument which is used as temporary store for
data if it is split over boundary in the buffer.

Signed-off-by: Pauli Nieminen <suokkos@gmail.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>

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>

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>

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>

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>

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>

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>

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>