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: Eric 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: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.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>

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: Len Brown <len.brown@intel.com>
Signed-off-by: Randy 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=13165

Signed-off-by: Len 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: Jesse 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 d2f59357700487a8b944f4f7777d1e97cf5ea2ed
("drm/i915: select framebuffer support automatically").

This is probably not only way to fix this.

Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus 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: Norbert Preining <preining@logic.at>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Dave Airlie <airlied@linux.ie>

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