diff options
Diffstat (limited to 'Documentation/gpu')
| -rw-r--r-- | Documentation/gpu/drm-internals.rst | 6 | ||||
| -rw-r--r-- | Documentation/gpu/drm-kms-helpers.rst | 26 | ||||
| -rw-r--r-- | Documentation/gpu/drm-kms.rst | 6 | ||||
| -rw-r--r-- | Documentation/gpu/drm-mm.rst | 2 | ||||
| -rw-r--r-- | Documentation/gpu/i915.rst | 1 | ||||
| -rw-r--r-- | Documentation/gpu/todo.rst | 82 | ||||
| -rw-r--r-- | Documentation/gpu/vgaarbiter.rst | 2 | ||||
| -rw-r--r-- | Documentation/gpu/vkms.rst | 2 |
8 files changed, 86 insertions, 41 deletions
diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 607f78f0f189..38afed24a75c 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -75,6 +75,12 @@ 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. +Module Initialization +--------------------- + +.. kernel-doc:: include/drm/drm_module.h + :doc: overview + Managing Ownership of the Framebuffer Aperture ---------------------------------------------- diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 5bb55ec1b9b5..c3ce91eecbc1 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -232,34 +232,34 @@ HDCP Helper Functions Reference Display Port Helper Functions Reference ======================================= -.. kernel-doc:: drivers/gpu/drm/drm_dp_helper.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp.c :doc: dp helpers -.. kernel-doc:: include/drm/drm_dp_helper.h +.. kernel-doc:: include/drm/dp/drm_dp_helper.h :internal: -.. kernel-doc:: drivers/gpu/drm/drm_dp_helper.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp.c :export: Display Port CEC Helper Functions Reference =========================================== -.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_cec.c :doc: dp cec helpers -.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_cec.c :export: Display Port Dual Mode Adaptor Helper Functions Reference ========================================================= -.. kernel-doc:: drivers/gpu/drm/drm_dp_dual_mode_helper.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_dual_mode_helper.c :doc: dp dual mode helpers -.. kernel-doc:: include/drm/drm_dp_dual_mode_helper.h +.. kernel-doc:: include/drm/dp/drm_dp_dual_mode_helper.h :internal: -.. kernel-doc:: drivers/gpu/drm/drm_dp_dual_mode_helper.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_dual_mode_helper.c :export: Display Port MST Helpers @@ -268,19 +268,19 @@ Display Port MST Helpers Overview -------- -.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c :doc: dp mst helper -.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c :doc: Branch device and port refcounting Functions Reference ------------------- -.. kernel-doc:: include/drm/drm_dp_mst_helper.h +.. kernel-doc:: include/drm/dp/drm_dp_mst_helper.h :internal: -.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c :export: Topology Lifetime Internals @@ -289,7 +289,7 @@ Topology Lifetime Internals These functions aren't exported to drivers, but are documented here to help make the MST topology helpers easier to understand -.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c :functions: drm_dp_mst_topology_try_get_mstb drm_dp_mst_topology_get_mstb drm_dp_mst_topology_put_mstb drm_dp_mst_topology_try_get_port drm_dp_mst_topology_get_port diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index d14bf1c35d7e..6f9c064fd323 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -423,12 +423,12 @@ Connector Functions Reference Writeback Connectors -------------------- -.. kernel-doc:: include/drm/drm_writeback.h - :internal: - .. kernel-doc:: drivers/gpu/drm/drm_writeback.c :doc: overview +.. kernel-doc:: include/drm/drm_writeback.h + :internal: + .. kernel-doc:: drivers/gpu/drm/drm_writeback.c :export: diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index e0538083a2c0..198bcc1affa1 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -8,7 +8,7 @@ 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. -The DRM core includes two memory managers, namely Translation Table Maps +The DRM core includes two memory managers, namely Translation Table Manager (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 diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index b7d801993bfa..bcaefc952764 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -539,6 +539,7 @@ GuC ABI .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h HuC --- diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index a1212b5b3026..127e76ee0b2d 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -222,7 +222,7 @@ Convert drivers to use drm_fbdev_generic_setup() Most drivers can use drm_fbdev_generic_setup(). Driver have to implement atomic modesetting and GEM vmap support. Historically, generic fbdev emulation expected the framebuffer in system memory or system-like memory. By employing -struct dma_buf_map, drivers with frambuffers in I/O memory can be supported +struct iosys_map, drivers with frambuffers in I/O memory can be supported as well. Contact: Maintainer of the driver you plan to convert @@ -234,13 +234,35 @@ Reimplement functions in drm_fbdev_fb_ops without fbdev A number of callback functions in drm_fbdev_fb_ops could benefit from being rewritten without dependencies on the fbdev module. Some of the -helpers could further benefit from using struct dma_buf_map instead of +helpers could further benefit from using struct iosys_map instead of raw pointers. Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter Level: Advanced +Benchmark and optimize blitting and format-conversion function +-------------------------------------------------------------- + +Drawing to dispay memory quickly is crucial for many applications' +performance. + +On at least x86-64, sys_imageblit() is significantly slower than +cfb_imageblit(), even though both use the same blitting algorithm and +the latter is written for I/O memory. It turns out that cfb_imageblit() +uses movl instructions, while sys_imageblit apparently does not. This +seems to be a problem with gcc's optimizer. DRM's format-conversion +helpers might be subject to similar issues. + +Benchmark and optimize fbdev's sys_() helpers and DRM's format-conversion +helpers. In cases that can be further optimized, maybe implement a different +algorithm. For micro-optimizations, use movl/movq instructions explicitly. +That might possibly require architecture-specific helpers (e.g., storel() +storeq()). + +Contact: Thomas Zimmermann <tzimmermann@suse.de> + +Level: Intermediate drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup ----------------------------------------------------------------- @@ -410,19 +432,19 @@ Contact: Emil Velikov, respective driver maintainers Level: Intermediate -Use struct dma_buf_map throughout codebase ------------------------------------------- +Use struct iosys_map throughout codebase +---------------------------------------- -Pointers to shared device memory are stored in struct dma_buf_map. Each +Pointers to shared device memory are stored in struct iosys_map. Each instance knows whether it refers to system or I/O memory. Most of the DRM-wide -interface have been converted to use struct dma_buf_map, but implementations +interface have been converted to use struct iosys_map, but implementations often still use raw pointers. -The task is to use struct dma_buf_map where it makes sense. +The task is to use struct iosys_map where it makes sense. -* Memory managers should use struct dma_buf_map for dma-buf-imported buffers. -* TTM might benefit from using struct dma_buf_map internally. -* Framebuffer copying and blitting helpers should operate on struct dma_buf_map. +* Memory managers should use struct iosys_map for dma-buf-imported buffers. +* TTM might benefit from using struct iosys_map internally. +* Framebuffer copying and blitting helpers should operate on struct iosys_map. Contact: Thomas Zimmermann <tzimmermann@suse.de>, Christian König, Daniel Vetter @@ -443,6 +465,21 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de> Level: Intermediate +Request memory regions in all drivers +------------------------------------- + +Go through all drivers and add code to request the memory regions that the +driver uses. This requires adding calls to request_mem_region(), +pci_request_region() or similar functions. Use helpers for managed cleanup +where possible. + +Drivers are pretty bad at doing this and there used to be conflicts among +DRM and fbdev drivers. Still, it's the correct thing to do. + +Contact: Thomas Zimmermann <tzimmermann@suse.de> + +Level: Starter + Core refactorings ================= @@ -460,8 +497,12 @@ This is a really varied tasks with lots of little bits and pieces: achieved by using an IPI to the local processor. * There's a massive confusion of different panic handlers. DRM fbdev emulation - helpers have one, but on top of that the fbcon code itself also has one. We - need to make sure that they stop fighting over each another. + helpers had their own (long removed), but on top of that the fbcon code itself + also has one. We need to make sure that they stop fighting over each other. + This is worked around by checking ``oops_in_progress`` at various entry points + into the DRM fbdev emulation helpers. A much cleaner approach here would be to + switch fbcon to the `threaded printk support + <https://lwn.net/Articles/800946/>`_. * ``drm_can_sleep()`` is a mess. It hides real bugs in normal operations and isn't a full solution for panic paths. We need to make sure that it only @@ -473,16 +514,15 @@ This is a really varied tasks with lots of little bits and pieces: even spinlocks (because NMI and hardirq can panic too). We need to either make sure to not call such paths, or trylock everything. Really tricky. -* For the above locking troubles reasons it's pretty much impossible to - attempt a synchronous modeset from panic handlers. The only thing we could - try to achive is an atomic ``set_base`` of the primary plane, and hope that - it shows up. Everything else probably needs to be delayed to some worker or - something else which happens later on. Otherwise it just kills the box - harder, prevent the panic from going out on e.g. netconsole. +* A clean solution would be an entirely separate panic output support in KMS, + bypassing the current fbcon support. See `[PATCH v2 0/3] drm: Add panic handling + <https://lore.kernel.org/dri-devel/20190311174218.51899-1-noralf@tronnes.org/>`_. -* There's also proposal for a simplied DRM console instead of the full-blown - fbcon and DRM fbdev emulation. Any kind of panic handling tricks should - obviously work for both console, in case we ever get kmslog merged. +* Encoding the actual oops and preceding dmesg in a QR might help with the + dread "important stuff scrolled away" problem. See `[RFC][PATCH] Oops messages + transfer using QR codes + <https://lore.kernel.org/lkml/1446217392-11981-1-git-send-email-alexandru.murtaza@intel.com/>`_ + for some example code that could be reused. Contact: Daniel Vetter diff --git a/Documentation/gpu/vgaarbiter.rst b/Documentation/gpu/vgaarbiter.rst index 339ed5fecd2e..bde3c0afb059 100644 --- a/Documentation/gpu/vgaarbiter.rst +++ b/Documentation/gpu/vgaarbiter.rst @@ -100,7 +100,7 @@ In-kernel interface .. kernel-doc:: include/linux/vgaarb.h :internal: -.. kernel-doc:: drivers/gpu/vga/vgaarb.c +.. kernel-doc:: drivers/pci/vgaarb.c :export: libpciaccess diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 941f0e7e5eef..9c873c3912cc 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -124,8 +124,6 @@ Add Plane Features There's lots of plane features we could add support for: -- Multiple overlay planes. [Good to get started] - - Clearing primary plane: clear primary plane before plane composition (at the start) for correctness of pixel blend ops. It also guarantees alpha channel is cleared in the target buffer for stable crc. [Good to get started] |