diff options
Diffstat (limited to 'Documentation/gpu')
-rw-r--r-- | Documentation/gpu/amdgpu.rst | 41 | ||||
-rw-r--r-- | Documentation/gpu/drm-uapi.rst | 114 | ||||
-rw-r--r-- | Documentation/gpu/i915.rst | 29 | ||||
-rw-r--r-- | Documentation/gpu/pl111.rst | 8 | ||||
-rw-r--r-- | Documentation/gpu/todo.rst | 46 |
5 files changed, 216 insertions, 22 deletions
diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst index 17112352f605..1f9ea8221f80 100644 --- a/Documentation/gpu/amdgpu.rst +++ b/Documentation/gpu/amdgpu.rst @@ -70,6 +70,15 @@ Interrupt Handling .. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c :internal: +IP Blocks +------------------ + +.. kernel-doc:: drivers/gpu/drm/amd/include/amd_shared.h + :doc: IP Blocks + +.. kernel-doc:: drivers/gpu/drm/amd/include/amd_shared.h + :identifiers: amd_ip_block_type amd_ip_funcs + AMDGPU XGMI Support =================== @@ -153,7 +162,7 @@ This section covers hwmon and power/thermal controls. HWMON Interfaces ---------------- -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c :doc: hwmon GPU sysfs Power State Interfaces @@ -164,48 +173,54 @@ GPU power controls are exposed via sysfs files. power_dpm_state ~~~~~~~~~~~~~~~ -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c :doc: power_dpm_state power_dpm_force_performance_level ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c :doc: power_dpm_force_performance_level pp_table ~~~~~~~~ -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c :doc: pp_table pp_od_clk_voltage ~~~~~~~~~~~~~~~~~ -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c :doc: pp_od_clk_voltage pp_dpm_* ~~~~~~~~ -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c :doc: pp_dpm_sclk pp_dpm_mclk pp_dpm_socclk pp_dpm_fclk pp_dpm_dcefclk pp_dpm_pcie pp_power_profile_mode ~~~~~~~~~~~~~~~~~~~~~ -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c :doc: pp_power_profile_mode -*_busy_percent -~~~~~~~~~~~~~~ +\*_busy_percent +~~~~~~~~~~~~~~~ -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c :doc: gpu_busy_percent -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c :doc: mem_busy_percent +gpu_metrics +~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: gpu_metrics + GPU Product Information ======================= @@ -233,7 +248,7 @@ serial_number unique_id --------- -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c :doc: unique_id GPU Memory Usage Information @@ -283,7 +298,7 @@ PCIe Accounting Information pcie_bw ------- -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c :doc: pcie_bw pcie_replay_count diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 496d8fcd4da0..7dce175f6d75 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -1,3 +1,5 @@ +.. Copyright 2020 DisplayLink (UK) Ltd. + =================== Userland interfaces =================== @@ -162,6 +164,116 @@ other hand, a driver requires shared state between clients which is visible to user-space and accessible beyond open-file boundaries, they cannot support render nodes. +Device Hot-Unplug +================= + +.. note:: + The following is the plan. Implementation is not there yet + (2020 May). + +Graphics devices (display and/or render) may be connected via USB (e.g. +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end +user is able to hot-unplug this kind of devices while they are being +used, and expects that the very least the machine does not crash. Any +damage from hot-unplugging a DRM device needs to be limited as much as +possible and userspace must be given the chance to handle it if it wants +to. Ideally, unplugging a DRM device still lets a desktop continue to +run, but that is going to need explicit support throughout the whole +graphics stack: from kernel and userspace drivers, through display +servers, via window system protocols, and in applications and libraries. + +Other scenarios that should lead to the same are: unrecoverable GPU +crash, PCI device disappearing off the bus, or forced unbind of a driver +from the physical device. + +In other words, from userspace perspective everything needs to keep on +working more or less, until userspace stops using the disappeared DRM +device and closes it completely. Userspace will learn of the device +disappearance from the device removed uevent, ioctls returning ENODEV +(or driver-specific ioctls returning driver-specific things), or open() +returning ENXIO. + +Only after userspace has closed all relevant DRM device and dmabuf file +descriptors and removed all mmaps, the DRM driver can tear down its +instance for the device that no longer exists. If the same physical +device somehow comes back in the mean time, it shall be a new DRM +device. + +Similar to PIDs, chardev minor numbers are not recycled immediately. A +new DRM device always picks the next free minor number compared to the +previous one allocated, and wraps around when minor numbers are +exhausted. + +The goal raises at least the following requirements for the kernel and +drivers. + +Requirements for KMS UAPI +------------------------- + +- KMS connectors must change their status to disconnected. + +- Legacy modesets and pageflips, and atomic commits, both real and + TEST_ONLY, and any other ioctls either fail with ENODEV or fake + success. + +- Pending non-blocking KMS operations deliver the DRM events userspace + is expecting. This applies also to ioctls that faked success. + +- open() on a device node whose underlying device has disappeared will + fail with ENXIO. + +- Attempting to create a DRM lease on a disappeared DRM device will + fail with ENODEV. Existing DRM leases remain and work as listed + above. + +Requirements for Render and Cross-Device UAPI +--------------------------------------------- + +- All GPU jobs that can no longer run must have their fences + force-signalled to avoid inflicting hangs on userspace. + The associated error code is ENODEV. + +- Some userspace APIs already define what should happen when the device + disappears (OpenGL, GL ES: `GL_KHR_robustness`_; `Vulkan`_: + VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this + behaviour the way they see best, e.g. returning failures in + driver-specific ioctls and handling those in userspace drivers, or + rely on uevents, and so on. + +- dmabuf which point to memory that has disappeared will either fail to + import with ENODEV or continue to be successfully imported if it would + have succeeded before the disappearance. See also about memory maps + below for already imported dmabufs. + +- Attempting to import a dmabuf to a disappeared device will either fail + with ENODEV or succeed if it would have succeeded without the + disappearance. + +- open() on a device node whose underlying device has disappeared will + fail with ENXIO. + +.. _GL_KHR_robustness: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_robustness.txt +.. _Vulkan: https://www.khronos.org/vulkan/ + +Requirements for Memory Maps +---------------------------- + +Memory maps have further requirements that apply to both existing maps +and maps created after the device has disappeared. If the underlying +memory disappears, the map is created or modified such that reads and +writes will still complete successfully but the result is undefined. +This applies to both userspace mmap()'d memory and memory pointed to by +dmabuf which might be mapped to other devices (cross-device dmabuf +imports). + +Raising SIGBUS is not an option, because userspace cannot realistically +handle it. Signal handlers are global, which makes them extremely +difficult to use correctly from libraries like those that Mesa produces. +Signal handlers are not composable, you can't have different handlers +for GPU1 and GPU2 from different vendors, and a third handler for +mmapped regular files. Threads cause additional pain with signal +handling as well. + .. _drm_driver_ioctl: IOCTL Support on Device Nodes @@ -199,7 +311,7 @@ EPERM/EACCES: difference between EACCES and EPERM. ENODEV: - The device is not (yet) present or fully initialized. + The device is not present anymore or is not yet fully initialized. EOPNOTSUPP: Feature (like PRIME, modesetting, GEM) is not supported by the driver. diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 33cc6ddf8f64..cff1f154b473 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -636,15 +636,36 @@ i915 Perf Observation Architecture Stream .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c :functions: i915_oa_poll_wait -All i915 Perf Internals ------------------------ +Other i915 Perf Internals +------------------------- -This section simply includes all currently documented i915 perf internals, in -no particular order, but may include some more minor utilities or platform +This section simply includes all other currently documented i915 perf internals, +in no particular order, but may include some more minor utilities or platform specific details than found in the more high-level sections. .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c :internal: + :no-identifiers: + i915_perf_init + i915_perf_fini + i915_perf_register + i915_perf_unregister + i915_perf_open_ioctl + i915_perf_release + i915_perf_add_config_ioctl + i915_perf_remove_config_ioctl + read_properties_unlocked + i915_perf_open_ioctl_locked + i915_perf_destroy_locked + i915_perf_read i915_perf_ioctl + i915_perf_enable_locked + i915_perf_disable_locked + i915_perf_poll i915_perf_poll_locked + i915_oa_stream_init i915_oa_read + i915_oa_stream_enable + i915_oa_stream_disable + i915_oa_wait_unlocked + i915_oa_poll_wait Style ===== diff --git a/Documentation/gpu/pl111.rst b/Documentation/gpu/pl111.rst index 9b03736d33dd..6d9a1b59a545 100644 --- a/Documentation/gpu/pl111.rst +++ b/Documentation/gpu/pl111.rst @@ -1,6 +1,6 @@ -========================================== - drm/pl111 ARM PrimeCell PL111 CLCD Driver -========================================== +==================================================== + drm/pl111 ARM PrimeCell PL110 and PL111 CLCD Driver +==================================================== .. kernel-doc:: drivers/gpu/drm/pl111/pl111_drv.c - :doc: ARM PrimeCell PL111 CLCD Driver + :doc: ARM PrimeCell PL110 and PL111 CLCD Driver diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 7969f106877d..b0ea17da8ff6 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -403,6 +403,52 @@ Contact: Emil Velikov, respective driver maintainers Level: Intermediate +Plumb drm_atomic_state all over +------------------------------- + +Currently various atomic functions take just a single or a handful of +object states (eg. plane state). While that single object state can +suffice for some simple cases, we often have to dig out additional +object states for dealing with various dependencies between the individual +objects or the hardware they represent. The process of digging out the +additional states is rather non-intuitive and error prone. + +To fix that most functions should rather take the overall +drm_atomic_state as one of their parameters. The other parameters +would generally be the object(s) we mainly want to interact with. + +For example, instead of + +.. code-block:: c + + int (*atomic_check)(struct drm_plane *plane, struct drm_plane_state *state); + +we would have something like + +.. code-block:: c + + int (*atomic_check)(struct drm_plane *plane, struct drm_atomic_state *state); + +The implementation can then trivially gain access to any required object +state(s) via drm_atomic_get_plane_state(), drm_atomic_get_new_plane_state(), +drm_atomic_get_old_plane_state(), and their equivalents for +other object types. + +Additionally many drivers currently access the object->state pointer +directly in their commit functions. That is not going to work if we +eg. want to allow deeper commit pipelines as those pointers could +then point to the states corresponding to a future commit instead of +the current commit we're trying to process. Also non-blocking commits +execute locklessly so there are serious concerns with dereferencing +the object->state pointers without holding the locks that protect them. +Use of drm_atomic_get_new_plane_state(), drm_atomic_get_old_plane_state(), +etc. avoids these problems as well since they relate to a specific +commit via the passed in drm_atomic_state. + +Contact: Ville Syrjälä, Daniel Vetter + +Level: Intermediate + Core refactorings ================= |