Merge tag 'drm-next-2020-08-06' of git://anongit.freedesktop.org/drm/drm
Pull drm updates from Dave Airlie: "New xilinx displayport driver, AMD support for two new GPUs (more header files), i915 initial support for RocketLake and some work on their DG1 (discrete chip). The core also grew some lockdep annotations to try and constrain what drivers do with dma-fences, and added some documentation on why the idea of indefinite fences doesn't work. The long list is below. I do have some fixes trees outstanding, but I'll follow up with those later. core: - add user def flag to cmd line modes - dma_fence_wait added might_sleep - dma-fence lockdep annotations - indefinite fences are bad documentation - gem CMA functions used in more drivers - struct mutex removal - more drm_ debug macro usage - set/drop master api fixes - fix for drm/mm hole size comparison - drm/mm remove invalid entry optimization - optimise drm/mm hole handling - VRR debugfs added - uncompressed AFBC modifier support - multiple display id blocks in EDID - multiple driver sg handling fixes - __drm_atomic_helper_crtc_reset in all drivers - managed vram helpers ttm: - ttm_mem_reg handling cleanup - remove bo offset field - drop CMA memtype flag - drop mappable flag xilinx: - New Xilinx ZynqMP DisplayPort Subsystem driver nouveau: - add CRC support - start using NVIDIA published class header files - convert all push buffer emission to new macros - Proper push buffer space management for EVO/NVD channels. - firmware loading fixes - 2MiB system memory pages support on Pascal and newer vkms: - larger cursor support i915: - Rocketlake platform enablement - Early DG1 enablement - Numerous GEM refactorings - DP MST fixes - FBC, PSR, Cursor, Color, Gamma fixes - TGL, RKL, EHL workaround updates - TGL 8K display support fixes - SDVO/HDMI/DVI fixes amdgpu: - Initial support for Sienna Cichlid GPU - Initial support for Navy Flounder GPU - SI UVD/VCE support - expose rotation property - Add support for unique id on Arcturus - Enable runtime PM on vega10 boards that support BACO - Skip BAR resizing if the bios already did id - Major swSMU code cleanup - Fixes for DCN bandwidth calculations amdkfd: - Track SDMA usage per process - SMI events interface radeon: - Default to on chip GART for AGP boards on all arches - Runtime PM reference count fixes msm: - headers regenerated causing churn - a650/a640 display and GPU enablement - dpu dither support for 6bpc panels - dpu cursor fix - dsi/mdp5 enablement for sdm630/sdm636/sdm66 tegra: - video capture prep support - reflection support mediatek: - convert mtk_dsi to bridge API meson: - FBC support sun4i: - iommu support rockchip: - register locking fix - per-pixel alpha support PX30 VOP mgag200: - ported to simple and shmem helpers - device init cleanups - use managed pci functions - dropped hw cursor support ast: - use managed pci functions - use managed VRAM helpers - rework cursor support malidp: - dev_groups support hibmc: - refactor hibmc_drv_vdac: vc4: - create TXP CRTC imx: - error path fixes and cleanups etnaviv: - clock handling and error handling cleanups - use pin_user_pages" * tag 'drm-next-2020-08-06' of git://anongit.freedesktop.org/drm/drm: (1747 commits) drm/msm: use kthread_create_worker instead of kthread_run drm/msm/mdp5: Add MDP5 configuration for SDM636/660 drm/msm/dsi: Add DSI configuration for SDM660 drm/msm/mdp5: Add MDP5 configuration for SDM630 drm/msm/dsi: Add phy configuration for SDM630/636/660 drm/msm/a6xx: add A640/A650 hwcg drm/msm/a6xx: hwcg tables in gpulist drm/msm/dpu: add SM8250 to hw catalog drm/msm/dpu: add SM8150 to hw catalog drm/msm/dpu: intf timing path for displayport drm/msm/dpu: set missing flush bits for INTF_2 and INTF_3 drm/msm/dpu: don't use INTF_INPUT_CTRL feature on sdm845 drm/msm/dpu: move some sspp caps to dpu_caps drm/msm/dpu: update UBWC config for sm8150 and sm8250 drm/msm/dpu: use right setup_blend_config for sm8150 and sm8250 drm/msm/a6xx: set ubwc config for A640 and A650 drm/msm/adreno: un-open-code some packets drm/msm: sync generated headers drm/msm/a6xx: add build_bw_table for A640/A650 drm/msm/a6xx: fix crashstate capture for A650 ...
This commit is contained in:
Linus Torvalds
@@ -100,11 +100,11 @@ CPU Access to DMA Buffer Objects
|
||||
.. kernel-doc:: drivers/dma-buf/dma-buf.c
|
||||
:doc: cpu access
|
||||
|
||||
Fence Poll Support
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
Implicit Fence Poll Support
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. kernel-doc:: drivers/dma-buf/dma-buf.c
|
||||
:doc: fence polling
|
||||
:doc: implicit fence polling
|
||||
|
||||
Kernel Functions and Structures Reference
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@@ -133,6 +133,18 @@ DMA Fences
|
||||
.. kernel-doc:: drivers/dma-buf/dma-fence.c
|
||||
:doc: DMA fences overview
|
||||
|
||||
DMA Fence Cross-Driver Contract
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. kernel-doc:: drivers/dma-buf/dma-fence.c
|
||||
:doc: fence cross-driver contract
|
||||
|
||||
DMA Fence Signalling Annotations
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. kernel-doc:: drivers/dma-buf/dma-fence.c
|
||||
:doc: fence signalling annotation
|
||||
|
||||
DMA Fences Functions Reference
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@@ -166,3 +178,73 @@ DMA Fence uABI/Sync File
|
||||
.. kernel-doc:: include/linux/sync_file.h
|
||||
:internal:
|
||||
|
||||
Indefinite DMA Fences
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
At various times &dma_fence with an indefinite time until dma_fence_wait()
|
||||
finishes have been proposed. Examples include:
|
||||
|
||||
* Future fences, used in HWC1 to signal when a buffer isn't used by the display
|
||||
any longer, and created with the screen update that makes the buffer visible.
|
||||
The time this fence completes is entirely under userspace's control.
|
||||
|
||||
* Proxy fences, proposed to handle &drm_syncobj for which the fence has not yet
|
||||
been set. Used to asynchronously delay command submission.
|
||||
|
||||
* Userspace fences or gpu futexes, fine-grained locking within a command buffer
|
||||
that userspace uses for synchronization across engines or with the CPU, which
|
||||
are then imported as a DMA fence for integration into existing winsys
|
||||
protocols.
|
||||
|
||||
* Long-running compute command buffers, while still using traditional end of
|
||||
batch DMA fences for memory management instead of context preemption DMA
|
||||
fences which get reattached when the compute job is rescheduled.
|
||||
|
||||
Common to all these schemes is that userspace controls the dependencies of these
|
||||
fences and controls when they fire. Mixing indefinite fences with normal
|
||||
in-kernel DMA fences does not work, even when a fallback timeout is included to
|
||||
protect against malicious userspace:
|
||||
|
||||
* Only the kernel knows about all DMA fence dependencies, userspace is not aware
|
||||
of dependencies injected due to memory management or scheduler decisions.
|
||||
|
||||
* Only userspace knows about all dependencies in indefinite fences and when
|
||||
exactly they will complete, the kernel has no visibility.
|
||||
|
||||
Furthermore the kernel has to be able to hold up userspace command submission
|
||||
for memory management needs, which means we must support indefinite fences being
|
||||
dependent upon DMA fences. If the kernel also support indefinite fences in the
|
||||
kernel like a DMA fence, like any of the above proposal would, there is the
|
||||
potential for deadlocks.
|
||||
|
||||
.. kernel-render:: DOT
|
||||
:alt: Indefinite Fencing Dependency Cycle
|
||||
:caption: Indefinite Fencing Dependency Cycle
|
||||
|
||||
digraph "Fencing Cycle" {
|
||||
node [shape=box bgcolor=grey style=filled]
|
||||
kernel [label="Kernel DMA Fences"]
|
||||
userspace [label="userspace controlled fences"]
|
||||
kernel -> userspace [label="memory management"]
|
||||
userspace -> kernel [label="Future fence, fence proxy, ..."]
|
||||
|
||||
{ rank=same; kernel userspace }
|
||||
}
|
||||
|
||||
This means that the kernel might accidentally create deadlocks
|
||||
through memory management dependencies which userspace is unaware of, which
|
||||
randomly hangs workloads until the timeout kicks in. Workloads, which from
|
||||
userspace's perspective, do not contain a deadlock. In such a mixed fencing
|
||||
architecture there is no single entity with knowledge of all dependencies.
|
||||
Thefore preventing such deadlocks from within the kernel is not possible.
|
||||
|
||||
The only solution to avoid dependencies loops is by not allowing indefinite
|
||||
fences in the kernel. This means:
|
||||
|
||||
* No future fences, proxy fences or userspace fences imported as DMA fences,
|
||||
with or without a timeout.
|
||||
|
||||
* No DMA fences that signal end of batchbuffer for command submission where
|
||||
userspace is allowed to use userspace fencing or long running compute
|
||||
workloads. This also means no implicit fencing for shared buffers in these
|
||||
cases.
|
||||
|
||||
@@ -86,7 +86,9 @@ The details of these operations are:
|
||||
- interleaved_dma: This is common to Slave as well as M2M clients. For slave
|
||||
address of devices' fifo could be already known to the driver.
|
||||
Various types of operations could be expressed by setting
|
||||
appropriate values to the 'dma_interleaved_template' members.
|
||||
appropriate values to the 'dma_interleaved_template' members. Cyclic
|
||||
interleaved DMA transfers are also possible if supported by the channel by
|
||||
setting the DMA_PREP_REPEAT transfer flag.
|
||||
|
||||
A non-NULL return of this transfer API represents a "descriptor" for
|
||||
the given transaction.
|
||||
|
||||
@@ -239,6 +239,27 @@ Currently, the types available are:
|
||||
want to transfer a portion of uncompressed data directly to the
|
||||
display to print it
|
||||
|
||||
- DMA_REPEAT
|
||||
|
||||
- The device supports repeated transfers. A repeated transfer, indicated by
|
||||
the DMA_PREP_REPEAT transfer flag, is similar to a cyclic transfer in that
|
||||
it gets automatically repeated when it ends, but can additionally be
|
||||
replaced by the client.
|
||||
|
||||
- This feature is limited to interleaved transfers, this flag should thus not
|
||||
be set if the DMA_INTERLEAVE flag isn't set. This limitation is based on
|
||||
the current needs of DMA clients, support for additional transfer types
|
||||
should be added in the future if and when the need arises.
|
||||
|
||||
- DMA_LOAD_EOT
|
||||
|
||||
- The device supports replacing repeated transfers at end of transfer (EOT)
|
||||
by queuing a new transfer with the DMA_PREP_LOAD_EOT flag set.
|
||||
|
||||
- Support for replacing a currently running transfer at another point (such
|
||||
as end of burst instead of end of transfer) will be added in the future
|
||||
based on DMA clients needs, if and when the need arises.
|
||||
|
||||
These various types will also affect how the source and destination
|
||||
addresses change over time.
|
||||
|
||||
@@ -531,6 +552,34 @@ DMA_CTRL_REUSE
|
||||
writes for which the descriptor should be in different format from
|
||||
normal data descriptors.
|
||||
|
||||
- DMA_PREP_REPEAT
|
||||
|
||||
- If set, the transfer will be automatically repeated when it ends until a
|
||||
new transfer is queued on the same channel with the DMA_PREP_LOAD_EOT flag.
|
||||
If the next transfer to be queued on the channel does not have the
|
||||
DMA_PREP_LOAD_EOT flag set, the current transfer will be repeated until the
|
||||
client terminates all transfers.
|
||||
|
||||
- This flag is only supported if the channel reports the DMA_REPEAT
|
||||
capability.
|
||||
|
||||
- DMA_PREP_LOAD_EOT
|
||||
|
||||
- If set, the transfer will replace the transfer currently being executed at
|
||||
the end of the transfer.
|
||||
|
||||
- This is the default behaviour for non-repeated transfers, specifying
|
||||
DMA_PREP_LOAD_EOT for non-repeated transfers will thus make no difference.
|
||||
|
||||
- When using repeated transfers, DMA clients will usually need to set the
|
||||
DMA_PREP_LOAD_EOT flag on all transfers, otherwise the channel will keep
|
||||
repeating the last repeated transfer and ignore the new transfers being
|
||||
queued. Failure to set DMA_PREP_LOAD_EOT will appear as if the channel was
|
||||
stuck on the previous transfer.
|
||||
|
||||
- This flag is only supported if the channel reports the DMA_LOAD_EOT
|
||||
capability.
|
||||
|
||||
General Design Notes
|
||||
====================
|
||||
|
||||
|
||||
Reference in New Issue
Block a user