Orange Pi5 kernel

^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   1) .. _todo:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   2) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   3) =========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   4) TODO list
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   5) =========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   6) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   7) This section contains a list of smaller janitorial tasks in the kernel DRM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   8) graphics subsystem useful as newbie projects. Or for slow rainy days.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   9) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  10) Difficulty
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  11) ----------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  12) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  13) To make it easier task are categorized into different levels:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  14) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  15) Starter: Good tasks to get started with the DRM subsystem.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  16) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  17) Intermediate: Tasks which need some experience with working in the DRM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  18) subsystem, or some specific GPU/display graphics knowledge. For debugging issue
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  19) it's good to have the relevant hardware (or a virtual driver set up) available
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  20) for testing.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  21) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  22) Advanced: Tricky tasks that need fairly good understanding of the DRM subsystem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  23) and graphics topics. Generally need the relevant hardware for development and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  24) testing.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  25) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  26) Subsystem-wide refactorings
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  27) ===========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  28) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  29) Remove custom dumb_map_offset implementations
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  30) ---------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  31) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  32) All GEM based drivers should be using drm_gem_create_mmap_offset() instead.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  33) Audit each individual driver, make sure it'll work with the generic
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  34) implementation (there's lots of outdated locking leftovers in various
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  35) implementations), and then remove it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  36) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  37) Contact: Daniel Vetter, respective driver maintainers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  38) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  39) Level: Intermediate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  40) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  41) Convert existing KMS drivers to atomic modesetting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  42) --------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  43) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  44) 3.19 has the atomic modeset interfaces and helpers, so drivers can now be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  45) converted over. Modern compositors like Wayland or Surfaceflinger on Android
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  46) really want an atomic modeset interface, so this is all about the bright
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  47) future.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  48) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  49) There is a conversion guide for atomic and all you need is a GPU for a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  50) non-converted driver (again virtual HW drivers for KVM are still all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  51) suitable).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  52) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  53) As part of this drivers also need to convert to universal plane (which means
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  54) exposing primary & cursor as proper plane objects). But that's much easier to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  55) do by directly using the new atomic helper driver callbacks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  56) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  57) Contact: Daniel Vetter, respective driver maintainers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  58) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  59) Level: Advanced
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  60) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  61) Clean up the clipped coordination confusion around planes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  62) ---------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  63) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  64) We have a helper to get this right with drm_plane_helper_check_update(), but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  65) it's not consistently used. This should be fixed, preferrably in the atomic
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  66) helpers (and drivers then moved over to clipped coordinates). Probably the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  67) helper should also be moved from drm_plane_helper.c to the atomic helpers, to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  68) avoid confusion - the other helpers in that file are all deprecated legacy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  69) helpers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  70) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  71) Contact: Ville Syrjälä, Daniel Vetter, driver maintainers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  72) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  73) Level: Advanced
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  74) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  75) Improve plane atomic_check helpers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  76) ----------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  77) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  78) Aside from the clipped coordinates right above there's a few suboptimal things
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  79) with the current helpers:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  80) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  81) - drm_plane_helper_funcs->atomic_check gets called for enabled or disabled
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  82)   planes. At best this seems to confuse drivers, worst it means they blow up
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  83)   when the plane is disabled without the CRTC. The only special handling is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  84)   resetting values in the plane state structures, which instead should be moved
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  85)   into the drm_plane_funcs->atomic_duplicate_state functions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  86) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  87) - Once that's done, helpers could stop calling ->atomic_check for disabled
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  88)   planes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  89) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  90) - Then we could go through all the drivers and remove the more-or-less confused
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  91)   checks for plane_state->fb and plane_state->crtc.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  92) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  93) Contact: Daniel Vetter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  94) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  95) Level: Advanced
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  96) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  97) Convert early atomic drivers to async commit helpers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  98) ----------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  99) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) For the first year the atomic modeset helpers didn't support asynchronous /
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) nonblocking commits, and every driver had to hand-roll them. This is fixed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) now, but there's still a pile of existing drivers that easily could be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) converted over to the new infrastructure.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) One issue with the helpers is that they require that drivers handle completion
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) events for atomic commits correctly. But fixing these bugs is good anyway.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) Contact: Daniel Vetter, respective driver maintainers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) Level: Advanced
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) Fallout from atomic KMS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) -----------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) ``drm_atomic_helper.c`` provides a batch of functions which implement legacy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) IOCTLs on top of the new atomic driver interface. Which is really nice for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) gradual conversion of drivers, but unfortunately the semantic mismatches are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) a bit too severe. So there's some follow-up work to adjust the function
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) interfaces to fix these issues:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) * atomic needs the lock acquire context. At the moment that's passed around
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122)   implicitly with some horrible hacks, and it's also allocate with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123)   ``GFP_NOFAIL`` behind the scenes. All legacy paths need to start allocating
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124)   the acquire context explicitly on stack and then also pass it down into
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125)   drivers explicitly so that the legacy-on-atomic functions can use them.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127)   Except for some driver code this is done. This task should be finished by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128)   adding WARN_ON(!drm_drv_uses_atomic_modeset) in drm_modeset_lock_all().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) * A bunch of the vtable hooks are now in the wrong place: DRM has a split
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131)   between core vfunc tables (named ``drm_foo_funcs``), which are used to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132)   implement the userspace ABI. And then there's the optional hooks for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133)   helper libraries (name ``drm_foo_helper_funcs``), which are purely for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134)   internal use. Some of these hooks should be move from ``_funcs`` to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135)   ``_helper_funcs`` since they are not part of the core ABI. There's a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136)   ``FIXME`` comment in the kerneldoc for each such case in ``drm_crtc.h``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) Contact: Daniel Vetter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) Level: Intermediate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) Get rid of dev->struct_mutex from GEM drivers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) ---------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) ``dev->struct_mutex`` is the Big DRM Lock from legacy days and infested
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) everything. Nowadays in modern drivers the only bit where it's mandatory is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) serializing GEM buffer object destruction. Which unfortunately means drivers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) have to keep track of that lock and either call ``unreference`` or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) ``unreference_locked`` depending upon context.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) Core GEM doesn't have a need for ``struct_mutex`` any more since kernel 4.8,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) and there's a ``gem_free_object_unlocked`` callback for any drivers which are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) entirely ``struct_mutex`` free.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) For drivers that need ``struct_mutex`` it should be replaced with a driver-
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) private lock. The tricky part is the BO free functions, since those can't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) reliably take that lock any more. Instead state needs to be protected with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) suitable subordinate locks or some cleanup work pushed to a worker thread. For
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) performance-critical drivers it might also be better to go with a more
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) fine-grained per-buffer object and per-context lockings scheme. Currently only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) the ``msm`` and `i915` drivers use ``struct_mutex``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) Contact: Daniel Vetter, respective driver maintainers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) Level: Advanced
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) Convert logging to drm_* functions with drm_device paramater
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) ------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) For drivers which could have multiple instances, it is necessary to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) differentiate between which is which in the logs. Since DRM_INFO/WARN/ERROR
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) don't do this, drivers used dev_info/warn/err to make this differentiation. We
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) now have drm_* variants of the drm print functions, so we can start to convert
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) those drivers back to using drm-formatted specific log messages.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) Before you start this conversion please contact the relevant maintainers to make
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) sure your work will be merged - not everyone agrees that the DRM dmesg macros
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) are better.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) Contact: Sean Paul, Maintainer of the driver you plan to convert
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) Level: Starter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) Convert drivers to use simple modeset suspend/resume
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) ----------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) Most drivers (except i915 and nouveau) that use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) drm_atomic_helper_suspend/resume() can probably be converted to use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) drm_mode_config_helper_suspend/resume(). Also there's still open-coded version
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) of the atomic suspend/resume code in older atomic modeset drivers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) Contact: Maintainer of the driver you plan to convert
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) Level: Intermediate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) Convert drivers to use drm_fbdev_generic_setup()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) ------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) Most drivers can use drm_fbdev_generic_setup(). Driver have to implement
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) atomic modesetting and GEM vmap support. Current generic fbdev emulation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) expects the framebuffer in system memory (or system-like memory).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) Contact: Maintainer of the driver you plan to convert
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) Level: Intermediate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) -----------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) A lot more drivers could be switched over to the drm_gem_framebuffer helpers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) Various hold-ups:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) - Need to switch over to the generic dirty tracking code using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214)   drm_atomic_helper_dirtyfb first (e.g. qxl).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) - Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217)   setup code can't be deleted.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) - Many drivers wrap drm_gem_fb_create() only to check for valid formats. For
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220)   atomic drivers we could check for valid formats by calling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221)   drm_plane_check_pixel_format() against all planes, and pass if any plane
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222)   supports the format. For non-atomic that's not possible since like the format
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223)   list for the primary plane is fake and we'd therefor reject valid formats.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) - Many drivers subclass drm_framebuffer, we'd need a embedding compatible
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226)   version of the varios drm_gem_fb_create functions. Maybe called
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227)   drm_gem_fb_create/_with_dirty/_with_funcs as needed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) Contact: Daniel Vetter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) Level: Intermediate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) Clean up mmap forwarding
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) ------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) A lot of drivers forward gem mmap calls to dma-buf mmap for imported buffers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) And also a lot of them forward dma-buf mmap to the gem mmap implementations.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) There's drm_gem_prime_mmap() for this now, but still needs to be rolled out.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) Contact: Daniel Vetter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) Level: Intermediate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) Generic fbdev defio support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) ---------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) The defio support code in the fbdev core has some very specific requirements,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) which means drivers need to have a special framebuffer for fbdev. The main
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) issue is that it uses some fields in struct page itself, which breaks shmem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) gem objects (and other things). To support defio, affected drivers require
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) the use of a shadow buffer, which may add CPU and memory overhead.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) Possible solution would be to write our own defio mmap code in the drm fbdev
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) emulation. It would need to fully wrap the existing mmap ops, forwarding
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) everything after it has done the write-protect/mkwrite trickery:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) - In the drm_fbdev_fb_mmap helper, if we need defio, change the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258)   default page prots to write-protected with something like this::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260)       vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) - Set the mkwrite and fsync callbacks with similar implementions to the core
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263)   fbdev defio stuff. These should all work on plain ptes, they don't actually
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264)   require a struct page.  uff. These should all work on plain ptes, they don't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265)   actually require a struct page.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) - Track the dirty pages in a separate structure (bitfield with one bit per page
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268)   should work) to avoid clobbering struct page.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) Might be good to also have some igt testcases for this.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) Contact: Daniel Vetter, Noralf Tronnes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) Level: Advanced
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276) idr_init_base()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) ---------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) DRM core&drivers uses a lot of idr (integer lookup directories) for mapping
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) userspace IDs to internal objects, and in most places ID=0 means NULL and hence
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) is never used. Switching to idr_init_base() for these would make the idr more
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282) efficient.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) Contact: Daniel Vetter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) Level: Starter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) struct drm_gem_object_funcs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) ---------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291) GEM objects can now have a function table instead of having the callbacks on the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) DRM driver struct. This is now the preferred way and drivers can be moved over.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294) We also need a 2nd version of the CMA define that doesn't require the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295) vmapping to be present (different hook for prime importing). Plus this needs to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296) be rolled out to all drivers using their own implementations, too.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) Level: Intermediate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300) Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301) ---------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) For cases where drivers are attempting to grab the modeset locks with a local
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304) acquire context. Replace the boilerplate code surrounding
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN() and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306) DRM_MODESET_LOCK_ALL_END() instead.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308) This should also be done for all places where drm_modeset_lock_all() is still
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309) used.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311) As a reference, take a look at the conversions already completed in drm core.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313) Contact: Sean Paul, respective driver maintainers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315) Level: Starter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317) Rename CMA helpers to DMA helpers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318) ---------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320) CMA (standing for contiguous memory allocator) is really a bit an accident of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321) what these were used for first, a much better name would be DMA helpers. In the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322) text these should even be called coherent DMA memory helpers (so maybe CDM, but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323) no one knows what that means) since underneath they just use dma_alloc_coherent.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325) Contact: Laurent Pinchart, Daniel Vetter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327) Level: Intermediate (mostly because it is a huge tasks without good partial
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328) milestones, not technically itself that challenging)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330) connector register/unregister fixes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331) -----------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333) - For most connectors it's a no-op to call drm_connector_register/unregister
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334)   directly from driver code, drm_dev_register/unregister take care of this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335)   already. We can remove all of them.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) - For dp drivers it's a bit more a mess, since we need the connector to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338)   registered when calling drm_dp_aux_register. Fix this by instead calling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339)   drm_dp_aux_init, and moving the actual registering into a late_register
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340)   callback as recommended in the kerneldoc.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342) Level: Intermediate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344) Remove load/unload callbacks from all non-DRIVER_LEGACY drivers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345) ---------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347) The load/unload callbacks in struct &drm_driver are very much midlayers, plus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348) for historical reasons they get the ordering wrong (and we can't fix that)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349) between setting up the &drm_driver structure and calling drm_dev_register().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351) - Rework drivers to no longer use the load/unload callbacks, directly coding the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352)   load/unload sequence into the driver's probe function.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354) - Once all non-DRIVER_LEGACY drivers are converted, disallow the load/unload
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355)   callbacks for all modern drivers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357) Contact: Daniel Vetter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359) Level: Intermediate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361) Replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362) ---------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364) Once EDID is parsed, the monitor HDMI support information is available through
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365) drm_display_info.is_hdmi. Many drivers still call drm_detect_hdmi_monitor() to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366) retrieve the same information, which is less efficient.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368) Audit each individual driver calling drm_detect_hdmi_monitor() and switch to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369) drm_display_info.is_hdmi if applicable.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 370) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 371) Contact: Laurent Pinchart, respective driver maintainers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 372) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 373) Level: Intermediate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 374) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 375) Consolidate custom driver modeset properties
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 376) --------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 377) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 378) Before atomic modeset took place, many drivers where creating their own
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 379) properties. Among other things, atomic brought the requirement that custom,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 380) driver specific properties should not be used.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 381) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 382) For this task, we aim to introduce core helpers or reuse the existing ones
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 383) if available:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 384) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 385) A quick, unconfirmed, examples list.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 386) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 387) Introduce core helpers:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 388) - audio (amdgpu, intel, gma500, radeon)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 389) - brightness, contrast, etc (armada, nouveau) - overlay only (?)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 390) - broadcast rgb (gma500, intel)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 391) - colorkey (armada, nouveau, rcar) - overlay only (?)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 392) - dither (amdgpu, nouveau, radeon) - varies across drivers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 393) - underscan family (amdgpu, radeon, nouveau)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 394) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 395) Already in core:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 396) - colorspace (sti)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 397) - tv format names, enhancements (gma500, intel)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 398) - tv overscan, margins, etc. (gma500, intel)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 399) - zorder (omapdrm) - same as zpos (?)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 400) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 401) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 402) Contact: Emil Velikov, respective driver maintainers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 403) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 404) Level: Intermediate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 405) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 406) Plumb drm_atomic_state all over
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 407) -------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 408) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 409) Currently various atomic functions take just a single or a handful of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 410) object states (eg. plane state). While that single object state can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 411) suffice for some simple cases, we often have to dig out additional
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 412) object states for dealing with various dependencies between the individual
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 413) objects or the hardware they represent. The process of digging out the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 414) additional states is rather non-intuitive and error prone.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 415) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 416) To fix that most functions should rather take the overall
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 417) drm_atomic_state as one of their parameters. The other parameters
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 418) would generally be the object(s) we mainly want to interact with.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 419) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 420) For example, instead of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 421) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 422) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 423) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 424)    int (*atomic_check)(struct drm_plane *plane, struct drm_plane_state *state);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 425) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 426) we would have something like
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 427) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 428) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 429) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 430)    int (*atomic_check)(struct drm_plane *plane, struct drm_atomic_state *state);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 431) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 432) The implementation can then trivially gain access to any required object
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 433) state(s) via drm_atomic_get_plane_state(), drm_atomic_get_new_plane_state(),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 434) drm_atomic_get_old_plane_state(), and their equivalents for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 435) other object types.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 436) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 437) Additionally many drivers currently access the object->state pointer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 438) directly in their commit functions. That is not going to work if we
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 439) eg. want to allow deeper commit pipelines as those pointers could
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 440) then point to the states corresponding to a future commit instead of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 441) the current commit we're trying to process. Also non-blocking commits
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 442) execute locklessly so there are serious concerns with dereferencing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 443) the object->state pointers without holding the locks that protect them.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 444) Use of drm_atomic_get_new_plane_state(), drm_atomic_get_old_plane_state(),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 445) etc. avoids these problems as well since they relate to a specific
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 446) commit via the passed in drm_atomic_state.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 447) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 448) Contact: Ville Syrjälä, Daniel Vetter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 449) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 450) Level: Intermediate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 451) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 452) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 453) Core refactorings
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 454) =================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 455) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 456) Make panic handling work
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 457) ------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 458) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 459) This is a really varied tasks with lots of little bits and pieces:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 460) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 461) * The panic path can't be tested currently, leading to constant breaking. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 462)   main issue here is that panics can be triggered from hardirq contexts and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 463)   hence all panic related callback can run in hardirq context. It would be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 464)   awesome if we could test at least the fbdev helper code and driver code by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 465)   e.g. trigger calls through drm debugfs files. hardirq context could be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 466)   achieved by using an IPI to the local processor.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 467) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 468) * There's a massive confusion of different panic handlers. DRM fbdev emulation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 469)   helpers have one, but on top of that the fbcon code itself also has one. We
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 470)   need to make sure that they stop fighting over each another.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 471) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 472) * ``drm_can_sleep()`` is a mess. It hides real bugs in normal operations and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 473)   isn't a full solution for panic paths. We need to make sure that it only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 474)   returns true if there's a panic going on for real, and fix up all the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 475)   fallout.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 476) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 477) * The panic handler must never sleep, which also means it can't ever
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 478)   ``mutex_lock()``. Also it can't grab any other lock unconditionally, not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 479)   even spinlocks (because NMI and hardirq can panic too). We need to either
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 480)   make sure to not call such paths, or trylock everything. Really tricky.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 481) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 482) * For the above locking troubles reasons it's pretty much impossible to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 483)   attempt a synchronous modeset from panic handlers. The only thing we could
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 484)   try to achive is an atomic ``set_base`` of the primary plane, and hope that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 485)   it shows up. Everything else probably needs to be delayed to some worker or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 486)   something else which happens later on. Otherwise it just kills the box
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 487)   harder, prevent the panic from going out on e.g. netconsole.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 488) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 489) * There's also proposal for a simplied DRM console instead of the full-blown
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 490)   fbcon and DRM fbdev emulation. Any kind of panic handling tricks should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 491)   obviously work for both console, in case we ever get kmslog merged.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 492) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 493) Contact: Daniel Vetter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 494) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 495) Level: Advanced
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 496) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 497) Clean up the debugfs support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 498) ----------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 499) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 500) There's a bunch of issues with it:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 501) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 502) - The drm_info_list ->show() function doesn't even bother to cast to the drm
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 503)   structure for you. This is lazy.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 504) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 505) - We probably want to have some support for debugfs files on crtc/connectors and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 506)   maybe other kms objects directly in core. There's even drm_print support in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 507)   the funcs for these objects to dump kms state, so it's all there. And then the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 508)   ->show() functions should obviously give you a pointer to the right object.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 509) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 510) - The drm_info_list stuff is centered on drm_minor instead of drm_device. For
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 511)   anything we want to print drm_device (or maybe drm_file) is the right thing.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 512) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 513) - The drm_driver->debugfs_init hooks we have is just an artifact of the old
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 514)   midlayered load sequence. DRM debugfs should work more like sysfs, where you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 515)   can create properties/files for an object anytime you want, and the core
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 516)   takes care of publishing/unpuplishing all the files at register/unregister
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 517)   time. Drivers shouldn't need to worry about these technicalities, and fixing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 518)   this (together with the drm_minor->drm_device move) would allow us to remove
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 519)   debugfs_init.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 520) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 521) - Drop the return code and error checking from all debugfs functions. Greg KH is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 522)   working on this already.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 523) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 524) Contact: Daniel Vetter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 525) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 526) Level: Intermediate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 527) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 528) KMS cleanups
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 529) ------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 530) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 531) Some of these date from the very introduction of KMS in 2008 ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 532) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 533) - Make ->funcs and ->helper_private vtables optional. There's a bunch of empty
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 534)   function tables in drivers, but before we can remove them we need to make sure
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 535)   that all the users in helpers and drivers do correctly check for a NULL
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 536)   vtable.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 537) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 538) - Cleanup up the various ->destroy callbacks. A lot of them just wrapt the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 539)   drm_*_cleanup implementations and can be removed. Some tack a kfree() at the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 540)   end, for which we could add drm_*_cleanup_kfree(). And then there's the (for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 541)   historical reasons) misnamed drm_primary_helper_destroy() function.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 542) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 543) Level: Intermediate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 544) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 545) Remove automatic page mapping from dma-buf importing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 546) ----------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 547) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 548) When importing dma-bufs, the dma-buf and PRIME frameworks automatically map
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 549) imported pages into the importer's DMA area. drm_gem_prime_fd_to_handle() and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 550) drm_gem_prime_handle_to_fd() require that importers call dma_buf_attach()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 551) even if they never do actual device DMA, but only CPU access through
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 552) dma_buf_vmap(). This is a problem for USB devices, which do not support DMA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 553) operations.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 554) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 555) To fix the issue, automatic page mappings should be removed from the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 556) buffer-sharing code. Fixing this is a bit more involved, since the import/export
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 557) cache is also tied to &drm_gem_object.import_attach. Meanwhile we paper over
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 558) this problem for USB devices by fishing out the USB host controller device, as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 559) long as that supports DMA. Otherwise importing can still needlessly fail.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 560) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 561) Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 562) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 563) Level: Advanced
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 564) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 565) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 566) Better Testing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 567) ==============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 568) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 569) Enable trinity for DRM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 570) ----------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 571) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 572) And fix up the fallout. Should be really interesting ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 573) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 574) Level: Advanced
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 575) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 576) Make KMS tests in i-g-t generic
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 577) -------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 578) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 579) The i915 driver team maintains an extensive testsuite for the i915 DRM driver,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 580) including tons of testcases for corner-cases in the modesetting API. It would
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 581) be awesome if those tests (at least the ones not relying on Intel-specific GEM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 582) features) could be made to run on any KMS driver.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 583) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 584) Basic work to run i-g-t tests on non-i915 is done, what's now missing is mass-
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 585) converting things over. For modeset tests we also first need a bit of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 586) infrastructure to use dumb buffers for untiled buffers, to be able to run all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 587) the non-i915 specific modeset tests.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 588) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 589) Level: Advanced
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 590) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 591) Extend virtual test driver (VKMS)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 592) ---------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 593) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 594) See the documentation of :ref:`VKMS <vkms>` for more details. This is an ideal
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 595) internship task, since it only requires a virtual machine and can be sized to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 596) fit the available time.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 597) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 598) Contact: Daniel Vetter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 599) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 600) Level: See details
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 601) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 602) Backlight Refactoring
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 603) ---------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 604) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 605) Backlight drivers have a triple enable/disable state, which is a bit overkill.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 606) Plan to fix this:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 607) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 608) 1. Roll out backlight_enable() and backlight_disable() helpers everywhere. This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 609)    has started already.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 610) 2. In all, only look at one of the three status bits set by the above helpers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 611) 3. Remove the other two status bits.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 612) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 613) Contact: Daniel Vetter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 614) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 615) Level: Intermediate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 616) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 617) Driver Specific
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 618) ===============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 619) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 620) AMD DC Display Driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 621) ---------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 622) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 623) AMD DC is the display driver for AMD devices starting with Vega. There has been
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 624) a bunch of progress cleaning it up but there's still plenty of work to be done.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 625) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 626) See drivers/gpu/drm/amd/display/TODO for tasks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 627) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 628) Contact: Harry Wentland, Alex Deucher
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 629) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 630) Bootsplash
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 631) ==========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 632) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 633) There is support in place now for writing internal DRM clients making it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 634) possible to pick up the bootsplash work that was rejected because it was written
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 635) for fbdev.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 636) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 637) - [v6,8/8] drm/client: Hack: Add bootsplash example
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 638)   https://patchwork.freedesktop.org/patch/306579/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 639) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 640) - [RFC PATCH v2 00/13] Kernel based bootsplash
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 641)   https://lkml.org/lkml/2017/12/13/764
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 642) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 643) Contact: Sam Ravnborg
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 644) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 645) Level: Advanced
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 646) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 647) Outside DRM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 648) ===========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 649) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 650) Convert fbdev drivers to DRM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 651) ----------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 652) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 653) There are plenty of fbdev drivers for older hardware. Some hwardware has
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 654) become obsolete, but some still provides good(-enough) framebuffers. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 655) drivers that are still useful should be converted to DRM and afterwards
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 656) removed from fbdev.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 657) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 658) Very simple fbdev drivers can best be converted by starting with a new
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 659) DRM driver. Simple KMS helpers and SHMEM should be able to handle any
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 660) existing hardware. The new driver's call-back functions are filled from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 661) existing fbdev code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 662) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 663) More complex fbdev drivers can be refactored step-by-step into a DRM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 664) driver with the help of the DRM fbconv helpers. [1] These helpers provide
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 665) the transition layer between the DRM core infrastructure and the fbdev
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 666) driver interface. Create a new DRM driver on top of the fbconv helpers,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 667) copy over the fbdev driver, and hook it up to the DRM code. Examples for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 668) several fbdev drivers are available at [1] and a tutorial of this process
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 669) available at [2]. The result is a primitive DRM driver that can run X11
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 670) and Weston.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 671) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 672)  - [1] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 673)  - [2] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 674) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 675) Contact: Thomas Zimmermann <tzimmermann@suse.de>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 676) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 677) Level: Advanced