summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/Kconfig
Commit message (Collapse)AuthorAgeFilesLines
* drm/fbdev: rework output polling to be back in the core. (v4)Dave Airlie2010-05-181-1/+1
| | | | | | | | | | | | | | | | | After thinking it over a lot it made more sense for the core to deal with the output polling especially so it can notify X. v2: drop plans for fake connector - per Michel's comments - fix X patch sent to xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd settings. v3: add config lock take inside polling, add intel/nouveau poll init/fini calls v4: config lock was a bit agressive, only needed around connector list reading. otherwise it could re-enter. glisse: discard drm_helper_hpd_irq_event v3: Reviewed-by: Michel Dänzer <michel@daenzer.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/kms/fb: add polling support for when nothing is connected.Dave Airlie2010-04-071-0/+1
| | | | | | | | | | | | | When we are running in a headless environment we have no idea what output the user might plug in later, we only have hotplug detect from the digital outputs. So if we detect no connected outputs at initialisation, start a slow work operation to poll every 5 seconds for an output. this is only hooked up for radeon so far, on hw where we have full hotplug detection there is no need for this. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: move radeon KMS on/off switch out of staging.Dave Airlie2010-02-011-0/+2
| | | | | | | | We are happy enough that the KMS driver is stable enough for enough people for the kms enable/disable to leave staging. Distros can now contemplate turning this on. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/i915: Select CONFIG_SHMEMChris Wilson2009-11-251-0/+1
| | | | | | | | | | | | | | | | | 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 <chris@chris-wilson.co.uk> Reported-and-tested-by: Mateusz Kaduk <mateusz.kaduk@gmail.com> Signed-off-by: Eric Anholt <eric@anholt.net> Cc: stable@kernel.org
* drm/i915: force mode set at lid open timeJesse Barnes2009-09-101-0/+1
| | | | | | | | | | | | 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 <mjg@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/kms/radeon: make kms default a runtime optionDave Airlie2009-09-081-1/+2
| | | | | | | This makes the kms/enable disable a runtime not a build time option. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/kms: fix kms helper license + KconfigDave Airlie2009-09-081-4/+4
| | | | | | | 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 moduleDave Airlie2009-09-071-2/+8
| | | | | | | 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>
* radeon: Use request_firmware()Ben Hutchings2009-08-311-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/r128: Use request_firmware() to load CCE microcodeBen Hutchings2009-08-271-0/+1
| | | | | | | | | Firmware blob looks like this: __be32 datah __be32 datal Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/mga: Use request_firmware() to load microcodeBen Hutchings2009-08-271-0/+1
| | | | | | | | Image format is IHEX, one record for each pipe in order (record addresses are ignored). Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/i915: Add missing dependency on Intel AGP support.Eric Anholt2009-06-211-0/+1
| | | | | | | | | 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>
* drm/radeon: introduce kernel modesetting for radeon hardwareJerome Glisse2009-06-151-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* drm: Add the TTM GPU memory manager subsystem.Thomas Hellstrom2009-06-151-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ACPI, i915: build fix (v2)Len Brown2009-05-291-7/+7
| | | | | | | | | | 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>
*-. Merge branches 'release', 'bugzilla-13032', 'bugzilla-13041+', ↵Len Brown2009-05-161-0/+6
|\ \ | | | | | | | | | 'bugzilla-13121', 'bugzilla-13165', 'bugzilla-13243', 'bugzilla-13259', 'resume-sci-en-regression', 'thermal-regression', 'tsc-regression' and 'asus-2.6.30' into release
| | * ACPI, i915: build fixLen Brown2009-05-151-0/+6
| |/ | | | | | | | | | | | | | | | | 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>
* | drm/i915: automatically select FRAMEBUFFER_CONSOLE if !EMBEDDEDJesse Barnes2009-05-121-0/+1
|/ | | | | | | 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>
* fbdev/drm: fix Kconfig submenu mess in "Graphics support"Krzysztof Helt2009-02-181-7/+6
| | | | | | | | | | | | | | | | | | | | | | | 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>
* drm/i915: select framebuffer support automaticallyIngo Molnar2009-02-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* drm: kconfig have drm core select i2c for kmsDave Airlie2008-12-291-1/+2
| | | | Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/i915: Register module dependencies for the modesetting code.Eric Anholt2008-12-291-0/+5
| | | | | Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
* DRM: i915: add mode setting supportJesse Barnes2008-12-291-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Export tiny shmem_file_setup for DRM-GEMHugh Dickins2008-10-201-1/+1
| | | | | | | | | | | | | 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: Hugh Dickins <hugh@veritas.com> Acked-by: Matt Mackall <mpm@selenic.com> Acked-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* drm: make CONFIG_DRM depend on CONFIG_SHMEM.Dave Airlie2008-10-181-1/+1
| | | | | | This can be removed later when DRM doesn't depend on shmem. Signed-off-by: Dave Airlie <airlied@redhat.com>
* FB_SIS=m, DRM_SIS=y is not a legal configuration.Adrian Bunk2008-10-181-0/+1
| | | | | | Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: reorganise drm tree to be more future proof.Dave Airlie2008-07-141-0/+107
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: Dave Airlie <airlied@redhat.com>
View Lorry Controller Status