linux.git/drivers/gpu/drm/Kconfig, branch v2.6.32

drm/i915: Select CONFIG_SHMEM

2009-11-25T20:27:42+00:00

The driver requires shmfs as the backing filesystem to handle the buffer
objects, so ensure it is selected if the user chooses to build our
driver.

Fixes: Bug 14662 - Dell E5500 kernel panic with KMS
http://bugzilla.kernel.org/show_bug.cgi?id=14662

The revealing nature of the panic is the NULL function pointer
dereference in read_cache_page_async().

Signed-off-by: Chris Wilson 
Reported-and-tested-by: Mateusz Kaduk 
Signed-off-by: Eric Anholt 
Cc: stable@kernel.org

drm/i915: force mode set at lid open time

2009-09-10T23:10:00+00:00

Some laptop platforms will disable pipes and/or planes at lid close time
and not restore them when the lid is opened again.  So catch the lid
event, and if the lid was opened, force a mode restore.

Fixes fdo bug #21230.

Acked-by: Matthew Garrett 
Signed-off-by: Jesse Barnes 
Signed-off-by: Eric Anholt

drm/kms/radeon: make kms default a runtime option

2009-09-08T01:15:59+00:00

This makes the kms/enable disable a runtime not a build time
option.

Signed-off-by: Dave Airlie

drm/kms: fix kms helper license + Kconfig

2009-09-08T01:15:58+00:00

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

drm: split crtc/fb helpers into a separate module

2009-09-07T05:45:33+00:00

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

radeon: Use request_firmware()

2009-08-30T23:09:30+00:00

Loosely based on a patch by
Jaswinder Singh Rajput .

KMS support by Dave Airlie .

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: Ben Hutchings 
Signed-off-by: Dave Airlie

drm/r128: Use request_firmware() to load CCE microcode

2009-08-27T00:47:00+00:00

Firmware blob looks like this:
    __be32 datah
    __be32 datal

Signed-off-by: Ben Hutchings 
Signed-off-by: Dave Airlie

drm/mga: Use request_firmware() to load microcode

2009-08-27T00:46:54+00:00

Image format is IHEX, one record for each pipe in order (record
addresses are ignored).

Signed-off-by: Ben Hutchings 
Signed-off-by: Dave Airlie

drm/i915: Add missing dependency on Intel AGP support.

2009-06-22T05:13:38+00:00

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

drm/radeon: introduce kernel modesetting for radeon hardware

2009-06-15T02:01:53+00:00

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 
    Dave Airlie 
    Alex Deucher 

Signed-off-by: Jerome Glisse 
Signed-off-by: Dave Airlie 
Signed-off-by: Alex Deucher 
Signed-off-by: Dave Airlie