| .. _todo: |
| |
| ========= |
| 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 |
| ------------------- |
| |
| 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. |
| |
| Once all existing drivers are converted we can also remove those bus support |
| files for USB and platform devices. |
| |
| 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). |
| |
| Contact: Daniel Vetter, Thierry Reding, respective driver maintainers |
| |
| Switch from reference/unreference to get/put |
| -------------------------------------------- |
| |
| For some reason DRM core uses ``reference``/``unreference`` suffixes for |
| refcounting functions, but kernel uses ``get``/``put`` (e.g. |
| ``kref_get``/``put()``). It would be good to switch over for consistency, and |
| it's shorter. Needs to be done in 3 steps for each pair of functions: |
| |
| * Create new ``get``/``put`` functions, define the old names as compatibility |
| wrappers |
| * Switch over each file/driver using a cocci-generated spatch. |
| * Once all users of the old names are gone, remove them. |
| |
| This way drivers/patches in the progress of getting merged won't break. |
| |
| Contact: Daniel Vetter |
| |
| Convert existing KMS drivers to atomic modesetting |
| -------------------------------------------------- |
| |
| 3.19 has the atomic modeset interfaces and helpers, so drivers can now be |
| 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). |
| |
| 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 |
| |
| 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 |
| 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 |
| |
| Convert early atomic drivers to async commit helpers |
| ---------------------------------------------------- |
| |
| For the first year the atomic modeset helpers didn't support asynchronous / |
| nonblocking commits, and every driver had to hand-roll them. This is fixed |
| now, but there's still a pile of existing drivers that easily could be |
| converted over to the new infrastructure. |
| |
| One issue with the helpers is that they require that drivers handle completion |
| events for atomic commits correctly. But fixing these bugs is good anyway. |
| |
| Contact: Daniel Vetter, respective driver maintainers |
| |
| Better manual-upload support for atomic |
| --------------------------------------- |
| |
| This would be especially useful for tinydrm: |
| |
| - Add a struct drm_rect dirty_clip to drm_crtc_state. When duplicating the |
| crtc state, clear that to the max values, x/y = 0 and w/h = MAX_INT, in |
| __drm_atomic_helper_crtc_duplicate_state(). |
| |
| - Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm\_ |
| prefix ofc and using drm_fb\_. drm_framebuffer.c makes sense since this |
| is a function useful to implement the fb->dirty function. |
| |
| - Create a new drm_fb_dirty function which does essentially what e.g. |
| mipi_dbi_fb_dirty does. You can use e.g. drm_atomic_helper_update_plane as the |
| template. But instead of doing a simple full-screen plane update, this new |
| helper also sets crtc_state->dirty_clip to the right coordinates. And of |
| course it needs to check whether the fb is actually active (and maybe where), |
| so there's some book-keeping involved. There's also some good fun involved in |
| scaling things appropriately. For that case we might simply give up and |
| declare the entire area covered by the plane as dirty. |
| |
| Contact: Noralf Trønnes, Daniel Vetter |
| |
| Fallout from atomic KMS |
| ----------------------- |
| |
| ``drm_atomic_helper.c`` provides a batch of functions which implement legacy |
| IOCTLs on top of the new atomic driver interface. Which is really nice for |
| gradual conversion of drivers, but unfortunately the semantic mismatches are |
| a bit too severe. So there's some follow-up work to adjust the function |
| interfaces to fix these issues: |
| |
| * atomic needs the lock acquire context. At the moment that's passed around |
| implicitly with some horrible hacks, and it's also allocate with |
| ``GFP_NOFAIL`` behind the scenes. All legacy paths need to start allocating |
| the acquire context explicitly on stack and then also pass it down into |
| drivers explicitly so that the legacy-on-atomic functions can use them. |
| |
| Except for some driver code this is done. |
| |
| * A bunch of the vtable hooks are now in the wrong place: DRM has a split |
| between core vfunc tables (named ``drm_foo_funcs``), which are used to |
| implement the userspace ABI. And then there's the optional hooks for the |
| helper libraries (name ``drm_foo_helper_funcs``), which are purely for |
| internal use. Some of these hooks should be move from ``_funcs`` to |
| ``_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``. |
| |
| * There's a new helper ``drm_atomic_helper_best_encoder()`` which could be |
| used by all atomic drivers which don't select the encoder for a given |
| connector at runtime. That's almost all of them, and would allow us to get |
| rid of a lot of ``best_encoder`` boilerplate in drivers. |
| |
| This was almost done, but new drivers added a few more cases again. |
| |
| Contact: Daniel Vetter |
| |
| 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_free_object_unlocked`` 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 the |
| following drivers still use ``struct_mutex``: ``msm``, ``omapdrm`` and |
| ``udl``. |
| |
| Contact: Daniel Vetter, respective driver maintainers |
| |
| Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent |
| ---------------------------------------------------------------------------- |
| |
| For drivers which could have multiple instances, it is necessary to |
| differentiate between which is which in the logs. Since DRM_INFO/WARN/ERROR |
| don't do this, drivers used dev_info/warn/err to make this differentiation. We |
| now have DRM_DEV_* variants of the drm print macros, so we can start to convert |
| those drivers back to using drm-formwatted specific log messages. |
| |
| Before you start this conversion please contact the relevant maintainers to make |
| sure your work will be merged - not everyone agrees that the DRM dmesg macros |
| are better. |
| |
| Contact: Sean Paul, Maintainer of the driver you plan to convert |
| |
| Convert drivers to use simple modeset suspend/resume |
| ---------------------------------------------------- |
| |
| Most drivers (except i915 and nouveau) that use |
| drm_atomic_helper_suspend/resume() can probably be converted to use |
| drm_mode_config_helper_suspend/resume(). |
| |
| Contact: Maintainer of the driver you plan to convert |
| |
| Convert drivers to use drm_fb_helper_fbdev_setup/teardown() |
| ----------------------------------------------------------- |
| |
| Most drivers can use drm_fb_helper_fbdev_setup() except maybe: |
| |
| - amdgpu which has special logic to decide whether to call |
| drm_helper_disable_unused_functions() |
| |
| - armada which isn't atomic and doesn't call |
| drm_helper_disable_unused_functions() |
| |
| - i915 which calls drm_fb_helper_initial_config() in a worker |
| |
| Drivers that use drm_framebuffer_remove() to clean up the fbdev framebuffer can |
| probably use drm_fb_helper_fbdev_teardown(). |
| |
| Contact: Maintainer of the driver you plan to convert |
| |
| 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. |
| |
| Contact: Daniel Vetter |
| |
| 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 |
| |
| idr_init_base() |
| --------------- |
| |
| DRM core&drivers uses a lot of idr (integer lookup directories) for mapping |
| userspace IDs to internal objects, and in most places ID=0 means NULL and hence |
| is never used. Switching to idr_init_base() for these would make the idr more |
| efficient. |
| |
| Contact: Daniel Vetter |
| |
| Core refactorings |
| ================= |
| |
| Clean up the DRM header mess |
| ---------------------------- |
| |
| Currently the DRM subsystem has only one global header, ``drmP.h``. This is |
| used both for functions exported to helper libraries and drivers and functions |
| only used internally in the ``drm.ko`` module. The goal would be to move all |
| header declarations not needed outside of ``drm.ko`` into |
| ``drivers/gpu/drm/drm_*_internal.h`` header files. ``EXPORT_SYMBOL`` also |
| needs to be dropped for these functions. |
| |
| This would nicely tie in with the below task to create kerneldoc after the API |
| is cleaned up. Or with the "hide legacy cruft better" task. |
| |
| Note that this is well in progress, but ``drmP.h`` is still huge. The updated |
| plan is to switch to per-file driver API headers, which will also structure |
| the kerneldoc better. This should also allow more fine-grained ``#include`` |
| directives. |
| |
| In the end no .c file should need to include ``drmP.h`` anymore. |
| |
| Contact: Daniel Vetter |
| |
| Add missing kerneldoc for exported functions |
| -------------------------------------------- |
| |
| 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. |
| |
| See https://dri.freedesktop.org/docs/drm/ for what's there already. |
| |
| Contact: Daniel Vetter |
| |
| Hide legacy cruft better |
| ------------------------ |
| |
| Way back DRM supported only drivers which shadow-attached to PCI devices with |
| userspace or fbdev drivers setting up outputs. Modern DRM drivers take charge |
| of the entire device, you can spot them with the DRIVER_MODESET flag. |
| |
| Unfortunately there's still large piles of legacy code around which needs to |
| be hidden so that driver writers don't accidentally end up using it. And to |
| prevent security issues in those legacy IOCTLs from being exploited on modern |
| drivers. This has multiple possible subtasks: |
| |
| * Extract support code for legacy features into a ``drm-legacy.ko`` kernel |
| module and compile it only when one of the legacy drivers is enabled. |
| |
| This is mostly done, the only thing left is to split up ``drm_irq.c`` into |
| legacy cruft and the parts needed by modern KMS drivers. |
| |
| Contact: Daniel Vetter |
| |
| Make panic handling work |
| ------------------------ |
| |
| This is a really varied tasks with lots of little bits and pieces: |
| |
| * The panic path can't be tested currently, leading to constant breaking. The |
| main issue here is that panics can be triggered from hardirq contexts and |
| hence all panic related callback can run in hardirq context. It would be |
| awesome if we could test at least the fbdev helper code and driver code by |
| e.g. trigger calls through drm debugfs files. hardirq context could be |
| 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. |
| |
| * ``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 |
| returns true if there's a panic going on for real, and fix up all the |
| fallout. |
| |
| * The panic handler must never sleep, which also means it can't ever |
| ``mutex_lock()``. Also it can't grab any other lock unconditionally, not |
| 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. |
| |
| * 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. |
| |
| Contact: Daniel Vetter |
| |
| Clean up the debugfs support |
| ---------------------------- |
| |
| There's a bunch of issues with it: |
| |
| - The drm_info_list ->show() function doesn't even bother to cast to the drm |
| structure for you. This is lazy. |
| |
| - We probably want to have some support for debugfs files on crtc/connectors and |
| maybe other kms objects directly in core. There's even drm_print support in |
| the funcs for these objects to dump kms state, so it's all there. And then the |
| ->show() functions should obviously give you a pointer to the right object. |
| |
| - The drm_info_list stuff is centered on drm_minor instead of drm_device. For |
| anything we want to print drm_device (or maybe drm_file) is the right thing. |
| |
| - The drm_driver->debugfs_init hooks we have is just an artifact of the old |
| midlayered load sequence. DRM debugfs should work more like sysfs, where you |
| can create properties/files for an object anytime you want, and the core |
| takes care of publishing/unpuplishing all the files at register/unregister |
| time. Drivers shouldn't need to worry about these technicalities, and fixing |
| this (together with the drm_minor->drm_device move) would allow us to remove |
| debugfs_init. |
| |
| Contact: Daniel Vetter |
| |
| KMS cleanups |
| ------------ |
| |
| Some of these date from the very introduction of KMS in 2008 ... |
| |
| - drm_mode_config.crtc_idr is misnamed, since it contains all KMS object. Should |
| be renamed to drm_mode_config.object_idr. |
| |
| - drm_display_mode doesn't need to be derived from drm_mode_object. That's |
| leftovers from older (never merged into upstream) KMS designs where modes |
| where set using their ID, including support to add/remove modes. |
| |
| Better Testing |
| ============== |
| |
| Enable trinity for DRM |
| ---------------------- |
| |
| And fix up the fallout. Should be really interesting ... |
| |
| Make KMS tests in i-g-t generic |
| ------------------------------- |
| |
| The i915 driver team maintains an extensive testsuite for the i915 DRM driver, |
| including tons of testcases for corner-cases in the modesetting API. It would |
| be awesome if those tests (at least the ones not relying on Intel-specific GEM |
| features) could be made to run on any KMS driver. |
| |
| Basic work to run i-g-t tests on non-i915 is done, what's now missing is mass- |
| 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. |
| |
| Contact: Daniel Vetter |
| |
| Create a virtual KMS driver for testing (vkms) |
| ---------------------------------------------- |
| |
| With all the latest helpers it should be fairly simple to create a virtual KMS |
| driver useful for testing, or for running X or similar on headless machines |
| (to be able to still use the GPU). This would be similar to vgem, but aimed at |
| the modeset side. |
| |
| Once the basics are there there's tons of possibilities to extend it. |
| |
| Contact: Daniel Vetter |
| |
| Driver Specific |
| =============== |
| |
| tinydrm |
| ------- |
| |
| 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 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 |
| |
| - 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. |
| |
| - 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. |
| |
| - tinydrm_gem_cma_prime_import_sg_table should probably go into the cma |
| helpers, as a _vmapped variant (since not every driver needs the vmap). |
| And tinydrm_gem_cma_free_object could the be merged into |
| drm_gem_cma_free_object(). |
| |
| - tinydrm_fb_create we could move into drm_simple_pipe, only need to add |
| the fb_create hook to drm_simple_pipe_funcs, which would again simplify a |
| bunch of things (since it gives you a one-stop vfunc for simple drivers). |
| |
| - 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 :-) |
| |
| - also rework the drm_framebuffer_funcs->dirty hook wire-up, see above. |
| |
| Contact: Noralf Trønnes, Daniel Vetter |
| |
| AMD DC Display Driver |
| --------------------- |
| |
| AMD DC is the display driver for AMD devices starting with Vega. There has been |
| a bunch of progress cleaning it up but there's still plenty of work to be done. |
| |
| See drivers/gpu/drm/amd/display/TODO for tasks. |
| |
| Contact: Harry Wentland, Alex Deucher |
| |
| i915 |
| ---- |
| |
| - 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 |
| |
| Outside DRM |
| =========== |