2005-04-16 15:20:36 -07:00
#
# Drm device configuration
#
# This driver provides support for the
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
#
2007-10-16 01:29:39 -07:00
menuconfig DRM
2005-04-16 15:20:36 -07:00
tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)"
2017-01-04 10:12:57 +01:00
depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
2017-11-25 20:35:49 +01:00
select DRM_PANEL_ORIENTATION_QUIRKS
2012-11-21 15:31:35 +01:00
select HDMI
2014-08-06 10:08:32 +02:00
select FB_CMDLINE
2008-12-13 18:21:08 +10:00
select I2C
select I2C_ALGOBIT
2011-11-25 15:21:02 +00:00
select DMA_SHARED_BUFFER
2016-11-15 22:06:39 +09:00
select SYNC_FILE
2005-04-16 15:20:36 -07: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
2010-05-27 13:40:25 -06:00
(/dev/agpgart) support if it is available for your platform.
2005-04-16 15:20:36 -07:00
2013-12-04 16:35:12 +01:00
config DRM_MIPI_DSI
bool
depends on DRM
2016-01-21 15:10:19 -08:00
config DRM_DP_AUX_CHARDEV
bool "DRM DP AUX Interface"
depends on DRM
help
Choose this option to enable a /dev/drm_dp_auxN node that allows to
read and write values to arbitrary DPCD registers on the DP aux
channel.
2016-10-31 09:08:06 +00:00
config DRM_DEBUG_MM
bool "Insert extra checks and debug info into the DRM range managers"
default n
2016-11-08 13:19:17 +00:00
depends on DRM=y
2016-11-09 14:39:06 +00:00
depends on STACKTRACE_SUPPORT
2016-10-31 09:08:06 +00:00
select STACKDEPOT
help
Enable allocation tracking of memory manager and leak detection on
shutdown.
Recommended for driver developers only.
If in doubt, say "N".
2018-05-03 13:22:16 +02:00
config DRM_DEBUG_SELFTEST
tristate "kselftests for DRM"
2016-12-22 08:36:09 +00:00
depends on DRM
depends on DEBUG_KERNEL
select PRIME_NUMBERS
select DRM_LIB_RANDOM
2018-05-03 13:22:17 +02:00
select DRM_KMS_HELPER
2016-12-22 08:36:09 +00:00
default n
help
2018-05-03 13:22:16 +02:00
This option provides kernel modules that can be used to run
various selftests on parts of the DRM api. This option is not
2016-12-22 08:36:09 +00:00
useful for distributions or general kernels, but only for kernel
developers working on DRM and associated drivers.
If in doubt, say "N".
2009-09-08 11:08:32 +10:00
config DRM_KMS_HELPER
2009-09-07 15:45:33 +10:00
tristate
depends on DRM
2013-10-08 17:44:47 +02:00
help
CRTC helpers for KMS drivers.
config DRM_KMS_FB_HELPER
bool
depends on DRM_KMS_HELPER
2009-09-07 15:45:33 +10:00
select FB
2011-01-20 14:44:16 -08:00
select FRAMEBUFFER_CONSOLE if !EXPERT
2011-04-22 07:51:33 +10:00
select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
2015-07-31 16:21:41 +05:30
select FB_SYS_FOPS
2015-07-31 16:21:42 +05:30
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
2016-04-28 17:18:33 +02:00
select FB_DEFERRED_IO
2009-09-07 15:45:33 +10:00
help
2013-10-08 17:44:47 +02:00
FBDEV helpers for KMS drivers.
2009-09-07 15:45:33 +10:00
2015-08-05 12:28:57 +05:30
config DRM_FBDEV_EMULATION
bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM
select DRM_KMS_HELPER
select DRM_KMS_FB_HELPER
default y
help
Choose this option if you have a need for the legacy fbdev
support. Note that this support also provides the linux console
support on top of your modesetting driver.
If in doubt, say "Y".
2017-02-15 17:19:08 +01:00
config DRM_FBDEV_OVERALLOC
int "Overallocation of the fbdev buffer"
depends on DRM_FBDEV_EMULATION
default 100
help
Defines the fbdev buffer overallocation in percent. Default
is 100. Typical values for double buffering will be 200,
triple buffering 300.
2018-09-28 14:05:55 +02:00
config DRM_FBDEV_LEAK_PHYS_SMEM
bool "Shamelessly allow leaking of fbdev physical address (DANGEROUS)"
depends on DRM_FBDEV_EMULATION && EXPERT
default n
help
In order to keep user-space compatibility, we want in certain
use-cases to keep leaking the fbdev physical address to the
user-space program handling the fbdev buffer.
This affects, not only, Amlogic, Allwinner or Rockchip devices
with ARM Mali GPUs using an userspace Blob.
This option is not supported by upstream developers and should be
removed as soon as possible and be considered as a broken and
legacy behaviour from a modern fbdev device driver.
Please send any bug reports when using this to your proprietary
software vendor that requires this.
If in doubt, say "N" or spread the word to your closed source
library vendor.
2012-03-18 22:37:33 +01:00
config DRM_LOAD_EDID_FIRMWARE
bool "Allow to specify an EDID data set instead of probing for it"
drm: handle override and firmware EDID at drm_do_get_edid() level
Handle debugfs override edid and firmware edid at the low level to
transparently and completely replace the real edid. Previously, we
practically only used the modes from the override EDID, and none of the
other data, such as audio parameters.
This change also prevents actual EDID reads when the EDID is to be
overridden, but retains the DDC probe. This is useful if the reason for
preferring override EDID are problems with reading the data, or
corruption of the data.
Move firmware EDID loading from helper to core, as the functionality
moves to lower level as well. This will result in a change of module
parameter from drm_kms_helper.edid_firmware to drm.edid_firmware, which
arguably makes more sense anyway.
Some future work remains related to override and firmware EDID
validation. Like before, no validation is done for override EDID. The
firmware EDID is validated separately in the loader. Some unification
and deduplication would be in order, to validate all of them at the
drm_do_get_edid() level, like "real" EDIDs.
v2: move firmware loading to core
v3: rebase, commit message refresh
Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1e8a710bcac46e5136c1a7b430074893c81f364a.1505203831.git.jani.nikula@intel.com
2017-09-12 11:19:26 +03:00
depends on DRM
2012-03-18 22:37:33 +01:00
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.
2018-07-11 15:29:07 +02:00
config DRM_DP_CEC
bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
select CEC_CORE
help
Choose this option if you want to enable HDMI CEC support for
DisplayPort/USB-C to HDMI adapters.
Note: not all adapters support this feature, and even for those
that do support this they often do not hook up the CEC pin.
2009-06-10 15:20:19 +02:00
config DRM_TTM
2009-06-05 14:42:42 +02:00
tristate
2017-01-04 10:12:57 +01:00
depends on DRM && MMU
2009-06-10 15:20:19 +02:00
help
GPU memory management subsystem for devices with multiple
GPU memory types. Will be enabled automatically if a device driver
uses it.
2012-06-27 15:30:18 +02:00
config DRM_GEM_CMA_HELPER
bool
2016-01-20 15:02:05 -08:00
depends on DRM
2012-06-27 15:30:18 +02:00
help
Choose this if you need the GEM CMA helper functions
2012-07-02 16:37:47 +02:00
config DRM_KMS_CMA_HELPER
bool
2016-01-20 15:02:05 -08:00
depends on DRM
2012-07-02 16:37:47 +02:00
select DRM_GEM_CMA_HELPER
help
Choose this if you need the KMS CMA helper functions
2019-03-12 19:43:44 -05:00
config DRM_GEM_SHMEM_HELPER
bool
depends on DRM
help
Choose this if you need the GEM shmem helper functions
2017-01-04 10:12:56 +01:00
config DRM_VM
bool
2017-01-12 09:57:36 +01:00
depends on DRM && MMU
2017-01-04 10:12:56 +01:00
2017-12-06 17:49:39 +01:00
config DRM_SCHED
tristate
depends on DRM
2013-01-24 21:46:07 +00:00
source "drivers/gpu/drm/i2c/Kconfig"
2015-04-02 19:48:39 +01:00
source "drivers/gpu/drm/arm/Kconfig"
2005-04-16 15:20:36 -07:00
config DRM_RADEON
tristate "ATI Radeon"
2017-01-07 12:39:11 +01:00
depends on DRM && PCI && MMU
2009-08-29 14:53:51 +01:00
select FW_LOADER
2009-09-08 11:09:50 +10:00
select DRM_KMS_HELPER
select DRM_TTM
2010-05-21 15:41:20 +10:00
select POWER_SUPPLY
2010-07-02 12:58:16 -04:00
select HWMON
2013-01-21 13:58:46 +01:00
select BACKLIGHT_CLASS_DEVICE
2015-08-14 12:50:11 +02:00
select BACKLIGHT_LCD_SUPPORT
2014-07-30 11:49:56 -04:00
select INTERVAL_TREE
2005-04-16 15:20:36 -07: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
2006-03-20 20:23:13 +01:00
run the Radeon in plain VGA mode.
2007-11-05 12:50:58 +10:00
2005-04-16 15:20:36 -07:00
If M is selected, the module will be called radeon.
2010-02-01 11:35:47 +10:00
source "drivers/gpu/drm/radeon/Kconfig"
2015-04-20 16:55:21 -04:00
config DRM_AMDGPU
tristate "AMD GPU"
2017-01-07 12:39:11 +01:00
depends on DRM && PCI && MMU
2015-04-20 16:55:21 -04:00
select FW_LOADER
select DRM_KMS_HELPER
2017-12-06 17:49:39 +01:00
select DRM_SCHED
2015-04-20 16:55:21 -04:00
select DRM_TTM
select POWER_SUPPLY
select HWMON
select BACKLIGHT_CLASS_DEVICE
2015-08-14 12:50:12 +02:00
select BACKLIGHT_LCD_SUPPORT
2015-04-20 16:55:21 -04:00
select INTERVAL_TREE
2017-08-26 02:43:06 -04:00
select CHASH
2015-04-20 16:55:21 -04:00
help
Choose this option if you have a recent AMD Radeon graphics card.
If M is selected, the module will be called amdgpu.
source "drivers/gpu/drm/amd/amdgpu/Kconfig"
2015-09-22 17:05:20 -04:00
2017-08-24 19:22:32 -04:00
source "drivers/gpu/drm/amd/lib/Kconfig"
2012-03-16 18:19:14 +10:00
source "drivers/gpu/drm/nouveau/Kconfig"
2013-10-09 09:18:51 +02:00
source "drivers/gpu/drm/i915/Kconfig"
2013-08-13 16:23:17 -07:00
2015-03-04 16:33:41 -08:00
config DRM_VGEM
tristate "Virtual GEM provider"
depends on DRM
help
Choose this option to get a virtual graphics memory manager,
as used by Mesa's software renderer for enhanced performance.
If M is selected the module will be called vgem.
2018-05-14 17:33:46 +03:00
config DRM_VKMS
2018-05-16 20:56:40 -03:00
tristate "Virtual KMS (EXPERIMENTAL)"
2018-05-14 17:33:46 +03:00
depends on DRM
2018-07-09 17:48:18 +02:00
select DRM_KMS_HELPER
2018-05-16 20:56:40 -03:00
default n
2018-05-14 17:33:46 +03:00
help
2018-05-16 20:56:40 -03:00
Virtual Kernel Mode-Setting (VKMS) is used for testing or for
running GPU in a headless machines. Choose this option to get
a VKMS.
2018-05-14 17:33:46 +03:00
If M is selected the module will be called vkms.
2015-03-04 16:33:41 -08:00
2011-10-11 10:42:51 +02:00
source "drivers/gpu/drm/exynos/Kconfig"
2014-08-22 18:36:26 +08:00
source "drivers/gpu/drm/rockchip/Kconfig"
2011-10-11 10:42:51 +02:00
source "drivers/gpu/drm/vmwgfx/Kconfig"
2011-11-03 18:22:48 +00:00
source "drivers/gpu/drm/gma500/Kconfig"
2010-12-15 07:14:24 +10: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 13:40:04 +00:00
source "drivers/gpu/drm/ast/Kconfig"
2012-04-17 15:01:25 +01:00
source "drivers/gpu/drm/mgag200/Kconfig"
2012-04-17 14:12:29 +01:00
source "drivers/gpu/drm/cirrus/Kconfig"
2012-04-26 13:53:59 +02:00
2012-08-15 13:59:49 +01:00
source "drivers/gpu/drm/armada/Kconfig"
2015-01-06 11:13:28 +01:00
source "drivers/gpu/drm/atmel-hlcdc/Kconfig"
2013-06-19 13:54:11 +02:00
source "drivers/gpu/drm/rcar-du/Kconfig"
2012-04-26 13:53:59 +02:00
source "drivers/gpu/drm/shmobile/Kconfig"
2012-11-15 21:28:22 +00:00
2015-10-29 09:36:23 +01:00
source "drivers/gpu/drm/sun4i/Kconfig"
2013-02-11 12:43:09 -05:00
source "drivers/gpu/drm/omapdrm/Kconfig"
2013-02-21 09:31:47 +10:00
2013-01-08 15:04:28 -06: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 14:47:55 +10: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-26 12:44:06 -04:00
2013-12-17 18:04:46 +01:00
source "drivers/gpu/drm/bochs/Kconfig"
2013-09-09 10:02:56 +10:00
source "drivers/gpu/drm/virtio/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-26 12:44:06 -04:00
source "drivers/gpu/drm/msm/Kconfig"
2013-10-09 10:32:49 +02:00
2015-08-19 22:19:49 -04:00
source "drivers/gpu/drm/fsl-dcu/Kconfig"
2013-10-09 10:32:49 +02:00
source "drivers/gpu/drm/tegra/Kconfig"
2013-08-30 13:36:43 +02:00
2017-04-14 12:13:34 +02:00
source "drivers/gpu/drm/stm/Kconfig"
2013-08-30 13:36:43 +02:00
source "drivers/gpu/drm/panel/Kconfig"
2014-07-30 18:20:56 +02:00
2015-07-21 17:01:19 +02:00
source "drivers/gpu/drm/bridge/Kconfig"
2014-07-30 18:20:56 +02:00
source "drivers/gpu/drm/sti/Kconfig"
2014-07-16 21:08:55 +03:00
2014-11-24 16:33:34 +01:00
source "drivers/gpu/drm/imx/Kconfig"
2015-03-02 13:01:12 -08:00
2018-04-30 11:10:58 -07:00
source "drivers/gpu/drm/v3d/Kconfig"
2015-03-02 13:01:12 -08:00
source "drivers/gpu/drm/vc4/Kconfig"
2015-12-03 18:21:29 +01:00
source "drivers/gpu/drm/etnaviv/Kconfig"
2016-02-19 15:30:26 +03:00
source "drivers/gpu/drm/arc/Kconfig"
2015-10-09 18:00:56 +08:00
source "drivers/gpu/drm/hisilicon/Kconfig"
2016-01-04 18:36:34 +01:00
source "drivers/gpu/drm/mediatek/Kconfig"
2016-08-04 10:06:56 +02:00
2016-09-22 19:52:39 +08:00
source "drivers/gpu/drm/zte/Kconfig"
2016-08-18 20:23:01 +02:00
source "drivers/gpu/drm/mxsfb/Kconfig"
2016-11-10 15:29:37 +01:00
source "drivers/gpu/drm/meson/Kconfig"
2017-01-22 00:15:00 +01:00
source "drivers/gpu/drm/tinydrm/Kconfig"
drm/pl111: Initial drm/kms driver for pl111
This is a modesetting driver for the pl111 CLCD display controller
found on various ARM platforms such as the Versatile Express. The
driver has only been tested on the bcm911360_entphn platform so far,
with PRIME-based buffer sharing between vc4 and clcd.
It reuses the existing devicetree binding, while not using quite as
many of its properties as the fbdev driver does (those are left for
future work).
v2: Nearly complete rewrite by anholt, cutting 2/3 of the code thanks
to DRM core's excellent new helpers.
v3: Don't match pl110 any more, don't attach if we don't have a DRM
panel, use DRM_GEM_CMA_FOPS, update MAINTAINERS, use the simple
display helper, use drm_gem_cma_dumb_create (same as our wrapper).
v4: Change the driver's .name to not clash with fbdev in sysfs, drop
platform alias, drop redundant "drm" in DRM driver name, hook up
.prepare_fb to the CMA helper so that DMA fences should work.
v5: Move register definitions inside the driver directory, fix build
in COMPILE_TEST and !AMBA mode.
v6: Drop TIM2_CLKSEL for now to be consistent with existing DT
bindings, switch back to external register definitions.
Signed-off-by: Tom Cooksey <tom.cooksey@arm.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> (v5)
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170413031746.12921-2-eric@anholt.net
2017-04-12 20:17:46 -07:00
source "drivers/gpu/drm/pl111/Kconfig"
2017-08-20 12:05:55 +02:00
source "drivers/gpu/drm/tve200/Kconfig"
drm/xen-front: Add support for Xen PV display frontend
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
Xen guest domain configuration options [3].
Driver limitations:
1. Only primary plane without additional properties is supported.
2. Only one video mode supported which resolution is configured
via XenStore.
3. All CRTCs operate at fixed frequency of 60Hz.
1. Implement Xen bus state machine for the frontend driver according to
the state diagram and recovery flow from display para-virtualized
protocol: xen/interface/io/displif.h.
2. Read configuration values from Xen store according
to xen/interface/io/displif.h protocol:
- read connector(s) configuration
- read buffer allocation mode (backend/frontend)
3. Handle Xen event channels:
- create for all configured connectors and publish
corresponding ring references and event channels in Xen store,
so backend can connect
- implement event channels interrupt handlers
- create and destroy event channels with respect to Xen bus state
4. Implement shared buffer handling according to the
para-virtualized display device protocol at xen/interface/io/displif.h:
- handle page directories according to displif protocol:
- allocate and share page directories
- grant references to the required set of pages for the
page directory
- allocate xen balllooned pages via Xen balloon driver
with alloc_xenballooned_pages/free_xenballooned_pages
- grant references to the required set of pages for the
shared buffer itself
- implement pages map/unmap for the buffers allocated by the
backend (gnttab_map_refs/gnttab_unmap_refs)
5. Implement kernel modesetiing/connector handling using
DRM simple KMS helper pipeline:
- implement KMS part of the driver with the help of DRM
simple pipepline helper which is possible due to the fact
that the para-virtualized driver only supports a single
(primary) plane:
- initialize connectors according to XenStore configuration
- handle frame done events from the backend
- create and destroy frame buffers and propagate those
to the backend
- propagate set/reset mode configuration to the backend on display
enable/disable callbacks
- send page flip request to the backend and implement logic for
reporting backend IO errors on prepare fb callback
- implement virtual connector handling:
- support only pixel formats suitable for single plane modes
- make sure the connector is always connected
- support a single video mode as per para-virtualized driver
configuration
6. Implement GEM handling depending on driver mode of operation:
depending on the requirements for the para-virtualized environment,
namely requirements dictated by the accompanying DRM/(v)GPU drivers
running in both host and guest environments, number of operating
modes of para-virtualized display driver are supported:
- display buffers can be allocated by either
frontend driver or backend
- display buffers can be allocated to be contiguous
in memory or not
Note! Frontend driver itself has no dependency on contiguous memory for
its operation.
6.1. Buffers allocated by the frontend driver.
The below modes of operation are configured at compile-time via
frontend driver's kernel configuration.
6.1.1. Front driver configured to use GEM CMA helpers
This use-case is useful when used with accompanying DRM/vGPU driver
in guest domain which was designed to only work with contiguous
buffers, e.g. DRM driver based on GEM CMA helpers: such drivers can
only import contiguous PRIME buffers, thus requiring frontend driver
to provide such. In order to implement this mode of operation
para-virtualized frontend driver can be configured to use
GEM CMA helpers.
6.1.2. Front driver doesn't use GEM CMA
If accompanying drivers can cope with non-contiguous memory then, to
lower pressure on CMA subsystem of the kernel, driver can allocate
buffers from system memory.
Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
may require IOMMU support on the platform, so accompanying DRM/vGPU
hardware can still reach display buffer memory while importing PRIME
buffers from the frontend driver.
6.2. Buffers allocated by the backend
This mode of operation is run-time configured via guest domain
configuration through XenStore entries.
For systems which do not provide IOMMU support, but having specific
requirements for display buffers it is possible to allocate such buffers
at backend side and share those with the frontend.
For example, if host domain is 1:1 mapped and has DRM/GPU hardware
expecting physically contiguous memory, this allows implementing
zero-copying use-cases.
Note, while using this scenario the following should be considered:
a) If guest domain dies then pages/grants received from the backend
cannot be claimed back
b) Misbehaving guest may send too many requests to the
backend exhausting its grant references and memory
(consider this from security POV).
Note! Configuration options 1.1 (contiguous display buffers) and 2
(backend allocated buffers) are not supported at the same time.
7. Handle communication with the backend:
- send requests and wait for the responses according
to the displif protocol
- serialize access to the communication channel
- time-out used for backend communication is set to 3000 ms
- manage display buffers shared with the backend
[1] https://github.com/xen-troops/displ_be
[2] https://github.com/xen-troops/libxenbe
[3] https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/man/xl.cfg.pod.5.in;h=a699367779e2ae1212ff8f638eff0206ec1a1cc9;hb=refs/heads/master#l1257
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180403112317.28751-2-andr2000@gmail.com
2018-04-03 14:23:17 +03:00
source "drivers/gpu/drm/xen/Kconfig"
2019-03-04 17:47:24 +01:00
source "drivers/gpu/drm/vboxvideo/Kconfig"
2016-08-04 10:06:56 +02:00
# Keep legacy drivers last
menuconfig DRM_LEGACY
bool "Enable legacy drivers (DANGEROUS)"
2017-01-12 09:57:36 +01:00
depends on DRM && MMU
2017-01-04 10:12:56 +01:00
select DRM_VM
2016-08-04 10:06:56 +02:00
help
Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
APIs to user-space, which can be used to circumvent access
restrictions and other security measures. For backwards compatibility
those drivers are still available, but their use is highly
inadvisable and might harm your system.
You are recommended to use the safe modeset-only drivers instead, and
perform 3D emulation in user-space.
Unless you have strong reasons to go rogue, say "N".
if DRM_LEGACY
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
select FW_LOADER
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_I810
tristate "Intel I810"
# !PREEMPT because of missing ioctl locking
depends on DRM && AGP && AGP_INTEL && (!PREEMPT || BROKEN)
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.
config DRM_MGA
tristate "Matrox g200/g400"
depends on DRM && PCI
select FW_LOADER
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
depends on FB_SIS || FB_SIS=n
help
Choose this option if you have a SiS 630 or compatible video
chipset. If M is selected the module will be called sis. AGP
support is required for this driver to work.
config DRM_VIA
tristate "Via unichrome video cards"
depends on DRM && PCI
help
Choose this option if you have a Via unichrome or compatible video
chipset. If M is selected the module will be called via.
config DRM_SAVAGE
tristate "Savage video cards"
depends on DRM && PCI
help
Choose this option if you have a Savage3D/4/SuperSavage/Pro/Twister
chipset. If M is selected the module will be called savage.
endif # DRM_LEGACY
2016-12-22 08:36:08 +00:00
2018-01-17 09:10:32 +01:00
# Separate option because drm_panel_orientation_quirks.c is shared with fbdev
config DRM_PANEL_ORIENTATION_QUIRKS
tristate
2016-12-22 08:36:08 +00:00
config DRM_LIB_RANDOM
bool
default n