I really don't want to have core drm module rely on CONFIG_FB,
so this is the easiest answer.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Loosely based on a patch by
Jaswinder Singh Rajput <jaswinderlinux@gmail.com>.

KMS support by Dave Airlie <airlied@redhat.com>.

For Radeon 100- to 500-series, firmware blobs look like:
    struct {
        __be32 datah;
        __be32 datal;
    } cp_ucode[256];

For Radeon 600-series, there are two separate firmware blobs:
    __be32 me_ucode[PM4_UCODE_SIZE * 3];
    __be32 pfp_ucode[PFP_UCODE_SIZE];

For Radeon 700-series, likewise:
    __be32 me_ucode[R700_PM4_UCODE_SIZE];
    __be32 pfp_ucode[R700_PFP_UCODE_SIZE];
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Firmware blob looks like this:
    __be32 datah
    __be32 datal
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Image format is IHEX, one record for each pipe in order (record
addresses are ignored).
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Users could accidentally enable AGP but not the Intel AGP support, and get
a DRM that doesn't probe as a result.

Bug #22358.
Signed-off-by: NEric Anholt <eric@anholt.net>

Add kernel modesetting support to radeon driver, use the ttm memory
manager to manage memory and DRM/GEM to provide userspace API.
In order to avoid backward compatibility issue and to allow clean
design and code the radeon kernel modesetting use different code path
than old radeon/drm driver.

When kernel modesetting is enabled the IOCTL of radeon/drm
driver are considered as invalid and an error message is printed
in the log and they return failure.

KMS enabled userspace will use new API to talk with the radeon/drm
driver. The new API provide functions to create/destroy/share/mmap
buffer object which are then managed by the kernel memory manager
(here TTM). In order to submit command to the GPU the userspace
provide a buffer holding the command stream, along this buffer
userspace have to provide a list of buffer object used by the
command stream. The kernel radeon driver will then place buffer
in GPU accessible memory and will update command stream to reflect
the position of the different buffers.

The kernel will also perform security check on command stream
provided by the user, we want to catch and forbid any illegal use
of the GPU such as DMA into random system memory or into memory
not owned by the process supplying the command stream. This part
of the code is still incomplete and this why we propose that patch
as a staging driver addition, future security might forbid current
experimental userspace to run.

This code support the following hardware : R1XX,R2XX,R3XX,R4XX,R5XX
(radeon up to X1950). Works is underway to provide support for R6XX,
R7XX and newer hardware (radeon from HD2XXX to HD4XXX).

Authors:
    Jerome Glisse <jglisse@redhat.com>
    Dave Airlie <airlied@redhat.com>
    Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave 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: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

drivers/built-in.o: In function `intel_opregion_init':
(.text+0x9d540): undefined reference to `acpi_video_register'

v2: move under DRM_I915 from DRM_I915_KMS
Signed-off-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>

drivers/built-in.o: In function `intel_opregion_init':
(.text+0x9d540): undefined reference to `acpi_video_register'

http://bugzilla.kernel.org/show_bug.cgi?id=13165Signed-off-by: NLen Brown <len.brown@intel.com>

People keep getting bitten by this, so just auto-select it by default,
assuming most configurations will actually want a console.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Submenus of the graphics support "Support for frame buffer devices" and
"Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)" are
broken in half after latest changes for Intel 915 mode setting support.

The DRM subsection is broken because one option is put outside the choice
section it depends on.

The frame buffers part is broken then due to circular dependency.  Fix
this by make Intel frame buffers depend on CONFIG_INTEL_AGP.

Kconfigs are broken by d2f59357
("drm/i915: select framebuffer support automatically").

This is probably not only way to fix this.
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Migration helper.

The i915 driver recently added a 'depends on FB' rule to its
Kconfig entry - which silently turns off DRM_I915 if someone
has a working config but no CONFIG_FB selected, and upgrades
to the latest upstream kernel.

Norbert Preining reported this problem:

   Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=12599
   Subject     : dri /dev node disappeared with 2.6.29-rc1

So change it to "select FB", which auto-selects framebuffer
support. This way the driver keeps working, regardless of
whether FB was enabled before or not.

Kconfig select's of interactive options can be problematic to
dependencies and can cause build breakages - but in this case
it's safe because it's a leaf entry with no dependencies of its
own.

( There is some minor circular dependency fallout as FB_I810
  and FB_INTEL also used 'depends on FB' constructs - update
  those to "select FB" too. )
Reported-by: NNorbert Preining <preining@logic.at>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported.  HDMI, DisplayPort and additional SDVO output support will
follow.

Support for the mode setting code is controlled by the new 'modeset'
module option.  A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.

Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing.  So use caution when
enabling this code; be sure your user level code supports the new
interfaces.

A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.

Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We're trying to keep the !CONFIG_SHMEM tiny-shmem.c (using ramfs without
swap) in synch with CONFIG_SHMEM shmem.c (and mpm is preparing patches
to combine them).  I was glad to see EXPORT_SYMBOL_GPL(shmem_file_setup)
go into shmem.c, but why not support DRM-GEM when !CONFIG_SHMEM too?
But caution says still depend on MMU, since !CONFIG_MMU is.. different.
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Acked-by: NMatt Mackall <mpm@selenic.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This can be removed later when DRM doesn't depend on shmem.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Reported-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

With the coming of kernel based modesetting and the memory manager stuff,
the everything in one directory approach was getting very ugly and
starting to be unmanageable.

This restructures the drm along the lines of other kernel components.

It creates a drivers/gpu/drm directory and moves the hw drivers into
subdirectores. It moves the includes into an include/drm, and
sets up the unifdef for the userspace headers we should be exporting.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NDave Airlie <airlied@linux.ie>

Move AGP and DRM menus into the video graphics support menu.
  They use 'menuconfig' so that they can all be disabled with
  one selection.
Make the console menu use 'menuconfig' so that it can all be
  disabled with one selection.
Make the frame buffer menu use 'menuconfig' so that it can all be
  disabled with one selection.
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Acked-by: NDave Airlie <airlied@linux.ie>
Signed-off-by: NAntonino Daplas <adaplas@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The DRM code depends on an atomic version of cmpxchg(), which is not
available on sparc32. Since other platforms besides sparc32 have this
issue a KCONFIG option is added for it.
Signed-off-by: NMartin Habets <errandir_news@mph.eclipse.co.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDave Airlie <airlied@linux.ie>

This patch removes a dead Radeon URL from two Kconfig files.

This isue was noted by Reto Gantenbein <ganto82@gmx.ch> in
Kernel Bugzilla #4446.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

Add driver for savage chipsets.

From: Felix Kuehling
Signed-off-by: NDave Airlie <airlied@linux.ie>

The gamma driver has been broken for quite a while, it doesn't build,
we don't have a userspace, mine is in Ireland etc...
Signed-off-by: NDave Airlie <airlied@linux.ie>

This patch adds serveral new ioctls and a new query to get_param query to
support PCI MGA cards.

Two ioctls were added to implement interrupt based waiting.  With this change,
the client-side driver no longer needs to map the primary DMA region or the
MMIO region.  Previously, end-of-frame waiting was done by busy waiting in the
client-side driver until one of the MMIO registers (the current DMA pointer)
matched a pointer to the end of primary DMA space.  By using interrupts, the
busy waiting and the extra mappings are removed.

A third ioctl was added to bootstrap DMA.  This ioctl, which is used by the
X-server, moves a *LOT* of code from the X-server into the kernel.  This allows
the kernel to do whatever needs to be done to setup DMA buffers.  The entire
process and the locations of the buffers are hidden from user-mode.

Additionally, a get_param query was added to differentiate between G4x0 cards
and G550 cards.  A gap was left in the numbering sequence so that, if needed,
G450 cards could be distinguished from G400 cards.  According to Ville
Syrjälä, the G4x0 cards and the G550 cards handle anisotropic filtering
differently.  This seems the most compatible way to let the client-side driver
know which card it's own.  Doing this very small change now eliminates the
need to bump the DRM minor version twice.

http://marc.theaimsgroup.com/?l=dri-devel&m=106625815319773&w=2

(airlied - this may not work at this point, I think the follow on buffer
 cleanup patches will be needed)

From: Ian Romanick <idr@us.ibm.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Add DRM device driver for VIA Unichrome chipsets

From: Unichrome Project http://unichrome.sf.net, Erdi Chen, Thomas Hellstrom    Signed-off-by: Dave Airlie <airlied@linux.ie>

be fixed but at the moment it is true.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!