558 lines
21 KiB
ReStructuredText
558 lines
21 KiB
ReStructuredText
.. _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.
|
|
|
|
Difficulty
|
|
----------
|
|
|
|
To make it easier task are categorized into different levels:
|
|
|
|
Starter: Good tasks to get started with the DRM subsystem.
|
|
|
|
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.
|
|
|
|
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
|
|
---------------------------------------------
|
|
|
|
All GEM based drivers should be using drm_gem_create_mmap_offset() instead.
|
|
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
|
|
|
|
Level: Intermediate
|
|
|
|
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
|
|
|
|
Level: Advanced
|
|
|
|
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
|
|
|
|
Level: Advanced
|
|
|
|
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
|
|
|
|
Level: Advanced
|
|
|
|
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. This task should be finished by
|
|
adding WARN_ON(!drm_drv_uses_atomic_modeset) in drm_modeset_lock_all().
|
|
|
|
* 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``.
|
|
|
|
Contact: Daniel 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_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 only the
|
|
``msm`` driver still use ``struct_mutex``.
|
|
|
|
Contact: Daniel Vetter, respective driver maintainers
|
|
|
|
Level: Advanced
|
|
|
|
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
|
|
|
|
Level: Starter
|
|
|
|
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(). Also there's still open-coded version
|
|
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()
|
|
-----------------------------------------------------------
|
|
|
|
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
|
|
|
|
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.
|
|
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. 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
|
|
everything after it has done the write-protect/mkwrite trickery:
|
|
|
|
- In the drm_fbdev_fb_mmap helper, if we need defio, change the
|
|
default page prots to write-protected with something like this::
|
|
|
|
vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot);
|
|
|
|
- Set the mkwrite and fsync callbacks with similar implementions to the core
|
|
fbdev defio stuff. These should all work on plain ptes, they don't actually
|
|
require a struct page. uff. These should all work on plain ptes, they don't
|
|
actually require a struct page.
|
|
|
|
- Track the dirty pages in a separate structure (bitfield with one bit per page
|
|
should work) to avoid clobbering struct page.
|
|
|
|
Might be good to also have some igt testcases for this.
|
|
|
|
Contact: Daniel Vetter, Noralf Tronnes
|
|
|
|
Level: Advanced
|
|
|
|
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
|
|
|
|
Level: Starter
|
|
|
|
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
|
|
---------------------------------------------------------
|
|
|
|
For cases where drivers are attempting to grab the modeset locks with a local
|
|
acquire context. Replace the boilerplate code surrounding
|
|
drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN() and
|
|
DRM_MODESET_LOCK_ALL_END() instead.
|
|
|
|
This should also be done for all places where drm_modest_lock_all() is still
|
|
used.
|
|
|
|
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
|
|
---------------------------------
|
|
|
|
CMA (standing for contiguous memory allocator) is really a bit an accident of
|
|
what these were used for first, a much better name would be DMA helpers. In the
|
|
text these should even be called coherent DMA memory helpers (so maybe CDM, but
|
|
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()
|
|
----------------------------------------------------------------
|
|
|
|
drm_display_mode.vrefresh isn't guaranteed to be populated. As such, using it
|
|
is risky and has been known to cause div-by-zero bugs. Fortunately, drm core
|
|
has helper which will use mode.vrefresh if it's !0 and will calculate it from
|
|
the timings when it's 0.
|
|
|
|
Use simple search/replace, or (more fun) cocci to replace instances of direct
|
|
vrefresh access with a call to the helper. Check out
|
|
https://lists.freedesktop.org/archives/dri-devel/2019-January/205186.html for
|
|
inspiration.
|
|
|
|
Once all instances of vrefresh have been converted, remove vrefresh from
|
|
drm_display_mode to avoid future use.
|
|
|
|
Contact: Sean Paul
|
|
|
|
Level: Starter
|
|
|
|
Remove drm_display_mode.hsync
|
|
-----------------------------
|
|
|
|
We have drm_mode_hsync() to calculate this from hsync_start/end, since drivers
|
|
shouldn't/don't use this, remove this member to avoid any temptations to use it
|
|
in the future. If there is any debug code using drm_display_mode.hsync, convert
|
|
it to use drm_mode_hsync() instead.
|
|
|
|
Contact: Sean Paul
|
|
|
|
Level: Starter
|
|
|
|
drm_fb_helper tasks
|
|
-------------------
|
|
|
|
- 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.
|
|
|
|
- The max connector argument for drm_fb_helper_init() and
|
|
drm_fb_helper_fbdev_setup() isn't used anymore and can be removed.
|
|
|
|
- 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().
|
|
|
|
Level: Intermediate
|
|
|
|
connector register/unregister fixes
|
|
-----------------------------------
|
|
|
|
- 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.
|
|
|
|
- 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
|
|
------------------------
|
|
|
|
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
|
|
|
|
Level: Advanced
|
|
|
|
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.
|
|
|
|
- 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
|
|
------------
|
|
|
|
Some of these date from the very introduction of KMS in 2008 ...
|
|
|
|
- Make ->funcs and ->helper_private vtables optional. There's a bunch of empty
|
|
function tables in drivers, but before we can remove them we need to make sure
|
|
that all the users in helpers and drivers do correctly check for a NULL
|
|
vtable.
|
|
|
|
- Cleanup up the various ->destroy callbacks. A lot of them just wrapt the
|
|
drm_*_cleanup implementations and can be removed. Some tack a kfree() at the
|
|
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
|
|
==============
|
|
|
|
Enable trinity for DRM
|
|
----------------------
|
|
|
|
And fix up the fallout. Should be really interesting ...
|
|
|
|
Level: Advanced
|
|
|
|
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.
|
|
|
|
Level: Advanced
|
|
|
|
Extend virtual test driver (VKMS)
|
|
---------------------------------
|
|
|
|
See the documentation of :ref:`VKMS <vkms>` for more details. This is an ideal
|
|
internship task, since it only requires a virtual machine and can be sized to
|
|
fit the available time.
|
|
|
|
Contact: Daniel Vetter
|
|
|
|
Level: See details
|
|
|
|
Backlight Refactoring
|
|
---------------------
|
|
|
|
Backlight drivers have a triple enable/disable state, which is a bit overkill.
|
|
Plan to fix this:
|
|
|
|
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.
|
|
|
|
Contact: Daniel Vetter
|
|
|
|
Level: Intermediate
|
|
|
|
Driver Specific
|
|
===============
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
- [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 <tzimmermann@suse.de>
|
|
|
|
Level: Advanced
|