| 1 | .. _todo:
|
| 2 |
|
| 3 | =========
|
| 4 | TODO list
|
| 5 | =========
|
| 6 |
|
| 7 | This section contains a list of smaller janitorial tasks in the kernel DRM
|
| 8 | graphics subsystem useful as newbie projects. Or for slow rainy days.
|
| 9 |
|
| 10 | Difficulty
|
| 11 | ----------
|
| 12 |
|
| 13 | To make it easier task are categorized into different levels:
|
| 14 |
|
| 15 | Starter: Good tasks to get started with the DRM subsystem.
|
| 16 |
|
| 17 | Intermediate: Tasks which need some experience with working in the DRM
|
| 18 | subsystem, or some specific GPU/display graphics knowledge. For debugging issue
|
| 19 | it's good to have the relevant hardware (or a virtual driver set up) available
|
| 20 | for testing.
|
| 21 |
|
| 22 | Advanced: Tricky tasks that need fairly good understanding of the DRM subsystem
|
| 23 | and graphics topics. Generally need the relevant hardware for development and
|
| 24 | testing.
|
| 25 |
|
| 26 | Expert: Only attempt these if you've successfully completed some tricky
|
| 27 | refactorings already and are an expert in the specific area
|
| 28 |
|
| 29 | Subsystem-wide refactorings
|
| 30 | ===========================
|
| 31 |
|
| 32 | Open-code drm_simple_encoder_init()
|
| 33 | -----------------------------------
|
| 34 |
|
| 35 | The helper drm_simple_encoder_init() was supposed to simplify encoder
|
| 36 | initialization. Instead it only added an intermediate layer between atomic
|
| 37 | modesetting and the DRM driver.
|
| 38 |
|
| 39 | The task here is to remove drm_simple_encoder_init(). Search for a driver
|
| 40 | that calls drm_simple_encoder_init() and inline the helper. The driver will
|
| 41 | also need its own instance of drm_encoder_funcs.
|
| 42 |
|
| 43 | Contact: Thomas Zimmermann, respective driver maintainer
|
| 44 |
|
| 45 | Level: Easy
|
| 46 |
|
| 47 | Replace struct drm_simple_display_pipe with regular atomic helpers
|
| 48 | ------------------------------------------------------------------
|
| 49 |
|
| 50 | The data type struct drm_simple_display_pipe and its helpers were supposed
|
| 51 | to simplify driver development. Instead they only added an intermediate layer
|
| 52 | between atomic modesetting and the DRM driver.
|
| 53 |
|
| 54 | There are still drivers that use drm_simple_display_pipe. The task here is to
|
| 55 | convert them to use regular atomic helpers. Search for a driver that calls
|
| 56 | drm_simple_display_pipe_init() and inline all helpers from drm_simple_kms_helper.c
|
| 57 | into the driver, such that no simple-KMS interfaces are required. Please also
|
| 58 | rename all inlined functions according to driver conventions.
|
| 59 |
|
| 60 | Contact: Thomas Zimmermann, respective driver maintainer
|
| 61 |
|
| 62 | Level: Easy
|
| 63 |
|
| 64 | Remove custom dumb_map_offset implementations
|
| 65 | ---------------------------------------------
|
| 66 |
|
| 67 | All GEM based drivers should be using drm_gem_create_mmap_offset() instead.
|
| 68 | Audit each individual driver, make sure it'll work with the generic
|
| 69 | implementation (there's lots of outdated locking leftovers in various
|
| 70 | implementations), and then remove it.
|
| 71 |
|
| 72 | Contact: Simona Vetter, respective driver maintainers
|
| 73 |
|
| 74 | Level: Intermediate
|
| 75 |
|
| 76 | Convert existing KMS drivers to atomic modesetting
|
| 77 | --------------------------------------------------
|
| 78 |
|
| 79 | 3.19 has the atomic modeset interfaces and helpers, so drivers can now be
|
| 80 | converted over. Modern compositors like Wayland or Surfaceflinger on Android
|
| 81 | really want an atomic modeset interface, so this is all about the bright
|
| 82 | future.
|
| 83 |
|
| 84 | There is a conversion guide for atomic and all you need is a GPU for a
|
| 85 | non-converted driver. The "Atomic mode setting design overview" series
|
| 86 | at LWN.net can also be helpful.
|
| 87 |
|
| 88 | As part of this drivers also need to convert to universal plane (which means
|
| 89 | exposing primary & cursor as proper plane objects). But that's much easier to
|
| 90 | do by directly using the new atomic helper driver callbacks.
|
| 91 |
|
| 92 | .. [1] https://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html
|
| 93 | .. [2] https://lwn.net/Articles/653071/
|
| 94 | .. [3] https://lwn.net/Articles/653466/
|
| 95 |
|
| 96 | Contact: Simona Vetter, respective driver maintainers
|
| 97 |
|
| 98 | Level: Advanced
|
| 99 |
|
| 100 | Clean up the clipped coordination confusion around planes
|
| 101 | ---------------------------------------------------------
|
| 102 |
|
| 103 | We have a helper to get this right with drm_plane_helper_check_update(), but
|
| 104 | it's not consistently used. This should be fixed, preferably in the atomic
|
| 105 | helpers (and drivers then moved over to clipped coordinates). Probably the
|
| 106 | helper should also be moved from drm_plane_helper.c to the atomic helpers, to
|
| 107 | avoid confusion - the other helpers in that file are all deprecated legacy
|
| 108 | helpers.
|
| 109 |
|
| 110 | Contact: Ville Syrjälä, Simona Vetter, driver maintainers
|
| 111 |
|
| 112 | Level: Advanced
|
| 113 |
|
| 114 | Improve plane atomic_check helpers
|
| 115 | ----------------------------------
|
| 116 |
|
| 117 | Aside from the clipped coordinates right above there's a few suboptimal things
|
| 118 | with the current helpers:
|
| 119 |
|
| 120 | - drm_plane_helper_funcs->atomic_check gets called for enabled or disabled
|
| 121 | planes. At best this seems to confuse drivers, worst it means they blow up
|
| 122 | when the plane is disabled without the CRTC. The only special handling is
|
| 123 | resetting values in the plane state structures, which instead should be moved
|
| 124 | into the drm_plane_funcs->atomic_duplicate_state functions.
|
| 125 |
|
| 126 | - Once that's done, helpers could stop calling ->atomic_check for disabled
|
| 127 | planes.
|
| 128 |
|
| 129 | - Then we could go through all the drivers and remove the more-or-less confused
|
| 130 | checks for plane_state->fb and plane_state->crtc.
|
| 131 |
|
| 132 | Contact: Simona Vetter
|
| 133 |
|
| 134 | Level: Advanced
|
| 135 |
|
| 136 | Convert early atomic drivers to async commit helpers
|
| 137 | ----------------------------------------------------
|
| 138 |
|
| 139 | For the first year the atomic modeset helpers didn't support asynchronous /
|
| 140 | nonblocking commits, and every driver had to hand-roll them. This is fixed
|
| 141 | now, but there's still a pile of existing drivers that easily could be
|
| 142 | converted over to the new infrastructure.
|
| 143 |
|
| 144 | One issue with the helpers is that they require that drivers handle completion
|
| 145 | events for atomic commits correctly. But fixing these bugs is good anyway.
|
| 146 |
|
| 147 | Somewhat related is the legacy_cursor_update hack, which should be replaced with
|
| 148 | the new atomic_async_check/commit functionality in the helpers in drivers that
|
| 149 | still look at that flag.
|
| 150 |
|
| 151 | Contact: Simona Vetter, respective driver maintainers
|
| 152 |
|
| 153 | Level: Advanced
|
| 154 |
|
| 155 | Fallout from atomic KMS
|
| 156 | -----------------------
|
| 157 |
|
| 158 | ``drm_atomic_helper.c`` provides a batch of functions which implement legacy
|
| 159 | IOCTLs on top of the new atomic driver interface. Which is really nice for
|
| 160 | gradual conversion of drivers, but unfortunately the semantic mismatches are
|
| 161 | a bit too severe. So there's some follow-up work to adjust the function
|
| 162 | interfaces to fix these issues:
|
| 163 |
|
| 164 | * atomic needs the lock acquire context. At the moment that's passed around
|
| 165 | implicitly with some horrible hacks, and it's also allocate with
|
| 166 | ``GFP_NOFAIL`` behind the scenes. All legacy paths need to start allocating
|
| 167 | the acquire context explicitly on stack and then also pass it down into
|
| 168 | drivers explicitly so that the legacy-on-atomic functions can use them.
|
| 169 |
|
| 170 | Except for some driver code this is done. This task should be finished by
|
| 171 | adding WARN_ON(!drm_drv_uses_atomic_modeset) in drm_modeset_lock_all().
|
| 172 |
|
| 173 | * A bunch of the vtable hooks are now in the wrong place: DRM has a split
|
| 174 | between core vfunc tables (named ``drm_foo_funcs``), which are used to
|
| 175 | implement the userspace ABI. And then there's the optional hooks for the
|
| 176 | helper libraries (name ``drm_foo_helper_funcs``), which are purely for
|
| 177 | internal use. Some of these hooks should be move from ``_funcs`` to
|
| 178 | ``_helper_funcs`` since they are not part of the core ABI. There's a
|
| 179 | ``FIXME`` comment in the kerneldoc for each such case in ``drm_crtc.h``.
|
| 180 |
|
| 181 | Contact: Simona Vetter
|
| 182 |
|
| 183 | Level: Intermediate
|
| 184 |
|
| 185 | Move Buffer Object Locking to dma_resv_lock()
|
| 186 | ---------------------------------------------
|
| 187 |
|
| 188 | Many drivers have their own per-object locking scheme, usually using
|
| 189 | mutex_lock(). This causes all kinds of trouble for buffer sharing, since
|
| 190 | depending which driver is the exporter and importer, the locking hierarchy is
|
| 191 | reversed.
|
| 192 |
|
| 193 | To solve this we need one standard per-object locking mechanism, which is
|
| 194 | dma_resv_lock(). This lock needs to be called as the outermost lock, with all
|
| 195 | other driver specific per-object locks removed. The problem is that rolling out
|
| 196 | the actual change to the locking contract is a flag day, due to struct dma_buf
|
| 197 | buffer sharing.
|
| 198 |
|
| 199 | Level: Expert
|
| 200 |
|
| 201 | Convert logging to drm_* functions with drm_device parameter
|
| 202 | ------------------------------------------------------------
|
| 203 |
|
| 204 | For drivers which could have multiple instances, it is necessary to
|
| 205 | differentiate between which is which in the logs. Since DRM_INFO/WARN/ERROR
|
| 206 | don't do this, drivers used dev_info/warn/err to make this differentiation. We
|
| 207 | now have drm_* variants of the drm print functions, so we can start to convert
|
| 208 | those drivers back to using drm-formatted specific log messages.
|
| 209 |
|
| 210 | Before you start this conversion please contact the relevant maintainers to make
|
| 211 | sure your work will be merged - not everyone agrees that the DRM dmesg macros
|
| 212 | are better.
|
| 213 |
|
| 214 | Contact: Sean Paul, Maintainer of the driver you plan to convert
|
| 215 |
|
| 216 | Level: Starter
|
| 217 |
|
| 218 | Convert drivers to use simple modeset suspend/resume
|
| 219 | ----------------------------------------------------
|
| 220 |
|
| 221 | Most drivers (except i915 and nouveau) that use
|
| 222 | drm_atomic_helper_suspend/resume() can probably be converted to use
|
| 223 | drm_mode_config_helper_suspend/resume(). Also there's still open-coded version
|
| 224 | of the atomic suspend/resume code in older atomic modeset drivers.
|
| 225 |
|
| 226 | Contact: Maintainer of the driver you plan to convert
|
| 227 |
|
| 228 | Level: Intermediate
|
| 229 |
|
| 230 | Reimplement functions in drm_fbdev_fb_ops without fbdev
|
| 231 | -------------------------------------------------------
|
| 232 |
|
| 233 | A number of callback functions in drm_fbdev_fb_ops could benefit from
|
| 234 | being rewritten without dependencies on the fbdev module. Some of the
|
| 235 | helpers could further benefit from using struct iosys_map instead of
|
| 236 | raw pointers.
|
| 237 |
|
| 238 | Contact: Thomas Zimmermann <[email protected]>, Simona Vetter
|
| 239 |
|
| 240 | Level: Advanced
|
| 241 |
|
| 242 | Benchmark and optimize blitting and format-conversion function
|
| 243 | --------------------------------------------------------------
|
| 244 |
|
| 245 | Drawing to display memory quickly is crucial for many applications'
|
| 246 | performance.
|
| 247 |
|
| 248 | On at least x86-64, sys_imageblit() is significantly slower than
|
| 249 | cfb_imageblit(), even though both use the same blitting algorithm and
|
| 250 | the latter is written for I/O memory. It turns out that cfb_imageblit()
|
| 251 | uses movl instructions, while sys_imageblit apparently does not. This
|
| 252 | seems to be a problem with gcc's optimizer. DRM's format-conversion
|
| 253 | helpers might be subject to similar issues.
|
| 254 |
|
| 255 | Benchmark and optimize fbdev's sys_() helpers and DRM's format-conversion
|
| 256 | helpers. In cases that can be further optimized, maybe implement a different
|
| 257 | algorithm. For micro-optimizations, use movl/movq instructions explicitly.
|
| 258 | That might possibly require architecture-specific helpers (e.g., storel()
|
| 259 | storeq()).
|
| 260 |
|
| 261 | Contact: Thomas Zimmermann <[email protected]>
|
| 262 |
|
| 263 | Level: Intermediate
|
| 264 |
|
| 265 | drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
|
| 266 | -----------------------------------------------------------------
|
| 267 |
|
| 268 | A lot more drivers could be switched over to the drm_gem_framebuffer helpers.
|
| 269 | Various hold-ups:
|
| 270 |
|
| 271 | - Need to switch over to the generic dirty tracking code using
|
| 272 | drm_atomic_helper_dirtyfb first (e.g. qxl).
|
| 273 |
|
| 274 | - Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb
|
| 275 | setup code can't be deleted.
|
| 276 |
|
| 277 | - Need to switch to drm_gem_fb_create(), as now drm_gem_fb_create() checks for
|
| 278 | valid formats for atomic drivers.
|
| 279 |
|
| 280 | - Many drivers subclass drm_framebuffer, we'd need a embedding compatible
|
| 281 | version of the varios drm_gem_fb_create functions. Maybe called
|
| 282 | drm_gem_fb_create/_with_dirty/_with_funcs as needed.
|
| 283 |
|
| 284 | Contact: Simona Vetter
|
| 285 |
|
| 286 | Level: Intermediate
|
| 287 |
|
| 288 | Generic fbdev defio support
|
| 289 | ---------------------------
|
| 290 |
|
| 291 | The defio support code in the fbdev core has some very specific requirements,
|
| 292 | which means drivers need to have a special framebuffer for fbdev. The main
|
| 293 | issue is that it uses some fields in struct page itself, which breaks shmem
|
| 294 | gem objects (and other things). To support defio, affected drivers require
|
| 295 | the use of a shadow buffer, which may add CPU and memory overhead.
|
| 296 |
|
| 297 | Possible solution would be to write our own defio mmap code in the drm fbdev
|
| 298 | emulation. It would need to fully wrap the existing mmap ops, forwarding
|
| 299 | everything after it has done the write-protect/mkwrite trickery:
|
| 300 |
|
| 301 | - In the drm_fbdev_fb_mmap helper, if we need defio, change the
|
| 302 | default page prots to write-protected with something like this::
|
| 303 |
|
| 304 | vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot);
|
| 305 |
|
| 306 | - Set the mkwrite and fsync callbacks with similar implementions to the core
|
| 307 | fbdev defio stuff. These should all work on plain ptes, they don't actually
|
| 308 | require a struct page. uff. These should all work on plain ptes, they don't
|
| 309 | actually require a struct page.
|
| 310 |
|
| 311 | - Track the dirty pages in a separate structure (bitfield with one bit per page
|
| 312 | should work) to avoid clobbering struct page.
|
| 313 |
|
| 314 | Might be good to also have some igt testcases for this.
|
| 315 |
|
| 316 | Contact: Simona Vetter, Noralf Tronnes
|
| 317 |
|
| 318 | Level: Advanced
|
| 319 |
|
| 320 | connector register/unregister fixes
|
| 321 | -----------------------------------
|
| 322 |
|
| 323 | - For most connectors it's a no-op to call drm_connector_register/unregister
|
| 324 | directly from driver code, drm_dev_register/unregister take care of this
|
| 325 | already. We can remove all of them.
|
| 326 |
|
| 327 | - For dp drivers it's a bit more a mess, since we need the connector to be
|
| 328 | registered when calling drm_dp_aux_register. Fix this by instead calling
|
| 329 | drm_dp_aux_init, and moving the actual registering into a late_register
|
| 330 | callback as recommended in the kerneldoc.
|
| 331 |
|
| 332 | Level: Intermediate
|
| 333 |
|
| 334 | Remove load/unload callbacks
|
| 335 | ----------------------------
|
| 336 |
|
| 337 | The load/unload callbacks in struct &drm_driver are very much midlayers, plus
|
| 338 | for historical reasons they get the ordering wrong (and we can't fix that)
|
| 339 | between setting up the &drm_driver structure and calling drm_dev_register().
|
| 340 |
|
| 341 | - Rework drivers to no longer use the load/unload callbacks, directly coding the
|
| 342 | load/unload sequence into the driver's probe function.
|
| 343 |
|
| 344 | - Once all drivers are converted, remove the load/unload callbacks.
|
| 345 |
|
| 346 | Contact: Simona Vetter
|
| 347 |
|
| 348 | Level: Intermediate
|
| 349 |
|
| 350 | Replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
|
| 351 | ---------------------------------------------------------------
|
| 352 |
|
| 353 | Once EDID is parsed, the monitor HDMI support information is available through
|
| 354 | drm_display_info.is_hdmi. Many drivers still call drm_detect_hdmi_monitor() to
|
| 355 | retrieve the same information, which is less efficient.
|
| 356 |
|
| 357 | Audit each individual driver calling drm_detect_hdmi_monitor() and switch to
|
| 358 | drm_display_info.is_hdmi if applicable.
|
| 359 |
|
| 360 | Contact: Laurent Pinchart, respective driver maintainers
|
| 361 |
|
| 362 | Level: Intermediate
|
| 363 |
|
| 364 | Consolidate custom driver modeset properties
|
| 365 | --------------------------------------------
|
| 366 |
|
| 367 | Before atomic modeset took place, many drivers where creating their own
|
| 368 | properties. Among other things, atomic brought the requirement that custom,
|
| 369 | driver specific properties should not be used.
|
| 370 |
|
| 371 | For this task, we aim to introduce core helpers or reuse the existing ones
|
| 372 | if available:
|
| 373 |
|
| 374 | A quick, unconfirmed, examples list.
|
| 375 |
|
| 376 | Introduce core helpers:
|
| 377 | - audio (amdgpu, intel, gma500, radeon)
|
| 378 | - brightness, contrast, etc (armada, nouveau) - overlay only (?)
|
| 379 | - broadcast rgb (gma500, intel)
|
| 380 | - colorkey (armada, nouveau, rcar) - overlay only (?)
|
| 381 | - dither (amdgpu, nouveau, radeon) - varies across drivers
|
| 382 | - underscan family (amdgpu, radeon, nouveau)
|
| 383 |
|
| 384 | Already in core:
|
| 385 | - colorspace (sti)
|
| 386 | - tv format names, enhancements (gma500, intel)
|
| 387 | - tv overscan, margins, etc. (gma500, intel)
|
| 388 | - zorder (omapdrm) - same as zpos (?)
|
| 389 |
|
| 390 |
|
| 391 | Contact: Emil Velikov, respective driver maintainers
|
| 392 |
|
| 393 | Level: Intermediate
|
| 394 |
|
| 395 | Use struct iosys_map throughout codebase
|
| 396 | ----------------------------------------
|
| 397 |
|
| 398 | Pointers to shared device memory are stored in struct iosys_map. Each
|
| 399 | instance knows whether it refers to system or I/O memory. Most of the DRM-wide
|
| 400 | interface have been converted to use struct iosys_map, but implementations
|
| 401 | often still use raw pointers.
|
| 402 |
|
| 403 | The task is to use struct iosys_map where it makes sense.
|
| 404 |
|
| 405 | * Memory managers should use struct iosys_map for dma-buf-imported buffers.
|
| 406 | * TTM might benefit from using struct iosys_map internally.
|
| 407 | * Framebuffer copying and blitting helpers should operate on struct iosys_map.
|
| 408 |
|
| 409 | Contact: Thomas Zimmermann <[email protected]>, Christian König, Simona Vetter
|
| 410 |
|
| 411 | Level: Intermediate
|
| 412 |
|
| 413 | Review all drivers for setting struct drm_mode_config.{max_width,max_height} correctly
|
| 414 | --------------------------------------------------------------------------------------
|
| 415 |
|
| 416 | The values in struct drm_mode_config.{max_width,max_height} describe the
|
| 417 | maximum supported framebuffer size. It's the virtual screen size, but many
|
| 418 | drivers treat it like limitations of the physical resolution.
|
| 419 |
|
| 420 | The maximum width depends on the hardware's maximum scanline pitch. The
|
| 421 | maximum height depends on the amount of addressable video memory. Review all
|
| 422 | drivers to initialize the fields to the correct values.
|
| 423 |
|
| 424 | Contact: Thomas Zimmermann <[email protected]>
|
| 425 |
|
| 426 | Level: Intermediate
|
| 427 |
|
| 428 | Request memory regions in all fbdev drivers
|
| 429 | --------------------------------------------
|
| 430 |
|
| 431 | Old/ancient fbdev drivers do not request their memory properly.
|
| 432 | Go through these drivers and add code to request the memory regions
|
| 433 | that the driver uses. This requires adding calls to request_mem_region(),
|
| 434 | pci_request_region() or similar functions. Use helpers for managed cleanup
|
| 435 | where possible. Problematic areas include hardware that has exclusive ranges
|
| 436 | like VGA. VGA16fb does not request the range as it is expected.
|
| 437 | Drivers are pretty bad at doing this and there used to be conflicts among
|
| 438 | DRM and fbdev drivers. Still, it's the correct thing to do.
|
| 439 |
|
| 440 | Contact: Thomas Zimmermann <[email protected]>
|
| 441 |
|
| 442 | Level: Starter
|
| 443 |
|
| 444 | Remove driver dependencies on FB_DEVICE
|
| 445 | ---------------------------------------
|
| 446 |
|
| 447 | A number of fbdev drivers provide attributes via sysfs and therefore depend
|
| 448 | on CONFIG_FB_DEVICE to be selected. Review each driver and attempt to make
|
| 449 | any dependencies on CONFIG_FB_DEVICE optional. At the minimum, the respective
|
| 450 | code in the driver could be conditionalized via ifdef CONFIG_FB_DEVICE. Not
|
| 451 | all drivers might be able to drop CONFIG_FB_DEVICE.
|
| 452 |
|
| 453 | Contact: Thomas Zimmermann <[email protected]>
|
| 454 |
|
| 455 | Level: Starter
|
| 456 |
|
| 457 | Remove disable/unprepare in remove/shutdown in panel-simple and panel-edp
|
| 458 | -------------------------------------------------------------------------
|
| 459 |
|
| 460 | As of commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in
|
| 461 | drm_panel"), we have a check in the drm_panel core to make sure nobody
|
| 462 | double-calls prepare/enable/disable/unprepare. Eventually that should probably
|
| 463 | be turned into a WARN_ON() or somehow made louder.
|
| 464 |
|
| 465 | At the moment, we expect that we may still encounter the warnings in the
|
| 466 | drm_panel core when using panel-simple and panel-edp. Since those panel
|
| 467 | drivers are used with a lot of different DRM modeset drivers they still
|
| 468 | make an extra effort to disable/unprepare the panel themsevles at shutdown
|
| 469 | time. Specifically we could still encounter those warnings if the panel
|
| 470 | driver gets shutdown() _before_ the DRM modeset driver and the DRM modeset
|
| 471 | driver properly calls drm_atomic_helper_shutdown() in its own shutdown()
|
| 472 | callback. Warnings could be avoided in such a case by using something like
|
| 473 | device links to ensure that the panel gets shutdown() after the DRM modeset
|
| 474 | driver.
|
| 475 |
|
| 476 | Once all DRM modeset drivers are known to shutdown properly, the extra
|
| 477 | calls to disable/unprepare in remove/shutdown in panel-simple and panel-edp
|
| 478 | should be removed and this TODO item marked complete.
|
| 479 |
|
| 480 | Contact: Douglas Anderson <[email protected]>
|
| 481 |
|
| 482 | Level: Intermediate
|
| 483 |
|
| 484 | Transition away from using deprecated MIPI DSI functions
|
| 485 | --------------------------------------------------------
|
| 486 |
|
| 487 | There are many functions defined in ``drm_mipi_dsi.c`` which have been
|
| 488 | deprecated. Each deprecated function was deprecated in favor of its `multi`
|
| 489 | variant (e.g. `mipi_dsi_generic_write()` and `mipi_dsi_generic_write_multi()`).
|
| 490 | The `multi` variant of a function includes improved error handling and logic
|
| 491 | which makes it more convenient to make several calls in a row, as most MIPI
|
| 492 | drivers do.
|
| 493 |
|
| 494 | Drivers should be updated to use undeprecated functions. Once all usages of the
|
| 495 | deprecated MIPI DSI functions have been removed, their definitions may be
|
| 496 | removed from ``drm_mipi_dsi.c``.
|
| 497 |
|
| 498 | Contact: Douglas Anderson <[email protected]>
|
| 499 |
|
| 500 | Level: Starter
|
| 501 |
|
| 502 | Remove devm_drm_put_bridge()
|
| 503 | ----------------------------
|
| 504 |
|
| 505 | Due to how the panel bridge handles the drm_bridge object lifetime, special
|
| 506 | care must be taken to dispose of the drm_bridge object when the
|
| 507 | panel_bridge is removed. This is currently managed using
|
| 508 | devm_drm_put_bridge(), but that is an unsafe, temporary workaround. To fix
|
| 509 | that, the DRM panel lifetime needs to be reworked. After the rework is
|
| 510 | done, remove devm_drm_put_bridge() and the TODO in
|
| 511 | drm_panel_bridge_remove().
|
| 512 |
|
| 513 | Contact: Maxime Ripard <[email protected]>,
|
| 514 | Luca Ceresoli <[email protected]>
|
| 515 |
|
| 516 | Level: Intermediate
|
| 517 |
|
| 518 | Convert users of of_drm_find_bridge() to of_drm_find_and_get_bridge()
|
| 519 | ---------------------------------------------------------------------
|
| 520 |
|
| 521 | Taking a struct drm_bridge pointer requires getting a reference and putting
|
| 522 | it after disposing of the pointer. Most functions returning a struct
|
| 523 | drm_bridge pointer already call drm_bridge_get() to increment the refcount
|
| 524 | and their users have been updated to call drm_bridge_put() when
|
| 525 | appropriate. of_drm_find_bridge() does not get a reference and it has been
|
| 526 | deprecated in favor of of_drm_find_and_get_bridge() which does, but some
|
| 527 | users still need to be converted.
|
| 528 |
|
| 529 | Contact: Maxime Ripard <[email protected]>,
|
| 530 | Luca Ceresoli <[email protected]>
|
| 531 |
|
| 532 | Level: Intermediate
|
| 533 |
|
| 534 | Core refactorings
|
| 535 | =================
|
| 536 |
|
| 537 | Make panic handling work
|
| 538 | ------------------------
|
| 539 |
|
| 540 | This is a really varied tasks with lots of little bits and pieces:
|
| 541 |
|
| 542 | * The panic path can't be tested currently, leading to constant breaking. The
|
| 543 | main issue here is that panics can be triggered from hardirq contexts and
|
| 544 | hence all panic related callback can run in hardirq context. It would be
|
| 545 | awesome if we could test at least the fbdev helper code and driver code by
|
| 546 | e.g. trigger calls through drm debugfs files. hardirq context could be
|
| 547 | achieved by using an IPI to the local processor.
|
| 548 |
|
| 549 | * There's a massive confusion of different panic handlers. DRM fbdev emulation
|
| 550 | helpers had their own (long removed), but on top of that the fbcon code itself
|
| 551 | also has one. We need to make sure that they stop fighting over each other.
|
| 552 | This is worked around by checking ``oops_in_progress`` at various entry points
|
| 553 | into the DRM fbdev emulation helpers. A much cleaner approach here would be to
|
| 554 | switch fbcon to the `threaded printk support
|
| 555 | <https://lwn.net/Articles/800946/>`_.
|
| 556 |
|
| 557 | * ``drm_can_sleep()`` is a mess. It hides real bugs in normal operations and
|
| 558 | isn't a full solution for panic paths. We need to make sure that it only
|
| 559 | returns true if there's a panic going on for real, and fix up all the
|
| 560 | fallout.
|
| 561 |
|
| 562 | * The panic handler must never sleep, which also means it can't ever
|
| 563 | ``mutex_lock()``. Also it can't grab any other lock unconditionally, not
|
| 564 | even spinlocks (because NMI and hardirq can panic too). We need to either
|
| 565 | make sure to not call such paths, or trylock everything. Really tricky.
|
| 566 |
|
| 567 | * A clean solution would be an entirely separate panic output support in KMS,
|
| 568 | bypassing the current fbcon support. See `[PATCH v2 0/3] drm: Add panic handling
|
| 569 | <https://lore.kernel.org/dri-devel/[email protected]/>`_.
|
| 570 |
|
| 571 | * Encoding the actual oops and preceding dmesg in a QR might help with the
|
| 572 | dread "important stuff scrolled away" problem. See `[RFC][PATCH] Oops messages
|
| 573 | transfer using QR codes
|
| 574 | <https://lore.kernel.org/lkml/[email protected]/>`_
|
| 575 | for some example code that could be reused.
|
| 576 |
|
| 577 | Contact: Simona Vetter
|
| 578 |
|
| 579 | Level: Advanced
|
| 580 |
|
| 581 | Clean up the debugfs support
|
| 582 | ----------------------------
|
| 583 |
|
| 584 | There's a bunch of issues with it:
|
| 585 |
|
| 586 | - Convert drivers to support the drm_debugfs_add_files() function instead of
|
| 587 | the drm_debugfs_create_files() function.
|
| 588 |
|
| 589 | - Improve late-register debugfs by rolling out the same debugfs pre-register
|
| 590 | infrastructure for connector and crtc too. That way, the drivers won't need to
|
| 591 | split their setup code into init and register anymore.
|
| 592 |
|
| 593 | - We probably want to have some support for debugfs files on crtc/connectors and
|
| 594 | maybe other kms objects directly in core. There's even drm_print support in
|
| 595 | the funcs for these objects to dump kms state, so it's all there. And then the
|
| 596 | ->show() functions should obviously give you a pointer to the right object.
|
| 597 |
|
| 598 | - The drm_driver->debugfs_init hooks we have is just an artifact of the old
|
| 599 | midlayered load sequence. DRM debugfs should work more like sysfs, where you
|
| 600 | can create properties/files for an object anytime you want, and the core
|
| 601 | takes care of publishing/unpuplishing all the files at register/unregister
|
| 602 | time. Drivers shouldn't need to worry about these technicalities, and fixing
|
| 603 | this (together with the drm_minor->drm_device move) would allow us to remove
|
| 604 | debugfs_init.
|
| 605 |
|
| 606 | Contact: Simona Vetter
|
| 607 |
|
| 608 | Level: Intermediate
|
| 609 |
|
| 610 | Object lifetime fixes
|
| 611 | ---------------------
|
| 612 |
|
| 613 | There's two related issues here
|
| 614 |
|
| 615 | - Cleanup up the various ->destroy callbacks, which often are all the same
|
| 616 | simple code.
|
| 617 |
|
| 618 | - Lots of drivers erroneously allocate DRM modeset objects using devm_kzalloc,
|
| 619 | which results in use-after free issues on driver unload. This can be serious
|
| 620 | trouble even for drivers for hardware integrated on the SoC due to
|
| 621 | EPROBE_DEFERRED backoff.
|
| 622 |
|
| 623 | Both these problems can be solved by switching over to drmm_kzalloc(), and the
|
| 624 | various convenience wrappers provided, e.g. drmm_crtc_alloc_with_planes(),
|
| 625 | drmm_universal_plane_alloc(), ... and so on.
|
| 626 |
|
| 627 | Contact: Simona Vetter
|
| 628 |
|
| 629 | Level: Intermediate
|
| 630 |
|
| 631 | Remove automatic page mapping from dma-buf importing
|
| 632 | ----------------------------------------------------
|
| 633 |
|
| 634 | When importing dma-bufs, the dma-buf and PRIME frameworks automatically map
|
| 635 | imported pages into the importer's DMA area. drm_gem_prime_fd_to_handle() and
|
| 636 | drm_gem_prime_handle_to_fd() require that importers call dma_buf_attach()
|
| 637 | even if they never do actual device DMA, but only CPU access through
|
| 638 | dma_buf_vmap(). This is a problem for USB devices, which do not support DMA
|
| 639 | operations.
|
| 640 |
|
| 641 | To fix the issue, automatic page mappings should be removed from the
|
| 642 | buffer-sharing code. Fixing this is a bit more involved, since the import/export
|
| 643 | cache is also tied to &drm_gem_object.import_attach. Meanwhile we paper over
|
| 644 | this problem for USB devices by fishing out the USB host controller device, as
|
| 645 | long as that supports DMA. Otherwise importing can still needlessly fail.
|
| 646 |
|
| 647 | Contact: Thomas Zimmermann <[email protected]>, Simona Vetter
|
| 648 |
|
| 649 | Level: Advanced
|
| 650 |
|
| 651 | Implement a new DUMB_CREATE2 ioctl
|
| 652 | ----------------------------------
|
| 653 |
|
| 654 | The current DUMB_CREATE ioctl is not well defined. Instead of a pixel and
|
| 655 | framebuffer format, it only accepts a color mode of vague semantics. Assuming
|
| 656 | a linear framebuffer, the color mode gives an idea of the supported pixel
|
| 657 | format. But userspace effectively has to guess the correct values. It really
|
| 658 | only works reliably with framebuffers in XRGB8888. Userspace has begun to
|
| 659 | workaround these limitations by computing arbitrary format's buffer sizes and
|
| 660 | calculating their sizes in terms of XRGB8888 pixels.
|
| 661 |
|
| 662 | One possible solution is a new ioctl DUMB_CREATE2. It should accept a DRM
|
| 663 | format and a format modifier to resolve the color mode's ambiguity. As
|
| 664 | framebuffers can be multi-planar, the new ioctl has to return the buffer size,
|
| 665 | pitch and GEM handle for each individual color plane.
|
| 666 |
|
| 667 | In the first step, the new ioctl can be limited to the current features of
|
| 668 | the existing DUMB_CREATE. Individual drivers can then be extended to support
|
| 669 | multi-planar formats. Rockchip might require this and would be a good candidate.
|
| 670 |
|
| 671 | It might also be helpful to userspace to query information about the size of
|
| 672 | a potential buffer, if allocated. Userspace would supply geometry and format;
|
| 673 | the kernel would return minimal allocation sizes and scanline pitch. There is
|
| 674 | interest to allocate that memory from another device and provide it to the
|
| 675 | DRM driver (say via dma-buf).
|
| 676 |
|
| 677 | Another requested feature is the ability to allocate a buffer by size, without
|
| 678 | format. Accelators use this for their buffer allocation and it could likely be
|
| 679 | generalized.
|
| 680 |
|
| 681 | In addition to the kernel implementation, there must be user-space support
|
| 682 | for the new ioctl. There's code in Mesa that might be able to use the new
|
| 683 | call.
|
| 684 |
|
| 685 | Contact: Thomas Zimmermann <[email protected]>
|
| 686 |
|
| 687 | Level: Advanced
|
| 688 |
|
| 689 | Better Testing
|
| 690 | ==============
|
| 691 |
|
| 692 | Add unit tests using the Kernel Unit Testing (KUnit) framework
|
| 693 | --------------------------------------------------------------
|
| 694 |
|
| 695 | The `KUnit <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_
|
| 696 | provides a common framework for unit tests within the Linux kernel. Having a
|
| 697 | test suite would allow to identify regressions earlier.
|
| 698 |
|
| 699 | A good candidate for the first unit tests are the format-conversion helpers in
|
| 700 | ``drm_format_helper.c``.
|
| 701 |
|
| 702 | Contact: Javier Martinez Canillas <[email protected]>
|
| 703 |
|
| 704 | Level: Intermediate
|
| 705 |
|
| 706 | Clean up and document former selftests suites
|
| 707 | ---------------------------------------------
|
| 708 |
|
| 709 | Some KUnit test suites (drm_buddy, drm_cmdline_parser, drm_damage_helper,
|
| 710 | drm_format, drm_framebuffer, drm_dp_mst_helper, drm_mm, drm_plane_helper and
|
| 711 | drm_rect) are former selftests suites that have been converted over when KUnit
|
| 712 | was first introduced.
|
| 713 |
|
| 714 | These suites were fairly undocumented, and with different goals than what unit
|
| 715 | tests can be. Trying to identify what each test in these suites actually test
|
| 716 | for, whether that makes sense for a unit test, and either remove it if it
|
| 717 | doesn't or document it if it does would be of great help.
|
| 718 |
|
| 719 | Contact: Maxime Ripard <[email protected]>
|
| 720 |
|
| 721 | Level: Intermediate
|
| 722 |
|
| 723 | Enable trinity for DRM
|
| 724 | ----------------------
|
| 725 |
|
| 726 | And fix up the fallout. Should be really interesting ...
|
| 727 |
|
| 728 | Level: Advanced
|
| 729 |
|
| 730 | Make KMS tests in i-g-t generic
|
| 731 | -------------------------------
|
| 732 |
|
| 733 | The i915 driver team maintains an extensive testsuite for the i915 DRM driver,
|
| 734 | including tons of testcases for corner-cases in the modesetting API. It would
|
| 735 | be awesome if those tests (at least the ones not relying on Intel-specific GEM
|
| 736 | features) could be made to run on any KMS driver.
|
| 737 |
|
| 738 | Basic work to run i-g-t tests on non-i915 is done, what's now missing is mass-
|
| 739 | converting things over. For modeset tests we also first need a bit of
|
| 740 | infrastructure to use dumb buffers for untiled buffers, to be able to run all
|
| 741 | the non-i915 specific modeset tests.
|
| 742 |
|
| 743 | Level: Advanced
|
| 744 |
|
| 745 | Extend virtual test driver (VKMS)
|
| 746 | ---------------------------------
|
| 747 |
|
| 748 | See the documentation of :ref:`VKMS <vkms>` for more details. This is an ideal
|
| 749 | internship task, since it only requires a virtual machine and can be sized to
|
| 750 | fit the available time.
|
| 751 |
|
| 752 | Level: See details
|
| 753 |
|
| 754 | Backlight Refactoring
|
| 755 | ---------------------
|
| 756 |
|
| 757 | Backlight drivers have a triple enable/disable state, which is a bit overkill.
|
| 758 | Plan to fix this:
|
| 759 |
|
| 760 | 1. Roll out backlight_enable() and backlight_disable() helpers everywhere. This
|
| 761 | has started already.
|
| 762 | 2. In all, only look at one of the three status bits set by the above helpers.
|
| 763 | 3. Remove the other two status bits.
|
| 764 |
|
| 765 | Contact: Simona Vetter
|
| 766 |
|
| 767 | Level: Intermediate
|
| 768 |
|
| 769 | Driver Specific
|
| 770 | ===============
|
| 771 |
|
| 772 | AMD DC Display Driver
|
| 773 | ---------------------
|
| 774 |
|
| 775 | AMD DC is the display driver for AMD devices starting with Vega. There has been
|
| 776 | a bunch of progress cleaning it up but there's still plenty of work to be done.
|
| 777 |
|
| 778 | See drivers/gpu/drm/amd/display/TODO for tasks.
|
| 779 |
|
| 780 | Contact: Harry Wentland, Alex Deucher
|
| 781 |
|
| 782 | Bootsplash
|
| 783 | ==========
|
| 784 |
|
| 785 | There is support in place now for writing internal DRM clients making it
|
| 786 | possible to pick up the bootsplash work that was rejected because it was written
|
| 787 | for fbdev.
|
| 788 |
|
| 789 | - [v6,8/8] drm/client: Hack: Add bootsplash example
|
| 790 | https://patchwork.freedesktop.org/patch/306579/
|
| 791 |
|
| 792 | - [RFC PATCH v2 00/13] Kernel based bootsplash
|
| 793 | https://lore.kernel.org/r/[email protected]
|
| 794 |
|
| 795 | Contact: Sam Ravnborg
|
| 796 |
|
| 797 | Level: Advanced
|
| 798 |
|
| 799 | Brightness handling on devices with multiple internal panels
|
| 800 | ============================================================
|
| 801 |
|
| 802 | On x86/ACPI devices there can be multiple backlight firmware interfaces:
|
| 803 | (ACPI) video, vendor specific and others. As well as direct/native (PWM)
|
| 804 | register programming by the KMS driver.
|
| 805 |
|
| 806 | To deal with this backlight drivers used on x86/ACPI call
|
| 807 | acpi_video_get_backlight_type() which has heuristics (+quirks) to select
|
| 808 | which backlight interface to use; and backlight drivers which do not match
|
| 809 | the returned type will not register themselves, so that only one backlight
|
| 810 | device gets registered (in a single GPU setup, see below).
|
| 811 |
|
| 812 | At the moment this more or less assumes that there will only
|
| 813 | be 1 (internal) panel on a system.
|
| 814 |
|
| 815 | On systems with 2 panels this may be a problem, depending on
|
| 816 | what interface acpi_video_get_backlight_type() selects:
|
| 817 |
|
| 818 | 1. native: in this case the KMS driver is expected to know which backlight
|
| 819 | device belongs to which output so everything should just work.
|
| 820 | 2. video: this does support controlling multiple backlights, but some work
|
| 821 | will need to be done to get the output <-> backlight device mapping
|
| 822 |
|
| 823 | The above assumes both panels will require the same backlight interface type.
|
| 824 | Things will break on systems with multiple panels where the 2 panels need
|
| 825 | a different type of control. E.g. one panel needs ACPI video backlight control,
|
| 826 | where as the other is using native backlight control. Currently in this case
|
| 827 | only one of the 2 required backlight devices will get registered, based on
|
| 828 | the acpi_video_get_backlight_type() return value.
|
| 829 |
|
| 830 | If this (theoretical) case ever shows up, then supporting this will need some
|
| 831 | work. A possible solution here would be to pass a device and connector-name
|
| 832 | to acpi_video_get_backlight_type() so that it can deal with this.
|
| 833 |
|
| 834 | Note in a way we already have a case where userspace sees 2 panels,
|
| 835 | in dual GPU laptop setups with a mux. On those systems we may see
|
| 836 | either 2 native backlight devices; or 2 native backlight devices.
|
| 837 |
|
| 838 | Userspace already has code to deal with this by detecting if the related
|
| 839 | panel is active (iow which way the mux between the GPU and the panels
|
| 840 | points) and then uses that backlight device. Userspace here very much
|
| 841 | assumes a single panel though. It picks only 1 of the 2 backlight devices
|
| 842 | and then only uses that one.
|
| 843 |
|
| 844 | Note that all userspace code (that I know off) is currently hardcoded
|
| 845 | to assume a single panel.
|
| 846 |
|
| 847 | Before the recent changes to not register multiple (e.g. video + native)
|
| 848 | /sys/class/backlight devices for a single panel (on a single GPU laptop),
|
| 849 | userspace would see multiple backlight devices all controlling the same
|
| 850 | backlight.
|
| 851 |
|
| 852 | To deal with this userspace had to always picks one preferred device under
|
| 853 | /sys/class/backlight and will ignore the others. So to support brightness
|
| 854 | control on multiple panels userspace will need to be updated too.
|
| 855 |
|
| 856 | There are plans to allow brightness control through the KMS API by adding
|
| 857 | a "display brightness" property to drm_connector objects for panels. This
|
| 858 | solves a number of issues with the /sys/class/backlight API, including not
|
| 859 | being able to map a sysfs backlight device to a specific connector. Any
|
| 860 | userspace changes to add support for brightness control on devices with
|
| 861 | multiple panels really should build on top of this new KMS property.
|
| 862 |
|
| 863 | Contact: Hans de Goede
|
| 864 |
|
| 865 | Level: Advanced
|
| 866 |
|
| 867 | Buffer age or other damage accumulation algorithm for buffer damage
|
| 868 | ===================================================================
|
| 869 |
|
| 870 | Drivers that do per-buffer uploads, need a buffer damage handling (rather than
|
| 871 | frame damage like drivers that do per-plane or per-CRTC uploads), but there is
|
| 872 | no support to get the buffer age or any other damage accumulation algorithm.
|
| 873 |
|
| 874 | For this reason, the damage helpers just fallback to a full plane update if the
|
| 875 | framebuffer attached to a plane has changed since the last page-flip. Drivers
|
| 876 | set &drm_plane_state.ignore_damage_clips to true as indication to
|
| 877 | drm_atomic_helper_damage_iter_init() and drm_atomic_helper_damage_iter_next()
|
| 878 | helpers that the damage clips should be ignored.
|
| 879 |
|
| 880 | This should be improved to get damage tracking properly working on drivers that
|
| 881 | do per-buffer uploads.
|
| 882 |
|
| 883 | More information about damage tracking and references to learning materials can
|
| 884 | be found in :ref:`damage_tracking_properties`.
|
| 885 |
|
| 886 | Contact: Javier Martinez Canillas <[email protected]>
|
| 887 |
|
| 888 | Level: Advanced
|
| 889 |
|
| 890 | Querying errors from drm_syncobj
|
| 891 | ================================
|
| 892 |
|
| 893 | The drm_syncobj container can be used by driver independent code to signal
|
| 894 | complection of submission.
|
| 895 |
|
| 896 | One minor feature still missing is a generic DRM IOCTL to query the error
|
| 897 | status of binary and timeline drm_syncobj.
|
| 898 |
|
| 899 | This was already improved by implementing the necessary kernel interface
|
| 900 | (patches are on the dri-devel mailing list) but adding support for that in the
|
| 901 | userspace stack is still missing.
|
| 902 |
|
| 903 | Contact: Christian König, Michel Dänzer
|
| 904 |
|
| 905 | Level: Starter
|
| 906 |
|
| 907 | DRM GPU Scheduler
|
| 908 | =================
|
| 909 |
|
| 910 | Provide a universal successor for drm_sched_resubmit_jobs()
|
| 911 | -----------------------------------------------------------
|
| 912 |
|
| 913 | drm_sched_resubmit_jobs() is deprecated. Main reason being that it leads to
|
| 914 | reinitializing dma_fences. See that function's docu for details. The better
|
| 915 | approach for valid resubmissions by amdgpu and Xe is (apparently) to figure out
|
| 916 | which job (and, through association: which entity) caused the hang. Then, the
|
| 917 | job's buffer data, together with all other jobs' buffer data currently in the
|
| 918 | same hardware ring, must be invalidated. This can for example be done by
|
| 919 | overwriting it. amdgpu currently determines which jobs are in the ring and need
|
| 920 | to be overwritten by keeping copies of the job. Xe obtains that information by
|
| 921 | directly accessing drm_sched's pending_list.
|
| 922 |
|
| 923 | Tasks:
|
| 924 |
|
| 925 | 1. implement scheduler functionality through which the driver can obtain the
|
| 926 | information which *broken* jobs are currently in the hardware ring.
|
| 927 | 2. Such infrastructure would then typically be used in
|
| 928 | drm_sched_backend_ops.timedout_job(). Document that.
|
| 929 | 3. Port a driver as first user.
|
| 930 | 4. Document the new alternative in the docu of deprecated
|
| 931 | drm_sched_resubmit_jobs().
|
| 932 |
|
| 933 | Contact: Christian König <[email protected]>
|
| 934 | Philipp Stanner <[email protected]>
|
| 935 |
|
| 936 | Level: Advanced
|
| 937 |
|
| 938 | Add locking for runqueues
|
| 939 | -------------------------
|
| 940 |
|
| 941 | There is an old FIXME by Sima in include/drm/gpu_scheduler.h. It details that
|
| 942 | struct drm_sched_rq is read at many places without any locks, not even with a
|
| 943 | READ_ONCE. At XDC 2025 no one could really tell why that is the case, whether
|
| 944 | locks are needed and whether they could be added. (But for real, that should
|
| 945 | probably be locked!). Check whether it's possible to add locks everywhere, and
|
| 946 | do so if yes.
|
| 947 |
|
| 948 | Contact: Philipp Stanner <[email protected]>
|
| 949 |
|
| 950 | Level: Intermediate
|
| 951 |
|
| 952 | Replace the lockless queue with a locked list
|
| 953 | ---------------------------------------------
|
| 954 |
|
| 955 | drm_sched is the only user in the entire kernel of a special lockless queue, the
|
| 956 | spsc_queue. This queue utilizes:
|
| 957 |
|
| 958 | - preempt_disable()
|
| 959 | - atomic instructions
|
| 960 | - memory barriers
|
| 961 | - ACCESS_ONCE()
|
| 962 |
|
| 963 | whereas a conventional spinlock utilizes:
|
| 964 |
|
| 965 | - preempt_disable()
|
| 966 | - 1 atomic instruction for taking / releasing the lock
|
| 967 | - memory barriers
|
| 968 |
|
| 969 | Moreover, drm_sched_entity_push_job(), the only user of spsc_queue_push(), has
|
| 970 | to take a lock in some situations anyways and calls to it are often serialized
|
| 971 | with a driver lock.
|
| 972 |
|
| 973 | It is, thus, highly questionable whether the lockless queue grants any advantage
|
| 974 | at all. Considering that its internals are not well documented and its correctness
|
| 975 | is not formally proven, it seems desirable to replace the queue with a mere list
|
| 976 | or hlist that is protected by a spinlock.
|
| 977 |
|
| 978 | Tasks:
|
| 979 |
|
| 980 | - Replace the spsc_queue in drm/sched (and those who might access the scheduler's
|
| 981 | internal queue) with a spinlock + (h)list.
|
| 982 | - Ideally, check with some micro benchmarks and real world tests (preferably
|
| 983 | with amdgpu) for relevant performance regressions.
|
| 984 | - Remove the spsc_queue from the kernel altogether.
|
| 985 |
|
| 986 | Contact:
|
| 987 |
|
| 988 | - Philipp Stanner <[email protected]>
|
| 989 | - Christian König <[email protected]>
|
| 990 |
|
| 991 | Level: Beginner
|
| 992 |
|
| 993 | Outside DRM
|
| 994 | ===========
|
| 995 |
|
| 996 | Convert fbdev drivers to DRM
|
| 997 | ----------------------------
|
| 998 |
|
| 999 | There are plenty of fbdev drivers for older hardware. Some hardware has
|
| 1000 | become obsolete, but some still provides good(-enough) framebuffers. The
|
| 1001 | drivers that are still useful should be converted to DRM and afterwards
|
| 1002 | removed from fbdev.
|
| 1003 |
|
| 1004 | Very simple fbdev drivers can best be converted by starting with a new
|
| 1005 | DRM driver. Simple KMS helpers and SHMEM should be able to handle any
|
| 1006 | existing hardware. The new driver's call-back functions are filled from
|
| 1007 | existing fbdev code.
|
| 1008 |
|
| 1009 | More complex fbdev drivers can be refactored step-by-step into a DRM
|
| 1010 | driver with the help of the DRM fbconv helpers . These helpers provide
|
| 1011 | the transition layer between the DRM core infrastructure and the fbdev
|
| 1012 | driver interface. Create a new DRM driver on top of the fbconv helpers,
|
| 1013 | copy over the fbdev driver, and hook it up to the DRM code. Examples for
|
| 1014 | several fbdev drivers are available in Thomas Zimmermann's fbconv tree
|
| 1015 | , as well as a tutorial of this process . The result is a primitive
|
| 1016 | DRM driver that can run X11 and Weston.
|
| 1017 |
|
| 1018 | .. [4] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv
|
| 1019 | .. [5] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c
|
| 1020 |
|
| 1021 | Contact: Thomas Zimmermann <[email protected]>
|
| 1022 |
|
| 1023 | Level: Advanced
|