UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/drivers/gpu/drm/Kconfig

194 lines
5.3 KiB
Plaintext
Raw Normal View History

Linux-2.6.12-rc2 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!
2005-04-17 06:20:36 +08:00
#
# Drm device configuration
#
# This driver provides support for the
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
#
video gfx: merge kconfig menus 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: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Dave Airlie <airlied@linux.ie> Signed-off-by: Antonino Daplas <adaplas@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-16 16:29:39 +08:00
menuconfig DRM
Linux-2.6.12-rc2 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!
2005-04-17 06:20:36 +08:00
tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)"
drm: DRM should depend on HAS_DMA If NO_DMA=y: drivers/built-in.o: In function `__drm_pci_free': drivers/gpu/drm/drm_pci.c:112: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `drm_pci_alloc': drivers/gpu/drm/drm_pci.c:72: undefined reference to `dma_alloc_coherent' drivers/built-in.o: In function `drm_gem_unmap_dma_buf': drivers/gpu/drm/drm_prime.c:87: undefined reference to `dma_unmap_sg' drivers/built-in.o: In function `drm_gem_map_dma_buf': drivers/gpu/drm/drm_prime.c:78: undefined reference to `dma_map_sg' Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-18 18:54:25 +08:00
depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU && HAS_DMA
drm: Add HDMI infoframe helpers Add a generic helper to fill in an HDMI AVI infoframe with data extracted from a DRM display mode. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-11-21 22:31:35 +08:00
select HDMI
drm: kconfig have drm core select i2c for kms Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-12-13 16:21:08 +08:00
select I2C
select I2C_ALGOBIT
drm: base prime/dma-buf support (v5) This adds the basic drm dma-buf interface layer, called PRIME. This commit doesn't add any driver support, it is simply and agreed upon starting point so we can work towards merging driver support for the next merge window. Current drivers with work done are nouveau, i915, udl, exynos and omap. The main APIs exposed to userspace allow translating a 32-bit object handle to a file descriptor, and a file descriptor to a 32-bit object handle. The flags value is currently limited to O_CLOEXEC. Acknowledgements: Daniel Vetter: lots of review Rob Clark: cleaned up lots of the internals and did lifetime review. v2: rename some functions after Chris preferred a green shed fix IS_ERR_OR_NULL -> IS_ERR v3: Fix Ville pointed out using buffer + kmalloc v4: add locking as per ickle review v5: allow re-exporting the original dma-buf (Daniel) Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Rob Clark <rob.clark@linaro.org> Reviewed-by: Sumit Semwal <sumit.semwal@linaro.org> Reviewed-by: Inki Dae <inki.dae@samsung.com> Acked-by: Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-11-25 23:21:02 +08:00
select DMA_SHARED_BUFFER
Linux-2.6.12-rc2 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!
2005-04-17 06:20:36 +08:00
help
Kernel-level support for the Direct Rendering Infrastructure (DRI)
introduced in XFree86 4.0. If you say Y here, you need to select
the module that's right for your graphics card from the list below.
These modules provide support for synchronization, security, and
DMA transfers. Please see <http://dri.sourceforge.net/> for more
details. You should also select and configure AGP
drm: Add support for platform devices to register as DRM devices Allow platform devices without PCI resources to be DRM devices. [airlied: fixup warnings with dev pointers] Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-05-28 03:40:25 +08:00
(/dev/agpgart) support if it is available for your platform.
Linux-2.6.12-rc2 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!
2005-04-17 06:20:36 +08:00
drm/usb: move usb support into a separate module In order to satisfy all the various Kconfig options between USB and DRM, we need to split the USB code out into a separate module and export symbols to it. This fixes build problems in -next reported by sfr. Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-03-20 14:59:29 +08:00
config DRM_USB
tristate
depends on DRM
drm: udl: usb: Fix recursive Kconfig dependency In drivers/usb/Kconfig "config USB_ARCH_HAS_HCD" is within "if USB_SUPPORT" statement. In drivers/gpu/drm/Kconfig "config DRM_USB" depends on USB_ARCH_HAS_HCD but selects USB_SUPPORT which leads to the error for udl Kconfig: $ yes "" | make oldconfig scripts/kconfig/conf --oldconfig Kconfig drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected! drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL Fix this by changing from select to depends on USB_SUPPORT in "config DRM_USB". This is a follow-up fix to df0b344300724e00db9fff7eb6406eb91f450b91 in Dave's drm-next GIT branch. [ v2: Restore old status, but change from select to depends on USB_SUPPORT ] Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Dave Airlie <airlied@gmail.com>
2012-08-25 03:20:03 +08:00
depends on USB_SUPPORT && USB_ARCH_HAS_HCD
drm/usb: move usb support into a separate module In order to satisfy all the various Kconfig options between USB and DRM, we need to split the USB code out into a separate module and export symbols to it. This fixes build problems in -next reported by sfr. Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-03-20 14:59:29 +08:00
select USB
drm/kms: fix kms helper license + Kconfig 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>
2009-09-08 09:08:32 +08:00
config DRM_KMS_HELPER
drm: split crtc/fb helpers into a separate module 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>
2009-09-07 13:45:33 +08:00
tristate
depends on DRM
drm: Add separate Kconfig option for fbdev helpers For drivers which might want to disable fbdev legacy support. Select the new option in all drivers for now, so this shouldn't result in any change. Drivers need some work anyway to make fbdev support optional (if they have it implemented, that is), so the recommended way to expose this is by adding per-driver options. At least as long as most drivers don't support disabling the fbdev support. v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm driver can already take advantage of this, which allows us to build msm without any fbdev depencies in the kernel! v3: Move the MODULE_* stuff from the fbdev helper file to drm_crtc_helper.c. Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Acked-by: Dave Airlie <airlied@linux.ie> Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-08 23:44:47 +08:00
help
CRTC helpers for KMS drivers.
config DRM_KMS_FB_HELPER
bool
depends on DRM_KMS_HELPER
drm: split crtc/fb helpers into a separate module 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>
2009-09-07 13:45:33 +08:00
select FB
kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option is used to configure any non-standard kernel with a much larger scope than only small devices. This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes references to the option throughout the kernel. A new CONFIG_EMBEDDED option is added that automatically selects CONFIG_EXPERT when enabled and can be used in the future to isolate options that should only be considered for embedded systems (RISC architectures, SLOB, etc). Calling the option "EXPERT" more accurately represents its intention: only expert users who understand the impact of the configuration changes they are making should enable it. Reviewed-by: Ingo Molnar <mingo@elte.hu> Acked-by: David Woodhouse <david.woodhouse@intel.com> Signed-off-by: David Rientjes <rientjes@google.com> Cc: Greg KH <gregkh@suse.de> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jens Axboe <axboe@kernel.dk> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Robin Holt <holt@sgi.com> Cc: <linux-arch@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-01-21 06:44:16 +08:00
select FRAMEBUFFER_CONSOLE if !EXPERT
drm: select FRAMEBUFFER_CONSOLE_PRIMARY if we have FRAMEBUFFER_CONSOLE Multi-gpu/switcheroo relies on this option to get the console on the correct GPU at bootup, some distros enable it but it seems some get it wrong. cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-04-22 05:51:33 +08:00
select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
drm: split crtc/fb helpers into a separate module 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>
2009-09-07 13:45:33 +08:00
help
drm: Add separate Kconfig option for fbdev helpers For drivers which might want to disable fbdev legacy support. Select the new option in all drivers for now, so this shouldn't result in any change. Drivers need some work anyway to make fbdev support optional (if they have it implemented, that is), so the recommended way to expose this is by adding per-driver options. At least as long as most drivers don't support disabling the fbdev support. v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm driver can already take advantage of this, which allows us to build msm without any fbdev depencies in the kernel! v3: Move the MODULE_* stuff from the fbdev helper file to drm_crtc_helper.c. Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Acked-by: Dave Airlie <airlied@linux.ie> Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-08 23:44:47 +08:00
FBDEV helpers for KMS drivers.
drm: split crtc/fb helpers into a separate module 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>
2009-09-07 13:45:33 +08:00
drm: allow loading an EDID as firmware to override broken monitor Broken monitors and/or broken graphic boards may send erroneous or no EDID data. This also applies to broken KVM devices that are unable to correctly forward the EDID data of the connected monitor but invent their own fantasy data. This patch allows to specify an EDID data set to be used instead of probing the monitor for it. It contains built-in data sets of frequently used screen resolutions. In addition, a particular EDID data set may be provided in the /lib/firmware directory and loaded via the firmware interface. The name is passed to the kernel as module parameter of the drm_kms_helper module either when loaded options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel commandline parameter drm_kms_helper.edid_firmware=edid/1280x1024.bin It is also possible to restrict the usage of a specified EDID data set to a particular connector. This is done by prepending the name of the connector to the name of the EDID data set using the syntax edid_firmware=[<connector>:]<edid> such as, for example, edid_firmware=DVI-I-1:edid/1920x1080.bin in which case no other connector will be affected. The built-in data sets are Resolution Name -------------------------------- 1024x768 edid/1024x768.bin 1280x1024 edid/1280x1024.bin 1680x1050 edid/1680x1050.bin 1920x1080 edid/1920x1080.bin They are ignored, if a file with the same name is available in the /lib/firmware directory. The built-in EDID data sets are based on standard timings that may not apply to a particular monitor and even crash it. Ideally, EDID data of the connected monitor should be used. They may be obtained through the drm/cardX/cardX-<connector>/edid entry in the /sys/devices PCI directory of a correctly working graphics adapter. It is even possible to specify the name of an EDID data set on-the-fly via the /sys/module interface, e.g. echo edid/myedid.bin >/sys/module/drm_kms_helper/parameters/edid_firmware The new screen mode is considered when the related kernel function is called for the first time after the change. Such calls are made when the X server is started or when the display settings dialog is opened in an already running X server. Signed-off-by: Carsten Emde <C.Emde@osadl.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-03-19 05:37:33 +08:00
config DRM_LOAD_EDID_FIRMWARE
bool "Allow to specify an EDID data set instead of probing for it"
depends on DRM_KMS_HELPER
help
Say Y here, if you want to use EDID data to be loaded from the
/lib/firmware directory or one of the provided built-in
data sets. This may be necessary, if the graphics adapter or
monitor are unable to provide appropriate EDID data. Since this
feature is provided as a workaround for broken hardware, the
default case is N. Details and instructions how to build your own
EDID data are given in Documentation/EDID/HOWTO.txt.
drm: Add the TTM GPU memory manager subsystem. 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>
2009-06-10 21:20:19 +08:00
config DRM_TTM
drm/radeon: introduce kernel modesetting for radeon hardware 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>
2009-06-05 20:42:42 +08:00
tristate
drm: Add the TTM GPU memory manager subsystem. 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>
2009-06-10 21:20:19 +08:00
depends on DRM
help
GPU memory management subsystem for devices with multiple
GPU memory types. Will be enabled automatically if a device driver
uses it.
DRM: Add DRM GEM CMA helper Many embedded drm devices do not have a IOMMU and no dedicated memory for graphics. These devices use CMA (Contiguous Memory Allocator) backed graphics memory. This patch provides helper functions to be able to share the code. The code technically does not depend on CMA as the backend allocator, the name has been chosen because CMA makes for a nice, short but still descriptive function prefix. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Lars-Peter Clausen <lars@metafoo.de> [Make DRM_GEM_CMA_HELPER a boolean Kconfig option] Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2012-06-27 21:30:18 +08:00
config DRM_GEM_CMA_HELPER
bool
depends on DRM
help
Choose this if you need the GEM CMA helper functions
DRM: Add DRM KMS/FB CMA helper This patchset introduces a set of helper function for implementing the KMS framebuffer layer for drivers which use the DRM GEM CMA helper function. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> [Make DRM_KMS_CMA_HELPER a boolean Kconfig option] Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2012-07-02 22:37:47 +08:00
config DRM_KMS_CMA_HELPER
bool
select DRM_GEM_CMA_HELPER
drm: Add separate Kconfig option for fbdev helpers For drivers which might want to disable fbdev legacy support. Select the new option in all drivers for now, so this shouldn't result in any change. Drivers need some work anyway to make fbdev support optional (if they have it implemented, that is), so the recommended way to expose this is by adding per-driver options. At least as long as most drivers don't support disabling the fbdev support. v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm driver can already take advantage of this, which allows us to build msm without any fbdev depencies in the kernel! v3: Move the MODULE_* stuff from the fbdev helper file to drm_crtc_helper.c. Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Acked-by: Dave Airlie <airlied@linux.ie> Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-08 23:44:47 +08:00
select DRM_KMS_FB_HELPER
DRM: Add DRM KMS/FB CMA helper This patchset introduces a set of helper function for implementing the KMS framebuffer layer for drivers which use the DRM GEM CMA helper function. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> [Make DRM_KMS_CMA_HELPER a boolean Kconfig option] Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2012-07-02 22:37:47 +08:00
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
help
Choose this if you need the KMS CMA helper functions
drm/i2c: give i2c it's own Kconfig Move this out of nouveau directory. As we start to add more encoder slaves used by other drivers, it makes sense to put the Kconfig bits in one place. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-01-25 05:46:07 +08:00
source "drivers/gpu/drm/i2c/Kconfig"
Linux-2.6.12-rc2 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!
2005-04-17 06:20:36 +08:00
config DRM_TDFX
tristate "3dfx Banshee/Voodoo3+"
depends on DRM && PCI
help
Choose this option if you have a 3dfx Banshee or Voodoo3 (or later),
graphics card. If M is selected, the module will be called tdfx.
config DRM_R128
tristate "ATI Rage 128"
depends on DRM && PCI
drm/r128: Use request_firmware() to load CCE microcode 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>
2009-08-24 01:37:26 +08:00
select FW_LOADER
Linux-2.6.12-rc2 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!
2005-04-17 06:20:36 +08:00
help
Choose this option if you have an ATI Rage 128 graphics card. If M
is selected, the module will be called r128. AGP support for
this card is strongly suggested (unless you have a PCI version).
config DRM_RADEON
tristate "ATI Radeon"
depends on DRM && PCI
drm/radeon: introduce kernel modesetting for radeon hardware 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>
2009-06-05 20:42:42 +08:00
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
radeon: Use request_firmware() 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>
2009-08-29 21:53:51 +08:00
select FW_LOADER
drm/kms/radeon: make kms default a runtime option This makes the kms/enable disable a runtime not a build time option. Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-09-08 09:09:50 +08:00
select DRM_KMS_HELPER
drm: Add separate Kconfig option for fbdev helpers For drivers which might want to disable fbdev legacy support. Select the new option in all drivers for now, so this shouldn't result in any change. Drivers need some work anyway to make fbdev support optional (if they have it implemented, that is), so the recommended way to expose this is by adding per-driver options. At least as long as most drivers don't support disabling the fbdev support. v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm driver can already take advantage of this, which allows us to build msm without any fbdev depencies in the kernel! v3: Move the MODULE_* stuff from the fbdev helper file to drm_crtc_helper.c. Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Acked-by: Dave Airlie <airlied@linux.ie> Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-08 23:44:47 +08:00
select DRM_KMS_FB_HELPER
drm/kms/radeon: make kms default a runtime option This makes the kms/enable disable a runtime not a build time option. Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-09-08 09:09:50 +08:00
select DRM_TTM
drm/radeon: fix power supply kconfig interaction. radeon needs power supply to get correct PM info so select it at the radeon level not at the kms option. Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-05-21 13:41:20 +08:00
select POWER_SUPPLY
drm/radeon/kms: add support for internal thermal sensors (v3) rv6xx/rv7xx/evergreen families supported; older asics did not have an internal thermal sensor. Note, not all oems use the internal thermal sensor, so it's only exposed in cases where it is used. Note also, that most laptops use an oem specific ACPI solution for GPU thermal information rather than using the internal thermal sensor directly. v2: export millidegrees celsius, use hwmon device properly. v3: fix Kconfig Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-07-03 00:58:16 +08:00
select HWMON
drm/radeon: Deprecate UMS support v2 KMS support is out and stable for a couple of years now and the userspace code has deprecated or abandoned the old UMS interface. So make the KMS interface the default and deprecate the UMS interface in the kernel as well. v2: rebased on alex/drm-next-3.9-wip Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-21 20:58:46 +08:00
select BACKLIGHT_CLASS_DEVICE
Linux-2.6.12-rc2 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!
2005-04-17 06:20:36 +08:00
help
Choose this option if you have an ATI Radeon graphics card. There
are both PCI and AGP versions. You don't need to choose this to
remove dead Radeon URL 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: Adrian Bunk <bunk@stusta.de>
2006-03-21 03:23:13 +08:00
run the Radeon in plain VGA mode.
drm: run cleanfile across drm tree Signed-off-by: Dave Airlie <airlied@linux.ie>
2007-11-05 10:50:58 +08:00
Linux-2.6.12-rc2 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!
2005-04-17 06:20:36 +08:00
If M is selected, the module will be called radeon.
drm/radeon/kms: move radeon KMS on/off switch out of staging. 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>
2010-02-01 09:35:47 +08:00
source "drivers/gpu/drm/radeon/Kconfig"
drm/nouveau: move out of staging drivers There's really no good reason for us to be in here anymore, we have to maintain this ABI anyway to avoid angering people. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-03-16 16:19:14 +08:00
source "drivers/gpu/drm/nouveau/Kconfig"
Linux-2.6.12-rc2 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!
2005-04-17 06:20:36 +08:00
config DRM_I810
tristate "Intel I810"
drm/i810: remove the BKL SMP i810 systems were practically nonexistent and the configuration was not officially supported by Intel at the time when Pentium-III was common. With this change, it is still possible to build a distribution kernel that has support for SMP and includes the i810 driver without the BKL. As a precaution, check for the theoretical SMP case at run time and refuse to load the driver. We also need to disable CONFIG_PREEMPT builds for this driver. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-01-26 06:17:15 +08:00
# !PREEMPT because of missing ioctl locking
depends on DRM && AGP && AGP_INTEL && (!PREEMPT || BROKEN)
Linux-2.6.12-rc2 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!
2005-04-17 06:20:36 +08:00
help
Choose this option if you have an Intel I810 graphics card. If M is
selected, the module will be called i810. AGP support is required
for this driver to work.
drm/i915: Kconfig option to disable the legacy fbdev support Boots Just Fine (tm)! The only glitch seems to be that at least on Fedora the boot splash gets confused and doesn't display much at all. And since there's no ugly console flickering anymore in between, the flicker while switching between X servers (VT support is still enabled) is even more jarring. Also, I'm unsure whether we don't need to somehow kick out vgacon, now that nothing else gets in the way. But stuff seems to work, so I don't care. Also everything still works as well with VGA_CONSOLE=n Also the #ifdef mess needs a bit of a cleanup, follow-up patches will do just that. To keep the Kconfig tidy, extract all the i915 options into its own file. v2: - Rebase on top of the preliminary hw support option and the intel_drv.h cleanup. - Shut up warnings in i915_debugfs.c v3: Use the right CONFIG variable, spotted by Chon Ming. Cc: Lee, Chon Ming <chon.ming.lee@intel.com> Cc: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-09 15:18:51 +08:00
source "drivers/gpu/drm/i915/Kconfig"
i915: Add a Kconfig option to turn on i915.preliminary_hw_support by default When building kernels for a preliminary hardware target, having to add a kernel command-line option can prove inconvenient. Add a Kconfig option that changes the default of this option to 1. Signed-off-by: Josh Triplett <josh@joshtriplett.org> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Pimp the Kconfig help text a bit as suggested by Damien in his 2nd review.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-14 07:23:17 +08:00
Linux-2.6.12-rc2 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!
2005-04-17 06:20:36 +08:00
config DRM_MGA
tristate "Matrox g200/g400"
drm: add PCI requirements to low-level drivers. Now that highlevel DRM no longer requires PCI, we can move the requirement into the lowlevel drivers. Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-07-09 05:43:27 +08:00
depends on DRM && PCI
drm/mga: Use request_firmware() to load microcode 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>
2009-08-24 01:34:25 +08:00
select FW_LOADER
Linux-2.6.12-rc2 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!
2005-04-17 06:20:36 +08:00
help
Choose this option if you have a Matrox G200, G400 or G450 graphics
card. If M is selected, the module will be called mga. AGP
support is required for this driver to work.
config DRM_SIS
tristate "SiS video cards"
depends on DRM && AGP
FB_SIS=m, DRM_SIS=y is not a legal configuration. Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-08-24 15:11:22 +08:00
depends on FB_SIS || FB_SIS=n
Linux-2.6.12-rc2 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!
2005-04-17 06:20:36 +08:00
help
drm: run cleanfile across drm tree Signed-off-by: Dave Airlie <airlied@linux.ie>
2007-11-05 10:50:58 +08:00
Choose this option if you have a SiS 630 or compatible video
Linux-2.6.12-rc2 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!
2005-04-17 06:20:36 +08:00
chipset. If M is selected the module will be called sis. AGP
support is required for this driver to work.
drm: Add via unichrome support 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>
2005-06-28 20:48:56 +08:00
config DRM_VIA
tristate "Via unichrome video cards"
drm: add PCI requirements to low-level drivers. Now that highlevel DRM no longer requires PCI, we can move the requirement into the lowlevel drivers. Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-07-09 05:43:27 +08:00
depends on DRM && PCI
drm: Add via unichrome support 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>
2005-06-28 20:48:56 +08:00
help
Choose this option if you have a Via unichrome or compatible video
chipset. If M is selected the module will be called via.
drm: add savage driver Add driver for savage chipsets. From: Felix Kuehling Signed-off-by: Dave Airlie <airlied@linux.ie>
2005-08-07 13:43:54 +08:00
config DRM_SAVAGE
tristate "Savage video cards"
drm: add PCI requirements to low-level drivers. Now that highlevel DRM no longer requires PCI, we can move the requirement into the lowlevel drivers. Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-07-09 05:43:27 +08:00
depends on DRM && PCI
drm: add savage driver Add driver for savage chipsets. From: Felix Kuehling Signed-off-by: Dave Airlie <airlied@linux.ie>
2005-08-07 13:43:54 +08:00
help
Choose this option if you have a Savage3D/4/SuperSavage/Pro/Twister
chipset. If M is selected the module will be called savage.
DRM: add DRM Driver for Samsung SoC EXYNOS4210. This patch is a DRM Driver for Samsung SoC Exynos4210 and now enables only FIMD yet but we will add HDMI support also in the future. this patch is based on git repository below: git://people.freedesktop.org/~airlied/linux.git branch name: drm-next commit-id: 88ef4e3f4f616462b78a7838eb3ffc3818d30f67 you can refer to our working repository below: http://git.infradead.org/users/kmpark/linux-2.6-samsung branch name: samsung-drm We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c based on Linux framebuffer) but couldn't so because lowlevel codes of s3c-fb.c are included internally and so FIMD module of this driver has its own lowlevel codes. We used GEM framework for buffer management and DMA APIs(dma_alloc_*) for buffer allocation so we can allocate physically continuous memory for DMA through it and also we could use CMA later if CMA is applied to mainline. Refer to this link for CMA(Continuous Memory Allocator): http://lkml.org/lkml/2011/7/20/45 this driver supports only physically continuous memory(non-iommu). Links to previous versions of the patchset: v1: < https://lwn.net/Articles/454380/ > v2: < http://www.spinics.net/lists/kernel/msg1224275.html > v3: < http://www.spinics.net/lists/dri-devel/msg13755.html > v4: < http://permalink.gmane.org/gmane.comp.video.dri.devel/60439 > v5: < http://comments.gmane.org/gmane.comp.video.dri.devel/60802 > Changelog v2: DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command. this feature maps user address space to physical memory region once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl. DRM: code clean and add exception codes. Changelog v3: DRM: Support multiple irq. FIMD and HDMI have their own irq handler but DRM Framework can regiter only one irq handler this patch supports mutiple irq for Samsung SoC. DRM: Consider modularization. each DRM, FIMD could be built as a module. DRM: Have indenpendent crtc object. crtc isn't specific to SoC Platform so this patch gets a crtc to be used as common object. created crtc could be attached to any encoder object. DRM: code clean and add exception codes. Changelog v4: DRM: remove is_defult from samsung_fb. is_default isn't used for default framebuffer. DRM: code refactoring to fimd module. this patch is be considered with multiple display objects and would use its own request_irq() to register a irq handler instead of drm framework's one. DRM: remove find_samsung_drm_gem_object() DRM: move kernel private data structures and definitions to driver folder. samsung_drm.h would contain only public information for userspace ioctl interface. DRM: code refactoring to gem modules. buffer module isn't dependent of gem module anymore. DRM: fixed security issue. DRM: remove encoder porinter from specific connector. samsung connector doesn't need to have generic encoder. DRM: code clean and add exception codes. Changelog v5: DRM: updated fimd(display controller) driver. added various pixel formats, color key and pixel blending features. DRM: removed end_buf_off from samsung_drm_overlay structure. this variable isn't used and end buffer address would be calculated by each sub driver. DRM: use generic function for mmap_offset. replaced samsung_drm_gem_create_mmap_offset() and samsung_drm_free_mmap_offset() with generic ones applied to mainline recentrly. DRM: removed unnecessary codes and added exception codes. DRM: added comments and code clean. Changelog v6: DRM: added default config options. DRM: added padding for 64-bit align. DRM: changed prefix 'samsung' to 'exynos' Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-10-04 18:19:01 +08:00
vmwgfx: Take the driver out of staging Also improve a bit on the Kconfig help. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-10-11 16:42:51 +08:00
source "drivers/gpu/drm/exynos/Kconfig"
source "drivers/gpu/drm/vmwgfx/Kconfig"
gma500: Now connect up to the DRM build to finish the job Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-11-04 02:22:48 +08:00
source "drivers/gpu/drm/gma500/Kconfig"
drm/udl: initial UDL driver (v4) This is an initial drm/kms driver for the displaylink devices. Supports fb_defio, supports KMS dumb interface supports 24bpp via conversion to 16bpp, hw can do this better. supports hot unplug using new drm core features. On an unplug, it disables connector polling, unplugs connectors from sysfs, unplugs fbdev layer (using Kay's API), drops all the USB device URBs, and call the drm core to unplug the device. This driver is based in large parts on udlfb.c so I've licensed it under GPLv2. Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-12-15 05:14:24 +08:00
source "drivers/gpu/drm/udl/Kconfig"
drm: Initial KMS driver for AST (ASpeed Technologies) 2000 series (v2) This is the initial driver for the Aspeed Technologies chips found in servers. This driver supports the AST 2000, 2100, 2200, 2150 and 2300. It doesn't support the AST11xx due to lack of hw to test it on, and them requiring different codepaths. This driver is intended to be used with xf86-video-modesetting in userspace. This driver has a slightly different design than other KMS drivers, but future server chips will probably share similiar setup. As these GPUs commonly have low video RAM, it doesn't make sense to put the kms console in VRAM always. This driver places the kms console into system RAM, and does dirty updates to a copy in video RAM. When userspace sets a new scanout buffer, it forcefully evicts the video RAM console, and X can create a framebuffer that can use all of of video RAM. This driver uses TTM but in a very simple fashion to control the eviction to system RAM of the console, and multiple servers. v2: add s/r support, fix Kconfig. Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-29 21:40:04 +08:00
source "drivers/gpu/drm/ast/Kconfig"
mgag200: initial g200se driver (v2) This is a driver for the G200 server engines chips, it doesn't driver any of the Matrix G series desktop cards. It will bind to G200 SE A,B, G200EV, G200WB, G200EH and G200ER cards. Its based on previous work done my Matthew Garrett but remodelled to follow the same style and flow as the AST server driver. It also works along the same lines as the AST server driver wrt memory management. There is no userspace driver planned, xf86-video-modesetting should be used. It also appears these GPUs have no ARGB hw cursors. v2: add missing tagfifo reset + G200 SE memory bw setup pieces. Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-04-17 22:01:25 +08:00
source "drivers/gpu/drm/mgag200/Kconfig"
drm/kms: driver for virtual cirrus under qemu This is the initial driver for emulated cirrus GPU found in qemu. This driver only supports the emulated GPU and doesn't attempt to bind to any real cirrus GPUs. This driver is intended to be used with xf86-video-modesetting in userspace. It requires at least version 0.3.0 This follow the same design as ast and mgag200, and is based on work done by Matthew Garrett previously. This GPU has no hw cursor, and it can't scanout 32-bpp, only packed 24-bpp. i.e. it sucks. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-04-17 21:12:29 +08:00
source "drivers/gpu/drm/cirrus/Kconfig"
drm: Renesas SH Mobile DRM driver The SH Mobile LCD controller (LCDC) DRM driver supports the main graphics plane in RGB and YUV formats, as well as the overlay planes (in alpha-blending mode only). Only flat panel outputs using the parallel interface are supported. Support for SYS panels, HDMI and DSI is currently not implemented. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
2012-04-26 19:53:59 +08:00
DRM: Armada: Add Armada DRM driver This patch adds support for the pair of LCD controllers on the Marvell Armada 510 SoCs. This driver supports: - multiple contiguous scanout buffers for video and graphics - shm backed cacheable buffer objects for X pixmaps for Vivante GPU acceleration - dual lcd0 and lcd1 crt operation - video overlay on each LCD crt via DRM planes - page flipping of the main scanout buffers - DRM prime for buffer export/import This driver is trivial to extend to other Armada SoCs. Included in this commit is the core driver with no output support; output support is platform and encoder driver dependent. Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-15 20:59:49 +08:00
source "drivers/gpu/drm/armada/Kconfig"
drm: Renesas R-Car Display Unit DRM driver The R-Car Display Unit (DU) DRM driver supports both superposition processors and all eight planes in RGB and YUV formats with alpha blending. Only VGA and LVDS encoders and connectors are currently supported. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-06-19 19:54:11 +08:00
source "drivers/gpu/drm/rcar-du/Kconfig"
drm: Renesas SH Mobile DRM driver The SH Mobile LCD controller (LCDC) DRM driver supports the main graphics plane in RGB and YUV formats, as well as the overlay planes (in alpha-blending mode only). Only flat panel outputs using the parallel interface are supported. Support for SYS panels, HDMI and DSI is currently not implemented. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
2012-04-26 19:53:59 +08:00
source "drivers/gpu/drm/shmobile/Kconfig"
drm: Add NVIDIA Tegra20 support This commit adds a KMS driver for the Tegra20 SoC. This includes basic support for host1x and the two display controllers found on the Tegra20 SoC. Each display controller can drive a separate RGB/LVDS output. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Tested-by: Stephen Warren <swarren@nvidia.com> Acked-by: Mark Zhang <markz@nvidia.com> Reviewed-by: Mark Zhang <markz@nvidia.com> Tested-by: Mark Zhang <markz@nvidia.com> Tested-and-acked-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Terje Bergstrom <tbergstrom@nvidia.com> Tested-by: Terje Bergstrom <tbergstrom@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-11-16 05:28:22 +08:00
drm/omap: move out of staging Now that the omapdss interface has been reworked so that omapdrm can use dispc directly, we have been able to fix the remaining functional kms issues with omapdrm. And in the mean time the PM sequencing and many other of that open issues have been solved. So I think it makes sense to finally move omapdrm out of staging. Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-02-12 01:43:09 +08:00
source "drivers/gpu/drm/omapdrm/Kconfig"
Merge branch 'tilcdc-next' of git://people.freedesktop.org/~robclark/linux into drm-next KMS driver for TI LCD controller * 'tilcdc-next' of git://people.freedesktop.org/~robclark/linux: drm/tilcdc: add support for LCD panels (v5) drm/tilcdc: add encoder slave (v2) drm/i2c: nxp-tda998x (v3) drm/tilcdc: add TI LCD Controller DRM driver (v4) drm/nouveau: use i2c encoder helper wrappers drm: i2c encoder helper wrappers drm/cma: add debugfs helpers drm: small fix in drm_send_vblank_event() drm: Don't set the plane->fb to NULL on successfull set_plane drm/cma-helper: fixup compilation Conflicts: drivers/gpu/drm/Kconfig drivers/gpu/drm/Makefile drivers/gpu/drm/drm_fb_cma_helper.c
2013-02-21 07:31:47 +08:00
drm/tilcdc: add TI LCD Controller DRM driver (v4) A simple DRM/KMS driver for the TI LCD Controller found in various smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the CMA helpers. Currently only the TFP410 DVI encoder is supported (tested with beaglebone + DVI cape). There are also various LCD displays, for which support can be added (as I get hw to test on), and an external i2c HDMI encoder found on some boards. The display controller supports a single CRTC. And the encoder+ connector are split out into sub-devices. Depending on which LCD or external encoder is actually present, the appropriate output module(s) will be loaded. v1: original v2: fix fb refcnting and few other cleanups v3: get +/- vsync/hsync from timings rather than panel-info, add option DT max-bandwidth field so driver doesn't attempt to pick a display mode with too high memory bandwidth, and other small cleanups v4: remove some unneeded stuff from panel-info struct, properly set high bits for hfp/hsw/hbp for rev 2, add DT bindings docs Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Koen Kooi <koen@dominion.thruhere.net>
2013-01-09 05:04:28 +08:00
source "drivers/gpu/drm/tilcdc/Kconfig"
drm: add new QXL driver. (v1.4) QXL is a paravirtual graphics device used by the Spice virtual desktop interface. The drivers uses GEM and TTM to manage memory, the qxl hw fencing however is quite different than normal TTM expects, we have to keep track of a number of non-linear fence ids per bo that we need to have released by the hardware. The releases are freed from a workqueue that wakes up and processes the release ring. releases are suballocated from a BO, there are 3 release categories, drawables, surfaces and cursor cmds. The hw also has 3 rings for commands, cursor and release handling. The hardware also have a surface id tracking mechnaism and the driver encapsulates it completely inside the kernel, userspace never sees the actual hw surface ids. This requires a newer version of the QXL userspace driver, so shouldn't be enabled until that has been placed into your distro of choice. Authors: Dave Airlie, Alon Levy v1.1: fixup some issues in the ioctl interface with padding v1.2: add module device table v1.3: fix nomodeset, fbcon leak, dumb bo create, release ring irq, don't try flush release ring (broken hw), fix -modesetting. v1.4: fbcon cpu usage reduction + suitable accel flags. Signed-off-by: Alon Levy <alevy@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-02-25 12:47:55 +08:00
source "drivers/gpu/drm/qxl/Kconfig"
drm/msm: basic KMS driver for snapdragon The snapdragon chips have multiple different display controllers, depending on which chip variant/version. (As far as I can tell, current devices have either MDP3 or MDP4, and upcoming devices have MDSS.) And then external to the display controller are HDMI, DSI, etc. blocks which may be shared across devices which have different display controller blocks. To more easily add support for different display controller blocks, the display controller specific bits are split out into a "kms" module, which provides the kms plane/crtc/encoder objects. The external HDMI, DSI, etc. blocks are part encoder, and part connector currently. But I think I will pull in the drm_bridge patches from chromeos tree, and split them into a bridge+connector, with the registers that need to be set in modeset handled by the bridge. This would remove the 'msm_connector' base class. But some things need to be double checked to make sure I could get the correct ON/OFF sequencing.. This patch adds support for mdp4 crtc (including hw cursor), dtv encoder (part of MDP4 block), and hdmi. Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-06-27 00:44:06 +08:00
source "drivers/gpu/drm/msm/Kconfig"
drm/tegra: Move driver to DRM tree In order to make subsystem-wide changes easier, move the Tegra DRM driver back into the DRM tree. Signed-off-by: Thierry Reding <treding@nvidia.com>
2013-10-09 16:32:49 +08:00
source "drivers/gpu/drm/tegra/Kconfig"