diff options
Diffstat (limited to 'Documentation/gpu/todo.rst')
| -rw-r--r-- | Documentation/gpu/todo.rst | 239 |
1 files changed, 150 insertions, 89 deletions
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 159a4aba49e6..6792fa9b6b6b 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -7,27 +7,24 @@ TODO list This section contains a list of smaller janitorial tasks in the kernel DRM graphics subsystem useful as newbie projects. Or for slow rainy days. -Subsystem-wide refactorings -=========================== - -De-midlayer drivers -------------------- +Difficulty +---------- -With the recent ``drm_bus`` cleanup patches for 3.17 it is no longer required -to have a ``drm_bus`` structure set up. Drivers can directly set up the -``drm_device`` structure instead of relying on bus methods in ``drm_usb.c`` -and ``drm_pci.c``. The goal is to get rid of the driver's ``->load`` / -``->unload`` callbacks and open-code the load/unload sequence properly, using -the new two-stage ``drm_device`` setup/teardown. +To make it easier task are categorized into different levels: -Once all existing drivers are converted we can also remove those bus support -files for USB and platform devices. +Starter: Good tasks to get started with the DRM subsystem. -All you need is a GPU for a non-converted driver (currently almost all of -them, but also all the virtual ones used by KVM, so everyone qualifies). +Intermediate: Tasks which need some experience with working in the DRM +subsystem, or some specific GPU/display graphics knowledge. For debugging issue +it's good to have the relevant hardware (or a virtual driver set up) available +for testing. -Contact: Daniel Vetter, Thierry Reding, respective driver maintainers +Advanced: Tricky tasks that need fairly good understanding of the DRM subsystem +and graphics topics. Generally need the relevant hardware for development and +testing. +Subsystem-wide refactorings +=========================== Remove custom dumb_map_offset implementations --------------------------------------------- @@ -39,6 +36,8 @@ implementations), and then remove it. Contact: Daniel Vetter, respective driver maintainers +Level: Intermediate + Convert existing KMS drivers to atomic modesetting -------------------------------------------------- @@ -57,6 +56,8 @@ do by directly using the new atomic helper driver callbacks. Contact: Daniel Vetter, respective driver maintainers +Level: Advanced + Clean up the clipped coordination confusion around planes --------------------------------------------------------- @@ -69,6 +70,8 @@ helpers. Contact: Ville Syrjälä, Daniel Vetter, driver maintainers +Level: Advanced + Convert early atomic drivers to async commit helpers ---------------------------------------------------- @@ -82,6 +85,8 @@ events for atomic commits correctly. But fixing these bugs is good anyway. Contact: Daniel Vetter, respective driver maintainers +Level: Advanced + Fallout from atomic KMS ----------------------- @@ -110,6 +115,8 @@ interfaces to fix these issues: Contact: Daniel Vetter +Level: Intermediate + Get rid of dev->struct_mutex from GEM drivers --------------------------------------------- @@ -133,6 +140,8 @@ fine-grained per-buffer object and per-context lockings scheme. Currently only t Contact: Daniel Vetter, respective driver maintainers +Level: Advanced + Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent ---------------------------------------------------------------------------- @@ -148,6 +157,8 @@ are better. Contact: Sean Paul, Maintainer of the driver you plan to convert +Level: Starter + Convert drivers to use simple modeset suspend/resume ---------------------------------------------------- @@ -158,6 +169,8 @@ of the atomic suspend/resume code in older atomic modeset drivers. Contact: Maintainer of the driver you plan to convert +Level: Intermediate + Convert drivers to use drm_fb_helper_fbdev_setup/teardown() ----------------------------------------------------------- @@ -176,23 +189,27 @@ probably use drm_fb_helper_fbdev_teardown(). Contact: Maintainer of the driver you plan to convert +Level: Intermediate + Clean up mmap forwarding ------------------------ A lot of drivers forward gem mmap calls to dma-buf mmap for imported buffers. And also a lot of them forward dma-buf mmap to the gem mmap implementations. -Would be great to refactor this all into a set of small common helpers. +There's drm_gem_prime_mmap() for this now, but still needs to be rolled out. Contact: Daniel Vetter +Level: Intermediate + Generic fbdev defio support --------------------------- The defio support code in the fbdev core has some very specific requirements, -which means drivers need to have a special framebuffer for fbdev. Which prevents -us from using the generic fbdev emulation code everywhere. The main issue is -that it uses some fields in struct page itself, which breaks shmem gem objects -(and other things). +which means drivers need to have a special framebuffer for fbdev. The main +issue is that it uses some fields in struct page itself, which breaks shmem +gem objects (and other things). To support defio, affected drivers require +the use of a shadow buffer, which may add CPU and memory overhead. Possible solution would be to write our own defio mmap code in the drm fbdev emulation. It would need to fully wrap the existing mmap ops, forwarding @@ -215,14 +232,7 @@ Might be good to also have some igt testcases for this. Contact: Daniel Vetter, Noralf Tronnes -Put a reservation_object into drm_gem_object --------------------------------------------- - -This would remove the need for the ->gem_prime_res_obj callback. It would also -allow us to implement generic helpers for waiting for a bo, allowing for quite a -bit of refactoring in the various wait ioctl implementations. - -Contact: Daniel Vetter +Level: Advanced idr_init_base() --------------- @@ -234,12 +244,7 @@ efficient. Contact: Daniel Vetter -Defaults for .gem_prime_import and export ------------------------------------------ - -Most drivers don't need to set drm_driver->gem_prime_import and -->gem_prime_export now that drm_gem_prime_import() and drm_gem_prime_export() -are the default. +Level: Starter struct drm_gem_object_funcs --------------------------- @@ -247,6 +252,12 @@ struct drm_gem_object_funcs GEM objects can now have a function table instead of having the callbacks on the DRM driver struct. This is now the preferred way and drivers can be moved over. +We also need a 2nd version of the CMA define that doesn't require the +vmapping to be present (different hook for prime importing). Plus this needs to +be rolled out to all drivers using their own implementations, too. + +Level: Intermediate + Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate --------------------------------------------------------- @@ -262,6 +273,8 @@ As a reference, take a look at the conversions already completed in drm core. Contact: Sean Paul, respective driver maintainers +Level: Starter + Rename CMA helpers to DMA helpers --------------------------------- @@ -272,6 +285,9 @@ no one knows what that means) since underneath they just use dma_alloc_coherent. Contact: Laurent Pinchart, Daniel Vetter +Level: Intermediate (mostly because it is a huge tasks without good partial +milestones, not technically itself that challenging) + Convert direct mode.vrefresh accesses to use drm_mode_vrefresh() ---------------------------------------------------------------- @@ -290,6 +306,8 @@ drm_display_mode to avoid future use. Contact: Sean Paul +Level: Starter + Remove drm_display_mode.hsync ----------------------------- @@ -300,33 +318,41 @@ it to use drm_mode_hsync() instead. Contact: Sean Paul -Core refactorings -================= +Level: Starter -Clean up the DRM header mess ----------------------------- +drm_fb_helper tasks +------------------- -The DRM subsystem originally had only one huge global header, ``drmP.h``. This -is now split up, but many source files still include it. The remaining part of -the cleanup work here is to replace any ``#include <drm/drmP.h>`` by only the -headers needed (and fixing up any missing pre-declarations in the headers). +- drm_fb_helper_restore_fbdev_mode_unlocked() should call restore_fbdev_mode() + not the _force variant so it can bail out if there is a master. But first + these igt tests need to be fixed: kms_fbcon_fbt@psr and + kms_fbcon_fbt@psr-suspend. -In the end no .c file should need to include ``drmP.h`` anymore. +- The max connector argument for drm_fb_helper_init() and + drm_fb_helper_fbdev_setup() isn't used anymore and can be removed. -Contact: Daniel Vetter +- The helper doesn't keep an array of connectors anymore so these can be + removed: drm_fb_helper_single_add_all_connectors(), + drm_fb_helper_add_one_connector() and drm_fb_helper_remove_one_connector(). -Add missing kerneldoc for exported functions --------------------------------------------- +Level: Intermediate -The DRM reference documentation is still lacking kerneldoc in a few areas. The -task would be to clean up interfaces like moving functions around between -files to better group them and improving the interfaces like dropping return -values for functions that never fail. Then write kerneldoc for all exported -functions and an overview section and integrate it all into the drm book. +connector register/unregister fixes +----------------------------------- -See https://dri.freedesktop.org/docs/drm/ for what's there already. +- For most connectors it's a no-op to call drm_connector_register/unregister + directly from driver code, drm_dev_register/unregister take care of this + already. We can remove all of them. -Contact: Daniel Vetter +- For dp drivers it's a bit more a mess, since we need the connector to be + registered when calling drm_dp_aux_register. Fix this by instead calling + drm_dp_aux_init, and moving the actual registering into a late_register + callback as recommended in the kerneldoc. + +Level: Intermediate + +Core refactorings +================= Make panic handling work ------------------------ @@ -367,6 +393,8 @@ This is a really varied tasks with lots of little bits and pieces: Contact: Daniel Vetter +Level: Advanced + Clean up the debugfs support ---------------------------- @@ -391,8 +419,13 @@ There's a bunch of issues with it: this (together with the drm_minor->drm_device move) would allow us to remove debugfs_init. +- Drop the return code and error checking from all debugfs functions. Greg KH is + working on this already. + Contact: Daniel Vetter +Level: Intermediate + KMS cleanups ------------ @@ -408,6 +441,8 @@ Some of these date from the very introduction of KMS in 2008 ... end, for which we could add drm_*_cleanup_kfree(). And then there's the (for historical reasons) misnamed drm_primary_helper_destroy() function. +Level: Intermediate + Better Testing ============== @@ -416,6 +451,8 @@ Enable trinity for DRM And fix up the fallout. Should be really interesting ... +Level: Advanced + Make KMS tests in i-g-t generic ------------------------------- @@ -429,6 +466,8 @@ converting things over. For modeset tests we also first need a bit of infrastructure to use dumb buffers for untiled buffers, to be able to run all the non-i915 specific modeset tests. +Level: Advanced + Extend virtual test driver (VKMS) --------------------------------- @@ -438,42 +477,25 @@ fit the available time. Contact: Daniel Vetter -Driver Specific -=============== - -tinydrm -------- +Level: See details -Tinydrm is the helper driver for really simple fb drivers. The goal is to make -those drivers as simple as possible, so lots of room for refactoring: +Backlight Refactoring +--------------------- -- backlight helpers, probably best to put them into a new drm_backlight.c. - This is because drivers/video is de-facto unmaintained. We could also - move drivers/video/backlight to drivers/gpu/backlight and take it all - over within drm-misc, but that's more work. Backlight helpers require a fair - bit of reworking and refactoring. A simple example is the enabling of a backlight. - Tinydrm has helpers for this. It would be good if other drivers can also use the - helper. However, there are various cases we need to consider i.e different - drivers seem to have different ways of enabling/disabling a backlight. - We also need to consider the backlight drivers (like gpio_backlight). The situation - is further complicated by the fact that the backlight is tied to fbdev - via fb_notifier_callback() which has complicated logic. For further details, refer - to the following discussion thread: - https://groups.google.com/forum/#!topic/outreachy-kernel/8rBe30lwtdA +Backlight drivers have a triple enable/disable state, which is a bit overkill. +Plan to fix this: -- spi helpers, probably best put into spi core/helper code. Thierry said - the spi maintainer is fast&reactive, so shouldn't be a big issue. +1. Roll out backlight_enable() and backlight_disable() helpers everywhere. This + has started already. +2. In all, only look at one of the three status bits set by the above helpers. +3. Remove the other two status bits. -- extract the mipi-dbi helper (well, the non-tinydrm specific parts at - least) into a separate helper, like we have for mipi-dsi already. Or follow - one of the ideas for having a shared dsi/dbi helper, abstracting away the - transport details more. +Contact: Daniel Vetter -- Quick aside: The unregister devm stuff is kinda getting the lifetimes of - a drm_device wrong. Doesn't matter, since everyone else gets it wrong - too :-) +Level: Intermediate -Contact: Noralf Trønnes, Daniel Vetter +Driver Specific +=============== AMD DC Display Driver --------------------- @@ -485,12 +507,51 @@ See drivers/gpu/drm/amd/display/TODO for tasks. Contact: Harry Wentland, Alex Deucher -i915 ----- +Bootsplash +========== + +There is support in place now for writing internal DRM clients making it +possible to pick up the bootsplash work that was rejected because it was written +for fbdev. -- Our early/late pm callbacks could be removed in favour of using - device_link_add to model the dependency between i915 and snd_had. See - https://dri.freedesktop.org/docs/drm/driver-api/device_link.html +- [v6,8/8] drm/client: Hack: Add bootsplash example + https://patchwork.freedesktop.org/patch/306579/ + +- [RFC PATCH v2 00/13] Kernel based bootsplash + https://lkml.org/lkml/2017/12/13/764 + +Contact: Sam Ravnborg + +Level: Advanced Outside DRM =========== + +Convert fbdev drivers to DRM +---------------------------- + +There are plenty of fbdev drivers for older hardware. Some hwardware has +become obsolete, but some still provides good(-enough) framebuffers. The +drivers that are still useful should be converted to DRM and afterwards +removed from fbdev. + +Very simple fbdev drivers can best be converted by starting with a new +DRM driver. Simple KMS helpers and SHMEM should be able to handle any +existing hardware. The new driver's call-back functions are filled from +existing fbdev code. + +More complex fbdev drivers can be refactored step-by-step into a DRM +driver with the help of the DRM fbconv helpers. [1] These helpers provide +the transition layer between the DRM core infrastructure and the fbdev +driver interface. Create a new DRM driver on top of the fbconv helpers, +copy over the fbdev driver, and hook it up to the DRM code. Examples for +several fbdev drivers are available at [1] and a tutorial of this process +available at [2]. The result is a primitive DRM driver that can run X11 +and Weston. + + - [1] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv + - [2] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c + +Contact: Thomas Zimmermann <[email protected]> + +Level: Advanced |