| todo.rst (04cf420bbc32a599aa2481725f708435ea19bf3d) | todo.rst (e066e9aa4d9c869c92d1d03647472e4ce96c0919) |
|---|---|
| 1.. _todo: 2 3========= 4TODO list 5========= 6 7This section contains a list of smaller janitorial tasks in the kernel DRM 8graphics subsystem useful as newbie projects. Or for slow rainy days. --- 23 unchanged lines hidden (view full) --- 32Remove custom dumb_map_offset implementations 33--------------------------------------------- 34 35All GEM based drivers should be using drm_gem_create_mmap_offset() instead. 36Audit each individual driver, make sure it'll work with the generic 37implementation (there's lots of outdated locking leftovers in various 38implementations), and then remove it. 39 | 1.. _todo: 2 3========= 4TODO list 5========= 6 7This section contains a list of smaller janitorial tasks in the kernel DRM 8graphics subsystem useful as newbie projects. Or for slow rainy days. --- 23 unchanged lines hidden (view full) --- 32Remove custom dumb_map_offset implementations 33--------------------------------------------- 34 35All GEM based drivers should be using drm_gem_create_mmap_offset() instead. 36Audit each individual driver, make sure it'll work with the generic 37implementation (there's lots of outdated locking leftovers in various 38implementations), and then remove it. 39 |
| 40Contact: Daniel Vetter, respective driver maintainers | 40Contact: Simona Vetter, respective driver maintainers |
| 41 42Level: Intermediate 43 44Convert existing KMS drivers to atomic modesetting 45-------------------------------------------------- 46 473.19 has the atomic modeset interfaces and helpers, so drivers can now be 48converted over. Modern compositors like Wayland or Surfaceflinger on Android --- 7 unchanged lines hidden (view full) --- 56As part of this drivers also need to convert to universal plane (which means 57exposing primary & cursor as proper plane objects). But that's much easier to 58do by directly using the new atomic helper driver callbacks. 59 60 .. [1] https://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html 61 .. [2] https://lwn.net/Articles/653071/ 62 .. [3] https://lwn.net/Articles/653466/ 63 | 41 42Level: Intermediate 43 44Convert existing KMS drivers to atomic modesetting 45-------------------------------------------------- 46 473.19 has the atomic modeset interfaces and helpers, so drivers can now be 48converted over. Modern compositors like Wayland or Surfaceflinger on Android --- 7 unchanged lines hidden (view full) --- 56As part of this drivers also need to convert to universal plane (which means 57exposing primary & cursor as proper plane objects). But that's much easier to 58do by directly using the new atomic helper driver callbacks. 59 60 .. [1] https://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html 61 .. [2] https://lwn.net/Articles/653071/ 62 .. [3] https://lwn.net/Articles/653466/ 63 |
| 64Contact: Daniel Vetter, respective driver maintainers | 64Contact: Simona Vetter, respective driver maintainers |
| 65 66Level: Advanced 67 68Clean up the clipped coordination confusion around planes 69--------------------------------------------------------- 70 71We have a helper to get this right with drm_plane_helper_check_update(), but 72it's not consistently used. This should be fixed, preferably in the atomic 73helpers (and drivers then moved over to clipped coordinates). Probably the 74helper should also be moved from drm_plane_helper.c to the atomic helpers, to 75avoid confusion - the other helpers in that file are all deprecated legacy 76helpers. 77 | 65 66Level: Advanced 67 68Clean up the clipped coordination confusion around planes 69--------------------------------------------------------- 70 71We have a helper to get this right with drm_plane_helper_check_update(), but 72it's not consistently used. This should be fixed, preferably in the atomic 73helpers (and drivers then moved over to clipped coordinates). Probably the 74helper should also be moved from drm_plane_helper.c to the atomic helpers, to 75avoid confusion - the other helpers in that file are all deprecated legacy 76helpers. 77 |
| 78Contact: Ville Syrjälä, Daniel Vetter, driver maintainers | 78Contact: Ville Syrjälä, Simona Vetter, driver maintainers |
| 79 80Level: Advanced 81 82Improve plane atomic_check helpers 83---------------------------------- 84 85Aside from the clipped coordinates right above there's a few suboptimal things 86with the current helpers: --- 5 unchanged lines hidden (view full) --- 92 into the drm_plane_funcs->atomic_duplicate_state functions. 93 94- Once that's done, helpers could stop calling ->atomic_check for disabled 95 planes. 96 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. 99 | 79 80Level: Advanced 81 82Improve plane atomic_check helpers 83---------------------------------- 84 85Aside from the clipped coordinates right above there's a few suboptimal things 86with the current helpers: --- 5 unchanged lines hidden (view full) --- 92 into the drm_plane_funcs->atomic_duplicate_state functions. 93 94- Once that's done, helpers could stop calling ->atomic_check for disabled 95 planes. 96 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. 99 |
| 100Contact: Daniel Vetter | 100Contact: Simona Vetter |
| 101 102Level: Advanced 103 104Convert early atomic drivers to async commit helpers 105---------------------------------------------------- 106 107For the first year the atomic modeset helpers didn't support asynchronous / 108nonblocking commits, and every driver had to hand-roll them. This is fixed 109now, but there's still a pile of existing drivers that easily could be 110converted over to the new infrastructure. 111 112One issue with the helpers is that they require that drivers handle completion 113events for atomic commits correctly. But fixing these bugs is good anyway. 114 115Somewhat related is the legacy_cursor_update hack, which should be replaced with 116the new atomic_async_check/commit functionality in the helpers in drivers that 117still look at that flag. 118 | 101 102Level: Advanced 103 104Convert early atomic drivers to async commit helpers 105---------------------------------------------------- 106 107For the first year the atomic modeset helpers didn't support asynchronous / 108nonblocking commits, and every driver had to hand-roll them. This is fixed 109now, but there's still a pile of existing drivers that easily could be 110converted over to the new infrastructure. 111 112One issue with the helpers is that they require that drivers handle completion 113events for atomic commits correctly. But fixing these bugs is good anyway. 114 115Somewhat related is the legacy_cursor_update hack, which should be replaced with 116the new atomic_async_check/commit functionality in the helpers in drivers that 117still look at that flag. 118 |
| 119Contact: Daniel Vetter, respective driver maintainers | 119Contact: Simona Vetter, respective driver maintainers |
| 120 121Level: Advanced 122 123Rename drm_atomic_state 124----------------------- 125 126The KMS framework uses two slightly different definitions for the ``state`` 127concept. For a given object (plane, CRTC, encoder, etc., so --- 36 unchanged lines hidden (view full) --- 164* A bunch of the vtable hooks are now in the wrong place: DRM has a split 165 between core vfunc tables (named ``drm_foo_funcs``), which are used to 166 implement the userspace ABI. And then there's the optional hooks for the 167 helper libraries (name ``drm_foo_helper_funcs``), which are purely for 168 internal use. Some of these hooks should be move from ``_funcs`` to 169 ``_helper_funcs`` since they are not part of the core ABI. There's a 170 ``FIXME`` comment in the kerneldoc for each such case in ``drm_crtc.h``. 171 | 120 121Level: Advanced 122 123Rename drm_atomic_state 124----------------------- 125 126The KMS framework uses two slightly different definitions for the ``state`` 127concept. For a given object (plane, CRTC, encoder, etc., so --- 36 unchanged lines hidden (view full) --- 164* A bunch of the vtable hooks are now in the wrong place: DRM has a split 165 between core vfunc tables (named ``drm_foo_funcs``), which are used to 166 implement the userspace ABI. And then there's the optional hooks for the 167 helper libraries (name ``drm_foo_helper_funcs``), which are purely for 168 internal use. Some of these hooks should be move from ``_funcs`` to 169 ``_helper_funcs`` since they are not part of the core ABI. There's a 170 ``FIXME`` comment in the kerneldoc for each such case in ``drm_crtc.h``. 171 |
| 172Contact: Daniel Vetter | 172Contact: Simona Vetter |
| 173 174Level: Intermediate 175 176Get rid of dev->struct_mutex from GEM drivers 177--------------------------------------------- 178 179``dev->struct_mutex`` is the Big DRM Lock from legacy days and infested 180everything. Nowadays in modern drivers the only bit where it's mandatory is --- 8 unchanged lines hidden (view full) --- 189For drivers that need ``struct_mutex`` it should be replaced with a driver- 190private lock. The tricky part is the BO free functions, since those can't 191reliably take that lock any more. Instead state needs to be protected with 192suitable subordinate locks or some cleanup work pushed to a worker thread. For 193performance-critical drivers it might also be better to go with a more 194fine-grained per-buffer object and per-context lockings scheme. Currently only 195the ``msm`` and `i915` drivers use ``struct_mutex``. 196 | 173 174Level: Intermediate 175 176Get rid of dev->struct_mutex from GEM drivers 177--------------------------------------------- 178 179``dev->struct_mutex`` is the Big DRM Lock from legacy days and infested 180everything. Nowadays in modern drivers the only bit where it's mandatory is --- 8 unchanged lines hidden (view full) --- 189For drivers that need ``struct_mutex`` it should be replaced with a driver- 190private lock. The tricky part is the BO free functions, since those can't 191reliably take that lock any more. Instead state needs to be protected with 192suitable subordinate locks or some cleanup work pushed to a worker thread. For 193performance-critical drivers it might also be better to go with a more 194fine-grained per-buffer object and per-context lockings scheme. Currently only 195the ``msm`` and `i915` drivers use ``struct_mutex``. 196 |
| 197Contact: Daniel Vetter, respective driver maintainers | 197Contact: Simona Vetter, respective driver maintainers |
| 198 199Level: Advanced 200 201Move Buffer Object Locking to dma_resv_lock() 202--------------------------------------------- 203 204Many drivers have their own per-object locking scheme, usually using 205mutex_lock(). This causes all kinds of trouble for buffer sharing, since --- 40 unchanged lines hidden (view full) --- 246Reimplement functions in drm_fbdev_fb_ops without fbdev 247------------------------------------------------------- 248 249A number of callback functions in drm_fbdev_fb_ops could benefit from 250being rewritten without dependencies on the fbdev module. Some of the 251helpers could further benefit from using struct iosys_map instead of 252raw pointers. 253 | 198 199Level: Advanced 200 201Move Buffer Object Locking to dma_resv_lock() 202--------------------------------------------- 203 204Many drivers have their own per-object locking scheme, usually using 205mutex_lock(). This causes all kinds of trouble for buffer sharing, since --- 40 unchanged lines hidden (view full) --- 246Reimplement functions in drm_fbdev_fb_ops without fbdev 247------------------------------------------------------- 248 249A number of callback functions in drm_fbdev_fb_ops could benefit from 250being rewritten without dependencies on the fbdev module. Some of the 251helpers could further benefit from using struct iosys_map instead of 252raw pointers. 253 |
| 254Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter | 254Contact: Thomas Zimmermann <tzimmermann@suse.de>, Simona Vetter |
| 255 256Level: Advanced 257 258Benchmark and optimize blitting and format-conversion function 259-------------------------------------------------------------- 260 261Drawing to display memory quickly is crucial for many applications' 262performance. --- 29 unchanged lines hidden (view full) --- 292 293- Need to switch to drm_gem_fb_create(), as now drm_gem_fb_create() checks for 294 valid formats for atomic drivers. 295 296- Many drivers subclass drm_framebuffer, we'd need a embedding compatible 297 version of the varios drm_gem_fb_create functions. Maybe called 298 drm_gem_fb_create/_with_dirty/_with_funcs as needed. 299 | 255 256Level: Advanced 257 258Benchmark and optimize blitting and format-conversion function 259-------------------------------------------------------------- 260 261Drawing to display memory quickly is crucial for many applications' 262performance. --- 29 unchanged lines hidden (view full) --- 292 293- Need to switch to drm_gem_fb_create(), as now drm_gem_fb_create() checks for 294 valid formats for atomic drivers. 295 296- Many drivers subclass drm_framebuffer, we'd need a embedding compatible 297 version of the varios drm_gem_fb_create functions. Maybe called 298 drm_gem_fb_create/_with_dirty/_with_funcs as needed. 299 |
| 300Contact: Daniel Vetter | 300Contact: Simona Vetter |
| 301 302Level: Intermediate 303 304Generic fbdev defio support 305--------------------------- 306 307The defio support code in the fbdev core has some very specific requirements, 308which means drivers need to have a special framebuffer for fbdev. The main --- 15 unchanged lines hidden (view full) --- 324 require a struct page. uff. These should all work on plain ptes, they don't 325 actually require a struct page. 326 327- Track the dirty pages in a separate structure (bitfield with one bit per page 328 should work) to avoid clobbering struct page. 329 330Might be good to also have some igt testcases for this. 331 | 301 302Level: Intermediate 303 304Generic fbdev defio support 305--------------------------- 306 307The defio support code in the fbdev core has some very specific requirements, 308which means drivers need to have a special framebuffer for fbdev. The main --- 15 unchanged lines hidden (view full) --- 324 require a struct page. uff. These should all work on plain ptes, they don't 325 actually require a struct page. 326 327- Track the dirty pages in a separate structure (bitfield with one bit per page 328 should work) to avoid clobbering struct page. 329 330Might be good to also have some igt testcases for this. 331 |
| 332Contact: Daniel Vetter, Noralf Tronnes | 332Contact: Simona Vetter, Noralf Tronnes |
| 333 334Level: Advanced 335 336connector register/unregister fixes 337----------------------------------- 338 339- For most connectors it's a no-op to call drm_connector_register/unregister 340 directly from driver code, drm_dev_register/unregister take care of this --- 13 unchanged lines hidden (view full) --- 354for historical reasons they get the ordering wrong (and we can't fix that) 355between setting up the &drm_driver structure and calling drm_dev_register(). 356 357- Rework drivers to no longer use the load/unload callbacks, directly coding the 358 load/unload sequence into the driver's probe function. 359 360- Once all drivers are converted, remove the load/unload callbacks. 361 | 333 334Level: Advanced 335 336connector register/unregister fixes 337----------------------------------- 338 339- For most connectors it's a no-op to call drm_connector_register/unregister 340 directly from driver code, drm_dev_register/unregister take care of this --- 13 unchanged lines hidden (view full) --- 354for historical reasons they get the ordering wrong (and we can't fix that) 355between setting up the &drm_driver structure and calling drm_dev_register(). 356 357- Rework drivers to no longer use the load/unload callbacks, directly coding the 358 load/unload sequence into the driver's probe function. 359 360- Once all drivers are converted, remove the load/unload callbacks. 361 |
| 362Contact: Daniel Vetter | 362Contact: Simona Vetter |
| 363 364Level: Intermediate 365 366Replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi 367--------------------------------------------------------------- 368 369Once EDID is parsed, the monitor HDMI support information is available through 370drm_display_info.is_hdmi. Many drivers still call drm_detect_hdmi_monitor() to --- 46 unchanged lines hidden (view full) --- 417often still use raw pointers. 418 419The task is to use struct iosys_map where it makes sense. 420 421* Memory managers should use struct iosys_map for dma-buf-imported buffers. 422* TTM might benefit from using struct iosys_map internally. 423* Framebuffer copying and blitting helpers should operate on struct iosys_map. 424 | 363 364Level: Intermediate 365 366Replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi 367--------------------------------------------------------------- 368 369Once EDID is parsed, the monitor HDMI support information is available through 370drm_display_info.is_hdmi. Many drivers still call drm_detect_hdmi_monitor() to --- 46 unchanged lines hidden (view full) --- 417often still use raw pointers. 418 419The task is to use struct iosys_map where it makes sense. 420 421* Memory managers should use struct iosys_map for dma-buf-imported buffers. 422* TTM might benefit from using struct iosys_map internally. 423* Framebuffer copying and blitting helpers should operate on struct iosys_map. 424 |
| 425Contact: Thomas Zimmermann <tzimmermann@suse.de>, Christian König, Daniel Vetter | 425Contact: Thomas Zimmermann <tzimmermann@suse.de>, Christian König, Simona Vetter |
| 426 427Level: Intermediate 428 429Review all drivers for setting struct drm_mode_config.{max_width,max_height} correctly 430-------------------------------------------------------------------------------------- 431 432The values in struct drm_mode_config.{max_width,max_height} describe the 433maximum supported framebuffer size. It's the virtual screen size, but many --- 119 unchanged lines hidden (view full) --- 553 <https://lore.kernel.org/dri-devel/20190311174218.51899-1-noralf@tronnes.org/>`_. 554 555* Encoding the actual oops and preceding dmesg in a QR might help with the 556 dread "important stuff scrolled away" problem. See `[RFC][PATCH] Oops messages 557 transfer using QR codes 558 <https://lore.kernel.org/lkml/1446217392-11981-1-git-send-email-alexandru.murtaza@intel.com/>`_ 559 for some example code that could be reused. 560 | 426 427Level: Intermediate 428 429Review all drivers for setting struct drm_mode_config.{max_width,max_height} correctly 430-------------------------------------------------------------------------------------- 431 432The values in struct drm_mode_config.{max_width,max_height} describe the 433maximum supported framebuffer size. It's the virtual screen size, but many --- 119 unchanged lines hidden (view full) --- 553 <https://lore.kernel.org/dri-devel/20190311174218.51899-1-noralf@tronnes.org/>`_. 554 555* Encoding the actual oops and preceding dmesg in a QR might help with the 556 dread "important stuff scrolled away" problem. See `[RFC][PATCH] Oops messages 557 transfer using QR codes 558 <https://lore.kernel.org/lkml/1446217392-11981-1-git-send-email-alexandru.murtaza@intel.com/>`_ 559 for some example code that could be reused. 560 |
| 561Contact: Daniel Vetter | 561Contact: Simona Vetter |
| 562 563Level: Advanced 564 565Clean up the debugfs support 566---------------------------- 567 568There's a bunch of issues with it: 569 --- 12 unchanged lines hidden (view full) --- 582- The drm_driver->debugfs_init hooks we have is just an artifact of the old 583 midlayered load sequence. DRM debugfs should work more like sysfs, where you 584 can create properties/files for an object anytime you want, and the core 585 takes care of publishing/unpuplishing all the files at register/unregister 586 time. Drivers shouldn't need to worry about these technicalities, and fixing 587 this (together with the drm_minor->drm_device move) would allow us to remove 588 debugfs_init. 589 | 562 563Level: Advanced 564 565Clean up the debugfs support 566---------------------------- 567 568There's a bunch of issues with it: 569 --- 12 unchanged lines hidden (view full) --- 582- The drm_driver->debugfs_init hooks we have is just an artifact of the old 583 midlayered load sequence. DRM debugfs should work more like sysfs, where you 584 can create properties/files for an object anytime you want, and the core 585 takes care of publishing/unpuplishing all the files at register/unregister 586 time. Drivers shouldn't need to worry about these technicalities, and fixing 587 this (together with the drm_minor->drm_device move) would allow us to remove 588 debugfs_init. 589 |
| 590Contact: Daniel Vetter | 590Contact: Simona Vetter |
| 591 592Level: Intermediate 593 594Object lifetime fixes 595--------------------- 596 597There's two related issues here 598 --- 4 unchanged lines hidden (view full) --- 603 which results in use-after free issues on driver unload. This can be serious 604 trouble even for drivers for hardware integrated on the SoC due to 605 EPROBE_DEFERRED backoff. 606 607Both these problems can be solved by switching over to drmm_kzalloc(), and the 608various convenience wrappers provided, e.g. drmm_crtc_alloc_with_planes(), 609drmm_universal_plane_alloc(), ... and so on. 610 | 591 592Level: Intermediate 593 594Object lifetime fixes 595--------------------- 596 597There's two related issues here 598 --- 4 unchanged lines hidden (view full) --- 603 which results in use-after free issues on driver unload. This can be serious 604 trouble even for drivers for hardware integrated on the SoC due to 605 EPROBE_DEFERRED backoff. 606 607Both these problems can be solved by switching over to drmm_kzalloc(), and the 608various convenience wrappers provided, e.g. drmm_crtc_alloc_with_planes(), 609drmm_universal_plane_alloc(), ... and so on. 610 |
| 611Contact: Daniel Vetter | 611Contact: Simona Vetter |
| 612 613Level: Intermediate 614 615Remove automatic page mapping from dma-buf importing 616---------------------------------------------------- 617 618When importing dma-bufs, the dma-buf and PRIME frameworks automatically map 619imported pages into the importer's DMA area. drm_gem_prime_fd_to_handle() and 620drm_gem_prime_handle_to_fd() require that importers call dma_buf_attach() 621even if they never do actual device DMA, but only CPU access through 622dma_buf_vmap(). This is a problem for USB devices, which do not support DMA 623operations. 624 625To fix the issue, automatic page mappings should be removed from the 626buffer-sharing code. Fixing this is a bit more involved, since the import/export 627cache is also tied to &drm_gem_object.import_attach. Meanwhile we paper over 628this problem for USB devices by fishing out the USB host controller device, as 629long as that supports DMA. Otherwise importing can still needlessly fail. 630 | 612 613Level: Intermediate 614 615Remove automatic page mapping from dma-buf importing 616---------------------------------------------------- 617 618When importing dma-bufs, the dma-buf and PRIME frameworks automatically map 619imported pages into the importer's DMA area. drm_gem_prime_fd_to_handle() and 620drm_gem_prime_handle_to_fd() require that importers call dma_buf_attach() 621even if they never do actual device DMA, but only CPU access through 622dma_buf_vmap(). This is a problem for USB devices, which do not support DMA 623operations. 624 625To fix the issue, automatic page mappings should be removed from the 626buffer-sharing code. Fixing this is a bit more involved, since the import/export 627cache is also tied to &drm_gem_object.import_attach. Meanwhile we paper over 628this problem for USB devices by fishing out the USB host controller device, as 629long as that supports DMA. Otherwise importing can still needlessly fail. 630 |
| 631Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter | 631Contact: Thomas Zimmermann <tzimmermann@suse.de>, Simona Vetter |
| 632 633Level: Advanced 634 635 636Better Testing 637============== 638 639Add unit tests using the Kernel Unit Testing (KUnit) framework --- 64 unchanged lines hidden (view full) --- 704Backlight drivers have a triple enable/disable state, which is a bit overkill. 705Plan to fix this: 706 7071. Roll out backlight_enable() and backlight_disable() helpers everywhere. This 708 has started already. 7092. In all, only look at one of the three status bits set by the above helpers. 7103. Remove the other two status bits. 711 | 632 633Level: Advanced 634 635 636Better Testing 637============== 638 639Add unit tests using the Kernel Unit Testing (KUnit) framework --- 64 unchanged lines hidden (view full) --- 704Backlight drivers have a triple enable/disable state, which is a bit overkill. 705Plan to fix this: 706 7071. Roll out backlight_enable() and backlight_disable() helpers everywhere. This 708 has started already. 7092. In all, only look at one of the three status bits set by the above helpers. 7103. Remove the other two status bits. 711 |
| 712Contact: Daniel Vetter | 712Contact: Simona Vetter |
| 713 714Level: Intermediate 715 716Driver Specific 717=============== 718 719AMD DC Display Driver 720--------------------- --- 147 unchanged lines hidden --- | 713 714Level: Intermediate 715 716Driver Specific 717=============== 718 719AMD DC Display Driver 720--------------------- --- 147 unchanged lines hidden --- |