diff options
| author | Linus Torvalds <torvalds@linux-foundation.org> | 2016-08-01 21:44:08 -0400 |
|---|---|---|
| committer | Linus Torvalds <torvalds@linux-foundation.org> | 2016-08-01 21:44:08 -0400 |
| commit | 731c7d3a205ba89b475b2aa71b5f13dd6ae3de56 (patch) | |
| tree | d2b9c3e0a98b94dfc3e4e60e35622c0143ef4ed4 /Documentation | |
| parent | 77a87824ed676ca8ff8482e4157d3adb284fd381 (diff) | |
| parent | 753e7c8cbd8c503b962294303c7b5e9ea8513443 (diff) | |
Merge tag 'drm-for-v4.8' of git://people.freedesktop.org/~airlied/linux
Merge drm updates from Dave Airlie:
"This is the main drm pull request for 4.8.
I'm down with a cold at the moment so hopefully this isn't in too bad
a state, I finished pulling stuff last week mostly (nouveau fixes just
went in today), so only this message should be influenced by illness.
Apologies to anyone who's major feature I missed :-)
Core:
Lockless GEM BO freeing
Non-blocking atomic work
Documentation changes (rst/sphinx)
Prep for new fencing changes
Simple display helpers
Master/auth changes
Register/unregister rework
Loads of trivial patches/fixes.
New stuff:
ARM Mali display driver (not the 3D chip)
sii902x RGB->HDMI bridge
Panel:
Support for new panels
Improved backlight support
Bridge:
Convert ADV7511 to bridge driver
ADV7533 support
TC358767 (DSI/DPI to eDP) encoder chip support
i915:
BXT support enabled by default
GVT-g infrastructure
GuC command submission and fixes
BXT workarounds
SKL/BKL workarounds
Demidlayering device registration
Thundering herd fixes
Missing pci ids
Atomic updates
amdgpu/radeon:
ATPX improvements for better dGPU power control on PX systems
New power features for CZ/BR/ST
Pipelined BO moves and evictions in TTM
GPU scheduler improvements
GPU reset improvements
Overclocking on dGPUs with amdgpu
Polaris powermanagement enabled
nouveau:
GK20A/GM20B volt and clock improvements.
Initial support for GP100/GP104 GPUs, GP104 will not yet support
acceleration due to NVIDIA having not released firmware for them as of yet.
exynos:
Exynos5433 SoC with IOMMU support.
vc4:
Shader validation for branching
imx-drm:
Atomic mode setting conversion
Reworked DMFC FIFO allocation
External bridge support
analogix-dp:
RK3399 eDP support
Lots of fixes.
rockchip:
Lots of small fixes.
msm:
DT bindings cleanups
Shrinker and madvise support
ASoC HDMI codec support
tegra:
Host1x driver cleanups
SOR reworking for DP support
Runtime PM support
omapdrm:
PLL enhancements
Header refactoring
Gamma table support
arcgpu:
Simulator support
virtio-gpu:
Atomic modesetting fixes.
rcar-du:
Misc fixes.
mediatek:
MT8173 HDMI support
sti:
ASOC HDMI codec support
Minor fixes
fsl-dcu:
Suspend/resume support
Bridge support
amdkfd:
Minor fixes.
etnaviv:
Enable GPU clock gating
hisilicon:
Vblank and other fixes"
* tag 'drm-for-v4.8' of git://people.freedesktop.org/~airlied/linux: (1575 commits)
drm/nouveau/gr/nv3x: fix instobj write offsets in gr setup
drm/nouveau/acpi: fix lockup with PCIe runtime PM
drm/nouveau/acpi: check for function 0x1B before using it
drm/nouveau/acpi: return supported DSM functions
drm/nouveau/acpi: ensure matching ACPI handle and supported functions
drm/nouveau/fbcon: fix font width not divisible by 8
drm/amd/powerplay: remove enable_clock_power_gatings_tasks from initialize and resume events
drm/amd/powerplay: move clockgating to after ungating power in pp for uvd/vce
drm/amdgpu: add query device id and revision id into system info entry at CGS
drm/amdgpu: add new definition in bif header
drm/amd/powerplay: rename smum header guards
drm/amdgpu: enable UVD context buffer for older HW
drm/amdgpu: fix default UVD context size
drm/amdgpu: fix incorrect type of info_id
drm/amdgpu: make amdgpu_cgs_call_acpi_method as static
drm/amdgpu: comment out unused defaults_staturn_pro static const structure to fix the build
drm/amdgpu: enable UVD VM only on polaris
drm/amdgpu: increase timeout of IB test
drm/amdgpu: add destroy session when generate VCE destroy msg.
drm/amd: fix deadlock of job_list_lock V2
...
Diffstat (limited to 'Documentation')
37 files changed, 3306 insertions, 3651 deletions
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 01bab5014a4a..8e6dd4b14314 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -16,7 +16,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ 80211.xml debugobjects.xml sh.xml regulator.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \ - tracepoint.xml gpu.xml media_api.xml w1.xml \ + tracepoint.xml media_api.xml w1.xml \ writing_musb_glue_layer.xml crypto-API.xml iio.xml include Documentation/DocBook/media/Makefile diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index 99cdc05bbb7a..9c10030eb2be 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -161,6 +161,10 @@ X!Edrivers/base/interface.c !Iinclude/linux/fence.h !Edrivers/dma-buf/seqno-fence.c !Iinclude/linux/seqno-fence.h +!Edrivers/dma-buf/fence-array.c +!Iinclude/linux/fence-array.h +!Edrivers/dma-buf/reservation.c +!Iinclude/linux/reservation.h !Edrivers/dma-buf/sync_file.c !Iinclude/linux/sync_file.h </sect2> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl deleted file mode 100644 index 7586bf75f62e..000000000000 --- a/Documentation/DocBook/gpu.tmpl +++ /dev/null @@ -1,3540 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" - "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> - -<book id="gpuDevelopersGuide"> - <bookinfo> - <title>Linux GPU Driver Developer's Guide</title> - - <authorgroup> - <author> - <firstname>Jesse</firstname> - <surname>Barnes</surname> - <contrib>Initial version</contrib> - <affiliation> - <orgname>Intel Corporation</orgname> - <address> - <email>jesse.barnes@intel.com</email> - </address> - </affiliation> - </author> - <author> - <firstname>Laurent</firstname> - <surname>Pinchart</surname> - <contrib>Driver internals</contrib> - <affiliation> - <orgname>Ideas on board SPRL</orgname> - <address> - <email>laurent.pinchart@ideasonboard.com</email> - </address> - </affiliation> - </author> - <author> - <firstname>Daniel</firstname> - <surname>Vetter</surname> - <contrib>Contributions all over the place</contrib> - <affiliation> - <orgname>Intel Corporation</orgname> - <address> - <email>daniel.vetter@ffwll.ch</email> - </address> - </affiliation> - </author> - <author> - <firstname>Lukas</firstname> - <surname>Wunner</surname> - <contrib>vga_switcheroo documentation</contrib> - <affiliation> - <address> - <email>lukas@wunner.de</email> - </address> - </affiliation> - </author> - </authorgroup> - - <copyright> - <year>2008-2009</year> - <year>2013-2014</year> - <holder>Intel Corporation</holder> - </copyright> - <copyright> - <year>2012</year> - <holder>Laurent Pinchart</holder> - </copyright> - <copyright> - <year>2015</year> - <holder>Lukas Wunner</holder> - </copyright> - - <legalnotice> - <para> - The contents of this file may be used under the terms of the GNU - General Public License version 2 (the "GPL") as distributed in - the kernel source COPYING file. - </para> - </legalnotice> - - <revhistory> - <!-- Put document revisions here, newest first. --> - <revision> - <revnumber>1.0</revnumber> - <date>2012-07-13</date> - <authorinitials>LP</authorinitials> - <revremark>Added extensive documentation about driver internals. - </revremark> - </revision> - <revision> - <revnumber>1.1</revnumber> - <date>2015-10-11</date> - <authorinitials>LW</authorinitials> - <revremark>Added vga_switcheroo documentation. - </revremark> - </revision> - </revhistory> - </bookinfo> - -<toc></toc> - -<part id="drmCore"> - <title>DRM Core</title> - <partintro> - <para> - This first part of the GPU Driver Developer's Guide documents core DRM - code, helper libraries for writing drivers and generic userspace - interfaces exposed by DRM drivers. - </para> - </partintro> - - <chapter id="drmIntroduction"> - <title>Introduction</title> - <para> - The Linux DRM layer contains code intended to support the needs - of complex graphics devices, usually containing programmable - pipelines well suited to 3D graphics acceleration. Graphics - drivers in the kernel may make use of DRM functions to make - tasks like memory management, interrupt handling and DMA easier, - and provide a uniform interface to applications. - </para> - <para> - A note on versions: this guide covers features found in the DRM - tree, including the TTM memory manager, output configuration and - mode setting, and the new vblank internals, in addition to all - the regular features found in current kernels. - </para> - <para> - [Insert diagram of typical DRM stack here] - </para> - <sect1> - <title>Style Guidelines</title> - <para> - For consistency this documentation uses American English. Abbreviations - are written as all-uppercase, for example: DRM, KMS, IOCTL, CRTC, and so - on. To aid in reading, documentations make full use of the markup - characters kerneldoc provides: @parameter for function parameters, @member - for structure members, &structure to reference structures and - function() for functions. These all get automatically hyperlinked if - kerneldoc for the referenced objects exists. When referencing entries in - function vtables please use ->vfunc(). Note that kerneldoc does - not support referencing struct members directly, so please add a reference - to the vtable struct somewhere in the same paragraph or at least section. - </para> - <para> - Except in special situations (to separate locked from unlocked variants) - locking requirements for functions aren't documented in the kerneldoc. - Instead locking should be check at runtime using e.g. - <code>WARN_ON(!mutex_is_locked(...));</code>. Since it's much easier to - ignore documentation than runtime noise this provides more value. And on - top of that runtime checks do need to be updated when the locking rules - change, increasing the chances that they're correct. Within the - documentation the locking rules should be explained in the relevant - structures: Either in the comment for the lock explaining what it - protects, or data fields need a note about which lock protects them, or - both. - </para> - <para> - Functions which have a non-<code>void</code> return value should have a - section called "Returns" explaining the expected return values in - different cases and their meanings. Currently there's no consensus whether - that section name should be all upper-case or not, and whether it should - end in a colon or not. Go with the file-local style. Other common section - names are "Notes" with information for dangerous or tricky corner cases, - and "FIXME" where the interface could be cleaned up. - </para> - </sect1> - </chapter> - - <!-- Internals --> - - <chapter id="drmInternals"> - <title>DRM Internals</title> - <para> - This chapter documents DRM internals relevant to driver authors - and developers working to add support for the latest features to - existing drivers. - </para> - <para> - First, we go over some typical driver initialization - requirements, like setting up command buffers, creating an - initial output configuration, and initializing core services. - Subsequent sections cover core internals in more detail, - providing implementation notes and examples. - </para> - <para> - The DRM layer provides several services to graphics drivers, - many of them driven by the application interfaces it provides - through libdrm, the library that wraps most of the DRM ioctls. - These include vblank event handling, memory - management, output management, framebuffer management, command - submission & fencing, suspend/resume support, and DMA - services. - </para> - - <!-- Internals: driver init --> - - <sect1> - <title>Driver Initialization</title> - <para> - At the core of every DRM driver is a <structname>drm_driver</structname> - structure. Drivers typically statically initialize a drm_driver structure, - and then pass it to <function>drm_dev_alloc()</function> to allocate a - device instance. After the device instance is fully initialized it can be - registered (which makes it accessible from userspace) using - <function>drm_dev_register()</function>. - </para> - <para> - The <structname>drm_driver</structname> structure contains static - information that describes the driver and features it supports, and - pointers to methods that the DRM core will call to implement the DRM API. - We will first go through the <structname>drm_driver</structname> static - information fields, and will then describe individual operations in - details as they get used in later sections. - </para> - <sect2> - <title>Driver Information</title> - <sect3> - <title>Driver Features</title> - <para> - Drivers inform the DRM core about their requirements and supported - features by setting appropriate flags in the - <structfield>driver_features</structfield> field. Since those flags - influence the DRM core behaviour since registration time, most of them - must be set to registering the <structname>drm_driver</structname> - instance. - </para> - <synopsis>u32 driver_features;</synopsis> - <variablelist> - <title>Driver Feature Flags</title> - <varlistentry> - <term>DRIVER_USE_AGP</term> - <listitem><para> - Driver uses AGP interface, the DRM core will manage AGP resources. - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRIVER_REQUIRE_AGP</term> - <listitem><para> - Driver needs AGP interface to function. AGP initialization failure - will become a fatal error. - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRIVER_PCI_DMA</term> - <listitem><para> - Driver is capable of PCI DMA, mapping of PCI DMA buffers to - userspace will be enabled. Deprecated. - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRIVER_SG</term> - <listitem><para> - Driver can perform scatter/gather DMA, allocation and mapping of - scatter/gather buffers will be enabled. Deprecated. - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRIVER_HAVE_DMA</term> - <listitem><para> - Driver supports DMA, the userspace DMA API will be supported. - Deprecated. - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRIVER_HAVE_IRQ</term><term>DRIVER_IRQ_SHARED</term> - <listitem><para> - DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler - managed by the DRM Core. The core will support simple IRQ handler - installation when the flag is set. The installation process is - described in <xref linkend="drm-irq-registration"/>.</para> - <para>DRIVER_IRQ_SHARED indicates whether the device & handler - support shared IRQs (note that this is required of PCI drivers). - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRIVER_GEM</term> - <listitem><para> - Driver use the GEM memory manager. - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRIVER_MODESET</term> - <listitem><para> - Driver supports mode setting interfaces (KMS). - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRIVER_PRIME</term> - <listitem><para> - Driver implements DRM PRIME buffer sharing. - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRIVER_RENDER</term> - <listitem><para> - Driver supports dedicated render nodes. - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRIVER_ATOMIC</term> - <listitem><para> - Driver supports atomic properties. In this case the driver - must implement appropriate obj->atomic_get_property() vfuncs - for any modeset objects with driver specific properties. - </para></listitem> - </varlistentry> - </variablelist> - </sect3> - <sect3> - <title>Major, Minor and Patchlevel</title> - <synopsis>int major; -int minor; -int patchlevel;</synopsis> - <para> - The DRM core identifies driver versions by a major, minor and patch - level triplet. The information is printed to the kernel log at - initialization time and passed to userspace through the - DRM_IOCTL_VERSION ioctl. - </para> - <para> - The major and minor numbers are also used to verify the requested driver - API version passed to DRM_IOCTL_SET_VERSION. When the driver API changes - between minor versions, applications can call DRM_IOCTL_SET_VERSION to - select a specific version of the API. If the requested major isn't equal - to the driver major, or the requested minor is larger than the driver - minor, the DRM_IOCTL_SET_VERSION call will return an error. Otherwise - the driver's set_version() method will be called with the requested - version. - </para> - </sect3> - <sect3> - <title>Name, Description and Date</title> - <synopsis>char *name; -char *desc; -char *date;</synopsis> - <para> - The driver name is printed to the kernel log at initialization time, - used for IRQ registration and passed to userspace through - DRM_IOCTL_VERSION. - </para> - <para> - The driver description is a purely informative string passed to - userspace through the DRM_IOCTL_VERSION ioctl and otherwise unused by - the kernel. - </para> - <para> - The driver date, formatted as YYYYMMDD, is meant to identify the date of - the latest modification to the driver. However, as most drivers fail to - update it, its value is mostly useless. The DRM core prints it to the - kernel log at initialization time and passes it to userspace through the - DRM_IOCTL_VERSION ioctl. - </para> - </sect3> - </sect2> - <sect2> - <title>Device Instance and Driver Handling</title> -!Pdrivers/gpu/drm/drm_drv.c driver instance overview -!Edrivers/gpu/drm/drm_drv.c - </sect2> - <sect2> - <title>Driver Load</title> - <sect3 id="drm-irq-registration"> - <title>IRQ Registration</title> - <para> - The DRM core tries to facilitate IRQ handler registration and - unregistration by providing <function>drm_irq_install</function> and - <function>drm_irq_uninstall</function> functions. Those functions only - support a single interrupt per device, devices that use more than one - IRQs need to be handled manually. - </para> - <sect4> - <title>Managed IRQ Registration</title> - <para> - <function>drm_irq_install</function> starts by calling the - <methodname>irq_preinstall</methodname> driver operation. The operation - is optional and must make sure that the interrupt will not get fired by - clearing all pending interrupt flags or disabling the interrupt. - </para> - <para> - The passed-in IRQ will then be requested by a call to - <function>request_irq</function>. If the DRIVER_IRQ_SHARED driver - feature flag is set, a shared (IRQF_SHARED) IRQ handler will be - requested. - </para> - <para> - The IRQ handler function must be provided as the mandatory irq_handler - driver operation. It will get passed directly to - <function>request_irq</function> and thus has the same prototype as all - IRQ handlers. It will get called with a pointer to the DRM device as the - second argument. - </para> - <para> - Finally the function calls the optional - <methodname>irq_postinstall</methodname> driver operation. The operation - usually enables interrupts (excluding the vblank interrupt, which is - enabled separately), but drivers may choose to enable/disable interrupts - at a different time. - </para> - <para> - <function>drm_irq_uninstall</function> is similarly used to uninstall an - IRQ handler. It starts by waking up all processes waiting on a vblank - interrupt to make sure they don't hang, and then calls the optional - <methodname>irq_uninstall</methodname> driver operation. The operation - must disable all hardware interrupts. Finally the function frees the IRQ - by calling <function>free_irq</function>. - </para> - </sect4> - <sect4> - <title>Manual IRQ Registration</title> - <para> - Drivers that require multiple interrupt handlers can't use the managed - IRQ registration functions. In that case IRQs must be registered and - unregistered manually (usually with the <function>request_irq</function> - and <function>free_irq</function> functions, or their devm_* equivalent). - </para> - <para> - When manually registering IRQs, drivers must not set the DRIVER_HAVE_IRQ - driver feature flag, and must not provide the - <methodname>irq_handler</methodname> driver operation. They must set the - <structname>drm_device</structname> <structfield>irq_enabled</structfield> - field to 1 upon registration of the IRQs, and clear it to 0 after - unregistering the IRQs. - </para> - </sect4> - </sect3> - <sect3> - <title>Memory Manager Initialization</title> - <para> - Every DRM driver requires a memory manager which must be initialized at - load time. DRM currently contains two memory managers, the Translation - Table Manager (TTM) and the Graphics Execution Manager (GEM). - This document describes the use of the GEM memory manager only. See - <xref linkend="drm-memory-management"/> for details. - </para> - </sect3> - <sect3> - <title>Miscellaneous Device Configuration</title> - <para> - Another task that may be necessary for PCI devices during configuration - is mapping the video BIOS. On many devices, the VBIOS describes device - configuration, LCD panel timings (if any), and contains flags indicating - device state. Mapping the BIOS can be done using the pci_map_rom() call, - a convenience function that takes care of mapping the actual ROM, - whether it has been shadowed into memory (typically at address 0xc0000) - or exists on the PCI device in the ROM BAR. Note that after the ROM has - been mapped and any necessary information has been extracted, it should - be unmapped; on many devices, the ROM address decoder is shared with - other BARs, so leaving it mapped could cause undesired behaviour like - hangs or memory corruption. - <!--!Fdrivers/pci/rom.c pci_map_rom--> - </para> - </sect3> - </sect2> - <sect2> - <title>Bus-specific Device Registration and PCI Support</title> - <para> - A number of functions are provided to help with device registration. - The functions deal with PCI and platform devices respectively and are - only provided for historical reasons. These are all deprecated and - shouldn't be used in new drivers. Besides that there's a few - helpers for pci drivers. - </para> -!Edrivers/gpu/drm/drm_pci.c -!Edrivers/gpu/drm/drm_platform.c - </sect2> - </sect1> - - <!-- Internals: memory management --> - - <sect1 id="drm-memory-management"> - <title>Memory management</title> - <para> - Modern Linux systems require large amount of graphics memory to store - frame buffers, textures, vertices and other graphics-related data. Given - the very dynamic nature of many of that data, managing graphics memory - efficiently is thus crucial for the graphics stack and plays a central - role in the DRM infrastructure. - </para> - <para> - The DRM core includes two memory managers, namely Translation Table Maps - (TTM) and Graphics Execution Manager (GEM). TTM was the first DRM memory - manager to be developed and tried to be a one-size-fits-them all - solution. It provides a single userspace API to accommodate the need of - all hardware, supporting both Unified Memory Architecture (UMA) devices - and devices with dedicated video RAM (i.e. most discrete video cards). - This resulted in a large, complex piece of code that turned out to be - hard to use for driver development. - </para> - <para> - GEM started as an Intel-sponsored project in reaction to TTM's - complexity. Its design philosophy is completely different: instead of - providing a solution to every graphics memory-related problems, GEM - identified common code between drivers and created a support library to - share it. GEM has simpler initialization and execution requirements than - TTM, but has no video RAM management capabilities and is thus limited to - UMA devices. - </para> - <sect2> - <title>The Translation Table Manager (TTM)</title> - <para> - TTM design background and information belongs here. - </para> - <sect3> - <title>TTM initialization</title> - <warning><para>This section is outdated.</para></warning> - <para> - Drivers wishing to support TTM must fill out a drm_bo_driver - structure. The structure contains several fields with function - pointers for initializing the TTM, allocating and freeing memory, - waiting for command completion and fence synchronization, and memory |