Documentation/gpu/todo.rst

11 ----------
18 subsystem, or some specific GPU/display graphics knowledge. For debugging issue
27 refactorings already and are an expert in the specific area
29 Subsystem-wide refactorings
33 ---------------------------------------------
45 --------------------------------------------------
53 non-converted driver.  The "Atomic mode setting design overview" series [2]_
60   .. [1] https://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html
69 ---------------------------------------------------------
75 avoid confusion - the other helpers in that file are all deprecated legacy
83 ----------------------------------
88 - drm_plane_helper_funcs->atomic_check gets called for enabled or disabled
92   into the drm_plane_funcs->atomic_duplicate_state functions.
94 - Once that's done, helpers could stop calling ->atomic_check for disabled
97 - Then we could go through all the drivers and remove the more-or-less confused
98   checks for plane_state->fb and plane_state->crtc.
105 ----------------------------------------------------
108 nonblocking commits, and every driver had to hand-roll them. This is fixed
124 -----------------------
147 -----------------------
152 a bit too severe. So there's some follow-up work to adjust the function
159   drivers explicitly so that the legacy-on-atomic functions can use them.
176 Get rid of dev->struct_mutex from GEM drivers
177 ---------------------------------------------
179 ``dev->struct_mutex`` is the Big DRM Lock from legacy days and infested
189 For drivers that need ``struct_mutex`` it should be replaced with a driver-
193 performance-critical drivers it might also be better to go with a more
194 fine-grained per-buffer object and per-context lockings scheme. Currently only
202 ---------------------------------------------
204 Many drivers have their own per-object locking scheme, usually using
209 To solve this we need one standard per-object locking mechanism, which is
211 other driver specific per-object locks removed. The problem is that rolling out
218 ------------------------------------------------------------
224 those drivers back to using drm-formatted specific log messages.
227 sure your work will be merged - not everyone agrees that the DRM dmesg macros
235 ----------------------------------------------------
239 drm_mode_config_helper_suspend/resume(). Also there's still open-coded version
247 -------------------------------------------------------
258 Benchmark and optimize blitting and format-conversion function
259 --------------------------------------------------------------
264 On at least x86-64, sys_imageblit() is significantly slower than
268 seems to be a problem with gcc's optimizer. DRM's format-conversion
271 Benchmark and optimize fbdev's sys_() helpers and DRM's format-conversion
273 algorithm. For micro-optimizations, use movl/movq instructions explicitly.
274 That might possibly require architecture-specific helpers (e.g., storel()
282 -----------------------------------------------------------------
285 Various hold-ups:
287 - Need to switch over to the generic dirty tracking code using
290 - Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb
293 - Need to switch to drm_gem_fb_create(), as now drm_gem_fb_create() checks for
296 - Many drivers subclass drm_framebuffer, we'd need a embedding compatible
305 ---------------------------
307 The defio support code in the fbdev core has some very specific requirements,
315 everything after it has done the write-protect/mkwrite trickery:
317 - In the drm_fbdev_fb_mmap helper, if we need defio, change the
318   default page prots to write-protected with something like this::
320       vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot);
322 - Set the mkwrite and fsync callbacks with similar implementions to the core
327 - Track the dirty pages in a separate structure (bitfield with one bit per page
337 -----------------------------------
339 - For most connectors it's a no-op to call drm_connector_register/unregister
343 - For dp drivers it's a bit more a mess, since we need the connector to be
351 ----------------------------
357 - Rework drivers to no longer use the load/unload callbacks, directly coding the
360 - Once all drivers are converted, remove the load/unload callbacks.
367 ---------------------------------------------------------------
381 --------------------------------------------
385 driver specific properties should not be used.
393 - audio (amdgpu, intel, gma500, radeon)
394 - brightness, contrast, etc (armada, nouveau) - overlay only (?)
395 - broadcast rgb (gma500, intel)
396 - colorkey (armada, nouveau, rcar) - overlay only (?)
397 - dither (amdgpu, nouveau, radeon) - varies across drivers
398 - underscan family (amdgpu, radeon, nouveau)
401 - colorspace (sti)
402 - tv format names, enhancements (gma500, intel)
403 - tv overscan, margins, etc. (gma500, intel)
404 - zorder (omapdrm) - same as zpos (?)
412 ----------------------------------------
415 instance knows whether it refers to system or I/O memory. Most of the DRM-wide
421 * Memory managers should use struct iosys_map for dma-buf-imported buffers.
430 --------------------------------------------------------------------------------------
445 -------------------------------------
460 ---------------------------------------
472 Remove disable/unprepare in remove/shutdown in panel-simple and panel-edp
473 -------------------------------------------------------------------------
475 As of commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in
477 double-calls prepare/enable/disable/unprepare. Eventually that should probably
481 drm_panel core when using panel-simple and panel-edp. Since those panel
483 make an extra effort to disable/unprepare the panel themsevles at shutdown
484 time. Specifically we could still encounter those warnings if the panel
488 device links to ensure that the panel gets shutdown() after the DRM modeset
492 calls to disable/unprepare in remove/shutdown in panel-simple and panel-edp
500 -------------------------------------------------
503 non-intuitive because, if there are errors, they return out of the *caller's*
522 ------------------------
553   <https://lore.kernel.org/dri-devel/20190311174218.51899-1-noralf@tronnes.org/>`_.
558   <https://lore.kernel.org/lkml/1446217392-11981-1-git-send-email-alexandru.murtaza@intel.com/>`_
566 ----------------------------
570 - Convert drivers to support the drm_debugfs_add_files() function instead of
573 - Improve late-register debugfs by rolling out the same debugfs pre-register
577 - We probably want to have some support for debugfs files on crtc/connectors and
580   ->show() functions should obviously give you a pointer to the right object.
582 - The drm_driver->debugfs_init hooks we have is just an artifact of the old
587   this (together with the drm_minor->drm_device move) would allow us to remove
595 ---------------------
599 - Cleanup up the various ->destroy callbacks, which often are all the same
602 - Lots of drivers erroneously allocate DRM modeset objects using devm_kzalloc,
603   which results in use-after free issues on driver unload. This can be serious
615 Remove automatic page mapping from dma-buf importing
616 ----------------------------------------------------
618 When importing dma-bufs, the dma-buf and PRIME frameworks automatically map
626 buffer-sharing code. Fixing this is a bit more involved, since the import/export
640 --------------------------------------------------------------
642 The `KUnit <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_
646 A good candidate for the first unit tests are the format-conversion helpers in
654 ---------------------------------------------
671 ----------------------
677 Make KMS tests in i-g-t generic
678 -------------------------------
681 including tons of testcases for corner-cases in the modesetting API. It would
682 be awesome if those tests (at least the ones not relying on Intel-specific GEM
685 Basic work to run i-g-t tests on non-i915 is done, what's now missing is mass-
688 the non-i915 specific modeset tests.
693 ---------------------------------
702 ---------------------
716 Driver Specific
720 ---------------------
736 - [v6,8/8] drm/client: Hack: Add bootsplash example
739 - [RFC PATCH v2 00/13] Kernel based bootsplash
740   https://lore.kernel.org/r/20171213194755.3409-1-mstaudt@suse.de
750 (ACPI) video, vendor specific and others. As well as direct/native (PWM)
760 be 1 (internal) panel on a system.
768    will need to be done to get the output <-> backlight device mapping
772 a different type of control. E.g. one panel needs ACPI video backlight control,
778 work. A possible solution here would be to pass a device and connector-name
786 panel is active (iow which way the mux between the GPU and the panels
788 assumes a single panel though. It picks only 1 of the 2 backlight devices
792 to assume a single panel.
795 /sys/class/backlight devices for a single panel (on a single GPU laptop),
806 being able to map a sysfs backlight device to a specific connector. Any
817 Drivers that do per-buffer uploads, need a buffer damage handling (rather than
818 frame damage like drivers that do per-plane or per-CRTC uploads), but there is
822 framebuffer attached to a plane has changed since the last page-flip. Drivers
828 do per-buffer uploads.
841 ----------------------------
844 become obsolete, but some still provides good(-enough) framebuffers. The
850 existing hardware. The new driver's call-back functions are filled from
853 More complex fbdev drivers can be refactored step-by-step into a DRM