diff options
Diffstat (limited to 'Documentation/gpu/todo.rst')
| -rw-r--r-- | Documentation/gpu/todo.rst | 325 |
1 files changed, 234 insertions, 91 deletions
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 1f8a5ebe188e..9013ced318cb 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -37,7 +37,7 @@ Audit each individual driver, make sure it'll work with the generic implementation (there's lots of outdated locking leftovers in various implementations), and then remove it. -Contact: Daniel Vetter, respective driver maintainers +Contact: Simona Vetter, respective driver maintainers Level: Intermediate @@ -49,15 +49,19 @@ converted over. Modern compositors like Wayland or Surfaceflinger on Android really want an atomic modeset interface, so this is all about the bright future. -There is a conversion guide for atomic and all you need is a GPU for a -non-converted driver (again virtual HW drivers for KVM are still all -suitable). +There is a conversion guide for atomic [1]_ and all you need is a GPU for a +non-converted driver. The "Atomic mode setting design overview" series [2]_ +[3]_ at LWN.net can also be helpful. As part of this drivers also need to convert to universal plane (which means exposing primary & cursor as proper plane objects). But that's much easier to do by directly using the new atomic helper driver callbacks. -Contact: Daniel Vetter, respective driver maintainers + .. [1] https://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html + .. [2] https://lwn.net/Articles/653071/ + .. [3] https://lwn.net/Articles/653466/ + +Contact: Simona Vetter, respective driver maintainers Level: Advanced @@ -65,13 +69,13 @@ Clean up the clipped coordination confusion around planes --------------------------------------------------------- We have a helper to get this right with drm_plane_helper_check_update(), but -it's not consistently used. This should be fixed, preferrably in the atomic +it's not consistently used. This should be fixed, preferably in the atomic helpers (and drivers then moved over to clipped coordinates). Probably the helper should also be moved from drm_plane_helper.c to the atomic helpers, to avoid confusion - the other helpers in that file are all deprecated legacy helpers. -Contact: Ville Syrjälä, Daniel Vetter, driver maintainers +Contact: Ville Syrjälä, Simona Vetter, driver maintainers Level: Advanced @@ -93,7 +97,7 @@ with the current helpers: - Then we could go through all the drivers and remove the more-or-less confused checks for plane_state->fb and plane_state->crtc. -Contact: Daniel Vetter +Contact: Simona Vetter Level: Advanced @@ -112,7 +116,30 @@ Somewhat related is the legacy_cursor_update hack, which should be replaced with the new atomic_async_check/commit functionality in the helpers in drivers that still look at that flag. -Contact: Daniel Vetter, respective driver maintainers +Contact: Simona Vetter, respective driver maintainers + +Level: Advanced + +Rename drm_atomic_state +----------------------- + +The KMS framework uses two slightly different definitions for the ``state`` +concept. For a given object (plane, CRTC, encoder, etc., so +``drm_$OBJECT_state``), the state is the entire state of that object. However, +at the device level, ``drm_atomic_state`` refers to a state update for a +limited number of objects. + +The state isn't the entire device state, but only the full state of some +objects in that device. This is confusing to newcomers, and +``drm_atomic_state`` should be renamed to something clearer like +``drm_atomic_commit``. + +In addition to renaming the structure itself, it would also imply renaming some +related functions (``drm_atomic_state_alloc``, ``drm_atomic_state_get``, +``drm_atomic_state_put``, ``drm_atomic_state_init``, +``__drm_atomic_state_free``, etc.). + +Contact: Maxime Ripard <mripard@kernel.org> Level: Advanced @@ -142,35 +169,10 @@ interfaces to fix these issues: ``_helper_funcs`` since they are not part of the core ABI. There's a ``FIXME`` comment in the kerneldoc for each such case in ``drm_crtc.h``. -Contact: Daniel Vetter +Contact: Simona Vetter Level: Intermediate -Get rid of dev->struct_mutex from GEM drivers ---------------------------------------------- - -``dev->struct_mutex`` is the Big DRM Lock from legacy days and infested -everything. Nowadays in modern drivers the only bit where it's mandatory is -serializing GEM buffer object destruction. Which unfortunately means drivers -have to keep track of that lock and either call ``unreference`` or -``unreference_locked`` depending upon context. - -Core GEM doesn't have a need for ``struct_mutex`` any more since kernel 4.8, -and there's a GEM object ``free`` callback for any drivers which are -entirely ``struct_mutex`` free. - -For drivers that need ``struct_mutex`` it should be replaced with a driver- -private lock. The tricky part is the BO free functions, since those can't -reliably take that lock any more. Instead state needs to be protected with -suitable subordinate locks or some cleanup work pushed to a worker thread. For -performance-critical drivers it might also be better to go with a more -fine-grained per-buffer object and per-context lockings scheme. Currently only -the ``msm`` and `i915` drivers use ``struct_mutex``. - -Contact: Daniel Vetter, respective driver maintainers - -Level: Advanced - Move Buffer Object Locking to dma_resv_lock() --------------------------------------------- @@ -181,13 +183,13 @@ reversed. To solve this we need one standard per-object locking mechanism, which is dma_resv_lock(). This lock needs to be called as the outermost lock, with all -other driver specific per-object locks removed. The problem is tha rolling out +other driver specific per-object locks removed. The problem is that rolling out the actual change to the locking contract is a flag day, due to struct dma_buf buffer sharing. Level: Expert -Convert logging to drm_* functions with drm_device paramater +Convert logging to drm_* functions with drm_device parameter ------------------------------------------------------------ For drivers which could have multiple instances, it is necessary to @@ -216,19 +218,6 @@ Contact: Maintainer of the driver you plan to convert Level: Intermediate -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 iosys_map, drivers with frambuffers in I/O memory can be supported -as well. - -Contact: Maintainer of the driver you plan to convert - -Level: Intermediate - Reimplement functions in drm_fbdev_fb_ops without fbdev ------------------------------------------------------- @@ -237,14 +226,14 @@ being rewritten without dependencies on the fbdev module. Some of the helpers could further benefit from using struct iosys_map instead of raw pointers. -Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter +Contact: Thomas Zimmermann <tzimmermann@suse.de>, Simona Vetter Level: Advanced Benchmark and optimize blitting and format-conversion function -------------------------------------------------------------- -Drawing to dispay memory quickly is crucial for many applications' +Drawing to display memory quickly is crucial for many applications' performance. On at least x86-64, sys_imageblit() is significantly slower than @@ -276,17 +265,14 @@ Various hold-ups: - Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb setup code can't be deleted. -- Many drivers wrap drm_gem_fb_create() only to check for valid formats. For - atomic drivers we could check for valid formats by calling - drm_plane_check_pixel_format() against all planes, and pass if any plane - supports the format. For non-atomic that's not possible since like the format - list for the primary plane is fake and we'd therefor reject valid formats. +- Need to switch to drm_gem_fb_create(), as now drm_gem_fb_create() checks for + valid formats for atomic drivers. - Many drivers subclass drm_framebuffer, we'd need a embedding compatible version of the varios drm_gem_fb_create functions. Maybe called drm_gem_fb_create/_with_dirty/_with_funcs as needed. -Contact: Daniel Vetter +Contact: Simona Vetter Level: Intermediate @@ -318,19 +304,10 @@ everything after it has done the write-protect/mkwrite trickery: Might be good to also have some igt testcases for this. -Contact: Daniel Vetter, Noralf Tronnes +Contact: Simona Vetter, Noralf Tronnes Level: Advanced -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. Callbacks in drivers have been -converted, except for struct drm_driver.gem_prime_mmap. - -Level: Intermediate - connector register/unregister fixes ----------------------------------- @@ -345,8 +322,8 @@ connector register/unregister fixes Level: Intermediate -Remove load/unload callbacks from all non-DRIVER_LEGACY drivers ---------------------------------------------------------------- +Remove load/unload callbacks +---------------------------- The load/unload callbacks in struct &drm_driver are very much midlayers, plus for historical reasons they get the ordering wrong (and we can't fix that) @@ -355,10 +332,9 @@ between setting up the &drm_driver structure and calling drm_dev_register(). - Rework drivers to no longer use the load/unload callbacks, directly coding the load/unload sequence into the driver's probe function. -- Once all non-DRIVER_LEGACY drivers are converted, disallow the load/unload - callbacks for all modern drivers. +- Once all drivers are converted, remove the load/unload callbacks. -Contact: Daniel Vetter +Contact: Simona Vetter Level: Intermediate @@ -421,7 +397,7 @@ The task is to use struct iosys_map where it makes sense. * 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 +Contact: Thomas Zimmermann <tzimmermann@suse.de>, Christian König, Simona Vetter Level: Intermediate @@ -440,14 +416,15 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de> Level: Intermediate -Request memory regions in all drivers -------------------------------------- +Request memory regions in all fbdev 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(), +Old/ancient fbdev drivers do not request their memory properly. +Go through these 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. - +where possible. Problematic areas include hardware that has exclusive ranges +like VGA. VGA16fb does not request the range as it is expected. 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. @@ -455,6 +432,79 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de> Level: Starter +Remove driver dependencies on FB_DEVICE +--------------------------------------- + +A number of fbdev drivers provide attributes via sysfs and therefore depend +on CONFIG_FB_DEVICE to be selected. Review each driver and attempt to make +any dependencies on CONFIG_FB_DEVICE optional. At the minimum, the respective +code in the driver could be conditionalized via ifdef CONFIG_FB_DEVICE. Not +all drivers might be able to drop CONFIG_FB_DEVICE. + +Contact: Thomas Zimmermann <tzimmermann@suse.de> + +Level: Starter + +Remove disable/unprepare in remove/shutdown in panel-simple and panel-edp +------------------------------------------------------------------------- + +As of commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in +drm_panel"), we have a check in the drm_panel core to make sure nobody +double-calls prepare/enable/disable/unprepare. Eventually that should probably +be turned into a WARN_ON() or somehow made louder. + +At the moment, we expect that we may still encounter the warnings in the +drm_panel core when using panel-simple and panel-edp. Since those panel +drivers are used with a lot of different DRM modeset drivers they still +make an extra effort to disable/unprepare the panel themsevles at shutdown +time. Specifically we could still encounter those warnings if the panel +driver gets shutdown() _before_ the DRM modeset driver and the DRM modeset +driver properly calls drm_atomic_helper_shutdown() in its own shutdown() +callback. Warnings could be avoided in such a case by using something like +device links to ensure that the panel gets shutdown() after the DRM modeset +driver. + +Once all DRM modeset drivers are known to shutdown properly, the extra +calls to disable/unprepare in remove/shutdown in panel-simple and panel-edp +should be removed and this TODO item marked complete. + +Contact: Douglas Anderson <dianders@chromium.org> + +Level: Intermediate + +Transition away from using deprecated MIPI DSI functions +-------------------------------------------------------- + +There are many functions defined in ``drm_mipi_dsi.c`` which have been +deprecated. Each deprecated function was deprecated in favor of its `multi` +variant (e.g. `mipi_dsi_generic_write()` and `mipi_dsi_generic_write_multi()`). +The `multi` variant of a function includes improved error handling and logic +which makes it more convenient to make several calls in a row, as most MIPI +drivers do. + +Drivers should be updated to use undeprecated functions. Once all usages of the +deprecated MIPI DSI functions have been removed, their definitions may be +removed from ``drm_mipi_dsi.c``. + +Contact: Douglas Anderson <dianders@chromium.org> + +Level: Starter + +Remove devm_drm_put_bridge() +---------------------------- + +Due to how the panel bridge handles the drm_bridge object lifetime, special +care must be taken to dispose of the drm_bridge object when the +panel_bridge is removed. This is currently managed using +devm_drm_put_bridge(), but that is an unsafe, temporary workaround. To fix +that, the DRM panel lifetime needs to be reworked. After the rework is +done, remove devm_drm_put_bridge() and the TODO in +drm_panel_bridge_remove(). + +Contact: Maxime Ripard <mripard@kernel.org>, + Luca Ceresoli <luca.ceresoli@bootlin.com> + +Level: Intermediate Core refactorings ================= @@ -499,7 +549,7 @@ This is a really varied tasks with lots of little bits and pieces: <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 +Contact: Simona Vetter Level: Advanced @@ -528,7 +578,7 @@ There's a bunch of issues with it: this (together with the drm_minor->drm_device move) would allow us to remove debugfs_init. -Contact: Daniel Vetter +Contact: Simona Vetter Level: Intermediate @@ -549,7 +599,7 @@ Both these problems can be solved by switching over to drmm_kzalloc(), and the various convenience wrappers provided, e.g. drmm_crtc_alloc_with_planes(), drmm_universal_plane_alloc(), ... and so on. -Contact: Daniel Vetter +Contact: Simona Vetter Level: Intermediate @@ -569,10 +619,47 @@ cache is also tied to &drm_gem_object.import_attach. Meanwhile we paper over this problem for USB devices by fishing out the USB host controller device, as long as that supports DMA. Otherwise importing can still needlessly fail. -Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter +Contact: Thomas Zimmermann <tzimmermann@suse.de>, Simona Vetter Level: Advanced +Implement a new DUMB_CREATE2 ioctl +---------------------------------- + +The current DUMB_CREATE ioctl is not well defined. Instead of a pixel and +framebuffer format, it only accepts a color mode of vague semantics. Assuming +a linear framebuffer, the color mode gives an idea of the supported pixel +format. But userspace effectively has to guess the correct values. It really +only works reliably with framebuffers in XRGB8888. Userspace has begun to +workaround these limitations by computing arbitrary format's buffer sizes and +calculating their sizes in terms of XRGB8888 pixels. + +One possible solution is a new ioctl DUMB_CREATE2. It should accept a DRM +format and a format modifier to resolve the color mode's ambiguity. As +framebuffers can be multi-planar, the new ioctl has to return the buffer size, +pitch and GEM handle for each individual color plane. + +In the first step, the new ioctl can be limited to the current features of +the existing DUMB_CREATE. Individual drivers can then be extended to support +multi-planar formats. Rockchip might require this and would be a good candidate. + +It might also be helpful to userspace to query information about the size of +a potential buffer, if allocated. Userspace would supply geometry and format; +the kernel would return minimal allocation sizes and scanline pitch. There is +interest to allocate that memory from another device and provide it to the +DRM driver (say via dma-buf). + +Another requested feature is the ability to allocate a buffer by size, without +format. Accelators use this for their buffer allocation and it could likely be +generalized. + +In addition to the kernel implementation, there must be user-space support +for the new ioctl. There's code in Mesa that might be able to use the new +call. + +Contact: Thomas Zimmermann <tzimmermann@suse.de> + +Level: Advanced Better Testing ============== @@ -591,6 +678,23 @@ Contact: Javier Martinez Canillas <javierm@redhat.com> Level: Intermediate +Clean up and document former selftests suites +--------------------------------------------- + +Some KUnit test suites (drm_buddy, drm_cmdline_parser, drm_damage_helper, +drm_format, drm_framebuffer, drm_dp_mst_helper, drm_mm, drm_plane_helper and +drm_rect) are former selftests suites that have been converted over when KUnit +was first introduced. + +These suites were fairly undocumented, and with different goals than what unit +tests can be. Trying to identify what each test in these suites actually test +for, whether that makes sense for a unit test, and either remove it if it +doesn't or document it if it does would be of great help. + +Contact: Maxime Ripard <mripard@kernel.org> + +Level: Intermediate + Enable trinity for DRM ---------------------- @@ -633,7 +737,7 @@ Plan to fix this: 2. In all, only look at one of the three status bits set by the above helpers. 3. Remove the other two status bits. -Contact: Daniel Vetter +Contact: Simona Vetter Level: Intermediate @@ -735,6 +839,45 @@ Contact: Hans de Goede Level: Advanced +Buffer age or other damage accumulation algorithm for buffer damage +=================================================================== + +Drivers that do per-buffer uploads, need a buffer damage handling (rather than +frame damage like drivers that do per-plane or per-CRTC uploads), but there is +no support to get the buffer age or any other damage accumulation algorithm. + +For this reason, the damage helpers just fallback to a full plane update if the +framebuffer attached to a plane has changed since the last page-flip. Drivers +set &drm_plane_state.ignore_damage_clips to true as indication to +drm_atomic_helper_damage_iter_init() and drm_atomic_helper_damage_iter_next() +helpers that the damage clips should be ignored. + +This should be improved to get damage tracking properly working on drivers that +do per-buffer uploads. + +More information about damage tracking and references to learning materials can +be found in :ref:`damage_tracking_properties`. + +Contact: Javier Martinez Canillas <javierm@redhat.com> + +Level: Advanced + +Querying errors from drm_syncobj +================================ + +The drm_syncobj container can be used by driver independent code to signal +complection of submission. + +One minor feature still missing is a generic DRM IOCTL to query the error +status of binary and timeline drm_syncobj. + +This should probably be improved by implementing the necessary kernel interface +and adding support for that in the userspace stack. + +Contact: Christian König + +Level: Starter + Outside DRM =========== @@ -752,16 +895,16 @@ 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 +driver with the help of the DRM fbconv helpers [4]_. 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. +several fbdev drivers are available in Thomas Zimmermann's fbconv tree +[4]_, as well as a tutorial of this process [5]_. 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 + .. [4] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv + .. [5] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c Contact: Thomas Zimmermann <tzimmermann@suse.de> |