Commit | Line | Data |
---|---|---|
0e70dad0 TR |
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 | ||
a5e5cf98 DV |
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 | ||
5823cca3 DV |
26 | Expert: Only attempt these if you've successfully completed some tricky |
27 | refactorings already and are an expert in the specific area | |
28 | ||
0e70dad0 TR |
29 | Subsystem-wide refactorings |
30 | =========================== | |
31 | ||
39dea70d DV |
32 | Remove custom dumb_map_offset implementations |
33 | --------------------------------------------- | |
34 | ||
35 | All GEM based drivers should be using drm_gem_create_mmap_offset() instead. | |
36 | Audit each individual driver, make sure it'll work with the generic | |
37 | implementation (there's lots of outdated locking leftovers in various | |
38 | implementations), and then remove it. | |
39 | ||
40 | Contact: Daniel Vetter, respective driver maintainers | |
41 | ||
a5e5cf98 DV |
42 | Level: Intermediate |
43 | ||
0e70dad0 TR |
44 | Convert existing KMS drivers to atomic modesetting |
45 | -------------------------------------------------- | |
46 | ||
47 | 3.19 has the atomic modeset interfaces and helpers, so drivers can now be | |
48 | converted over. Modern compositors like Wayland or Surfaceflinger on Android | |
49 | really want an atomic modeset interface, so this is all about the bright | |
50 | future. | |
51 | ||
52 | There is a conversion guide for atomic and all you need is a GPU for a | |
53 | non-converted driver (again virtual HW drivers for KVM are still all | |
54 | suitable). | |
55 | ||
56 | As part of this drivers also need to convert to universal plane (which means | |
57 | exposing primary & cursor as proper plane objects). But that's much easier to | |
58 | do by directly using the new atomic helper driver callbacks. | |
59 | ||
60 | Contact: Daniel Vetter, respective driver maintainers | |
1a80cc1c | 61 | |
a5e5cf98 DV |
62 | Level: Advanced |
63 | ||
1a80cc1c DV |
64 | Clean up the clipped coordination confusion around planes |
65 | --------------------------------------------------------- | |
66 | ||
67 | We have a helper to get this right with drm_plane_helper_check_update(), but | |
68 | it's not consistently used. This should be fixed, preferrably in the atomic | |
69 | helpers (and drivers then moved over to clipped coordinates). Probably the | |
70 | helper should also be moved from drm_plane_helper.c to the atomic helpers, to | |
71 | avoid confusion - the other helpers in that file are all deprecated legacy | |
72 | helpers. | |
73 | ||
74 | Contact: Ville Syrjälä, Daniel Vetter, driver maintainers | |
4e8be453 | 75 | |
a5e5cf98 DV |
76 | Level: Advanced |
77 | ||
9a69bd19 DV |
78 | Improve plane atomic_check helpers |
79 | ---------------------------------- | |
80 | ||
81 | Aside from the clipped coordinates right above there's a few suboptimal things | |
82 | with the current helpers: | |
83 | ||
84 | - drm_plane_helper_funcs->atomic_check gets called for enabled or disabled | |
85 | planes. At best this seems to confuse drivers, worst it means they blow up | |
86 | when the plane is disabled without the CRTC. The only special handling is | |
87 | resetting values in the plane state structures, which instead should be moved | |
88 | into the drm_plane_funcs->atomic_duplicate_state functions. | |
89 | ||
90 | - Once that's done, helpers could stop calling ->atomic_check for disabled | |
91 | planes. | |
92 | ||
93 | - Then we could go through all the drivers and remove the more-or-less confused | |
94 | checks for plane_state->fb and plane_state->crtc. | |
95 | ||
96 | Contact: Daniel Vetter | |
97 | ||
98 | Level: Advanced | |
99 | ||
0e70dad0 TR |
100 | Convert early atomic drivers to async commit helpers |
101 | ---------------------------------------------------- | |
102 | ||
103 | For the first year the atomic modeset helpers didn't support asynchronous / | |
104 | nonblocking commits, and every driver had to hand-roll them. This is fixed | |
105 | now, but there's still a pile of existing drivers that easily could be | |
106 | converted over to the new infrastructure. | |
107 | ||
108 | One issue with the helpers is that they require that drivers handle completion | |
109 | events for atomic commits correctly. But fixing these bugs is good anyway. | |
110 | ||
7d18e2f3 DV |
111 | Somewhat related is the legacy_cursor_update hack, which should be replaced with |
112 | the new atomic_async_check/commit functionality in the helpers in drivers that | |
113 | still look at that flag. | |
114 | ||
0e70dad0 TR |
115 | Contact: Daniel Vetter, respective driver maintainers |
116 | ||
a5e5cf98 DV |
117 | Level: Advanced |
118 | ||
0e70dad0 TR |
119 | Fallout from atomic KMS |
120 | ----------------------- | |
121 | ||
122 | ``drm_atomic_helper.c`` provides a batch of functions which implement legacy | |
123 | IOCTLs on top of the new atomic driver interface. Which is really nice for | |
124 | gradual conversion of drivers, but unfortunately the semantic mismatches are | |
125 | a bit too severe. So there's some follow-up work to adjust the function | |
126 | interfaces to fix these issues: | |
127 | ||
128 | * atomic needs the lock acquire context. At the moment that's passed around | |
129 | implicitly with some horrible hacks, and it's also allocate with | |
130 | ``GFP_NOFAIL`` behind the scenes. All legacy paths need to start allocating | |
131 | the acquire context explicitly on stack and then also pass it down into | |
132 | drivers explicitly so that the legacy-on-atomic functions can use them. | |
133 | ||
2ec04b33 DV |
134 | Except for some driver code this is done. This task should be finished by |
135 | adding WARN_ON(!drm_drv_uses_atomic_modeset) in drm_modeset_lock_all(). | |
be05fe13 | 136 | |
0e70dad0 TR |
137 | * A bunch of the vtable hooks are now in the wrong place: DRM has a split |
138 | between core vfunc tables (named ``drm_foo_funcs``), which are used to | |
139 | implement the userspace ABI. And then there's the optional hooks for the | |
140 | helper libraries (name ``drm_foo_helper_funcs``), which are purely for | |
141 | internal use. Some of these hooks should be move from ``_funcs`` to | |
142 | ``_helper_funcs`` since they are not part of the core ABI. There's a | |
143 | ``FIXME`` comment in the kerneldoc for each such case in ``drm_crtc.h``. | |
144 | ||
0e70dad0 TR |
145 | Contact: Daniel Vetter |
146 | ||
a5e5cf98 DV |
147 | Level: Intermediate |
148 | ||
0e70dad0 TR |
149 | Get rid of dev->struct_mutex from GEM drivers |
150 | --------------------------------------------- | |
151 | ||
152 | ``dev->struct_mutex`` is the Big DRM Lock from legacy days and infested | |
153 | everything. Nowadays in modern drivers the only bit where it's mandatory is | |
154 | serializing GEM buffer object destruction. Which unfortunately means drivers | |
155 | have to keep track of that lock and either call ``unreference`` or | |
156 | ``unreference_locked`` depending upon context. | |
157 | ||
158 | Core GEM doesn't have a need for ``struct_mutex`` any more since kernel 4.8, | |
d693def4 | 159 | and there's a GEM object ``free`` callback for any drivers which are |
0e70dad0 TR |
160 | entirely ``struct_mutex`` free. |
161 | ||
162 | For drivers that need ``struct_mutex`` it should be replaced with a driver- | |
163 | private lock. The tricky part is the BO free functions, since those can't | |
164 | reliably take that lock any more. Instead state needs to be protected with | |
165 | suitable subordinate locks or some cleanup work pushed to a worker thread. For | |
166 | performance-critical drivers it might also be better to go with a more | |
efdff86d EV |
167 | fine-grained per-buffer object and per-context lockings scheme. Currently only |
168 | the ``msm`` and `i915` drivers use ``struct_mutex``. | |
0e70dad0 | 169 | |
085c6c09 | 170 | Contact: Daniel Vetter, respective driver maintainers |
0e70dad0 | 171 | |
a5e5cf98 DV |
172 | Level: Advanced |
173 | ||
5823cca3 DV |
174 | Move Buffer Object Locking to dma_resv_lock() |
175 | --------------------------------------------- | |
176 | ||
177 | Many drivers have their own per-object locking scheme, usually using | |
178 | mutex_lock(). This causes all kinds of trouble for buffer sharing, since | |
179 | depending which driver is the exporter and importer, the locking hierarchy is | |
180 | reversed. | |
181 | ||
182 | To solve this we need one standard per-object locking mechanism, which is | |
183 | dma_resv_lock(). This lock needs to be called as the outermost lock, with all | |
184 | other driver specific per-object locks removed. The problem is tha rolling out | |
185 | the actual change to the locking contract is a flag day, due to struct dma_buf | |
186 | buffer sharing. | |
187 | ||
188 | Level: Expert | |
189 | ||
93ccfa9a DV |
190 | Convert logging to drm_* functions with drm_device paramater |
191 | ------------------------------------------------------------ | |
45ae2787 SP |
192 | |
193 | For drivers which could have multiple instances, it is necessary to | |
194 | differentiate between which is which in the logs. Since DRM_INFO/WARN/ERROR | |
195 | don't do this, drivers used dev_info/warn/err to make this differentiation. We | |
93ccfa9a DV |
196 | now have drm_* variants of the drm print functions, so we can start to convert |
197 | those drivers back to using drm-formatted specific log messages. | |
45ae2787 | 198 | |
9f446781 DV |
199 | Before you start this conversion please contact the relevant maintainers to make |
200 | sure your work will be merged - not everyone agrees that the DRM dmesg macros | |
201 | are better. | |
202 | ||
45ae2787 SP |
203 | Contact: Sean Paul, Maintainer of the driver you plan to convert |
204 | ||
a5e5cf98 DV |
205 | Level: Starter |
206 | ||
3233fc0a NT |
207 | Convert drivers to use simple modeset suspend/resume |
208 | ---------------------------------------------------- | |
209 | ||
210 | Most drivers (except i915 and nouveau) that use | |
211 | drm_atomic_helper_suspend/resume() can probably be converted to use | |
2ec04b33 DV |
212 | drm_mode_config_helper_suspend/resume(). Also there's still open-coded version |
213 | of the atomic suspend/resume code in older atomic modeset drivers. | |
3233fc0a NT |
214 | |
215 | Contact: Maintainer of the driver you plan to convert | |
216 | ||
a5e5cf98 DV |
217 | Level: Intermediate |
218 | ||
80ae0369 TZ |
219 | Convert drivers to use drm_fbdev_generic_setup() |
220 | ------------------------------------------------ | |
ee05baa0 | 221 | |
80ae0369 | 222 | Most drivers can use drm_fbdev_generic_setup(). Driver have to implement |
222ec45f TZ |
223 | atomic modesetting and GEM vmap support. Historically, generic fbdev emulation |
224 | expected the framebuffer in system memory or system-like memory. By employing | |
7938f421 | 225 | struct iosys_map, drivers with frambuffers in I/O memory can be supported |
222ec45f | 226 | as well. |
ee05baa0 NT |
227 | |
228 | Contact: Maintainer of the driver you plan to convert | |
229 | ||
a5e5cf98 DV |
230 | Level: Intermediate |
231 | ||
222ec45f TZ |
232 | Reimplement functions in drm_fbdev_fb_ops without fbdev |
233 | ------------------------------------------------------- | |
234 | ||
235 | A number of callback functions in drm_fbdev_fb_ops could benefit from | |
236 | being rewritten without dependencies on the fbdev module. Some of the | |
7938f421 | 237 | helpers could further benefit from using struct iosys_map instead of |
222ec45f TZ |
238 | raw pointers. |
239 | ||
240 | Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter | |
241 | ||
242 | Level: Advanced | |
243 | ||
9ae2ac4d TZ |
244 | Benchmark and optimize blitting and format-conversion function |
245 | -------------------------------------------------------------- | |
246 | ||
247 | Drawing to dispay memory quickly is crucial for many applications' | |
248 | performance. | |
249 | ||
250 | On at least x86-64, sys_imageblit() is significantly slower than | |
251 | cfb_imageblit(), even though both use the same blitting algorithm and | |
252 | the latter is written for I/O memory. It turns out that cfb_imageblit() | |
253 | uses movl instructions, while sys_imageblit apparently does not. This | |
254 | seems to be a problem with gcc's optimizer. DRM's format-conversion | |
255 | helpers might be subject to similar issues. | |
256 | ||
257 | Benchmark and optimize fbdev's sys_() helpers and DRM's format-conversion | |
258 | helpers. In cases that can be further optimized, maybe implement a different | |
259 | algorithm. For micro-optimizations, use movl/movq instructions explicitly. | |
260 | That might possibly require architecture-specific helpers (e.g., storel() | |
261 | storeq()). | |
262 | ||
263 | Contact: Thomas Zimmermann <tzimmermann@suse.de> | |
264 | ||
265 | Level: Intermediate | |
222ec45f | 266 | |
2c81bdc8 DV |
267 | drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup |
268 | ----------------------------------------------------------------- | |
269 | ||
270 | A lot more drivers could be switched over to the drm_gem_framebuffer helpers. | |
271 | Various hold-ups: | |
272 | ||
273 | - Need to switch over to the generic dirty tracking code using | |
274 | drm_atomic_helper_dirtyfb first (e.g. qxl). | |
275 | ||
276 | - Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb | |
277 | setup code can't be deleted. | |
278 | ||
279 | - Many drivers wrap drm_gem_fb_create() only to check for valid formats. For | |
280 | atomic drivers we could check for valid formats by calling | |
281 | drm_plane_check_pixel_format() against all planes, and pass if any plane | |
282 | supports the format. For non-atomic that's not possible since like the format | |
283 | list for the primary plane is fake and we'd therefor reject valid formats. | |
284 | ||
285 | - Many drivers subclass drm_framebuffer, we'd need a embedding compatible | |
286 | version of the varios drm_gem_fb_create functions. Maybe called | |
287 | drm_gem_fb_create/_with_dirty/_with_funcs as needed. | |
288 | ||
289 | Contact: Daniel Vetter | |
290 | ||
291 | Level: Intermediate | |
292 | ||
be5cadc7 DV |
293 | Generic fbdev defio support |
294 | --------------------------- | |
295 | ||
296 | The defio support code in the fbdev core has some very specific requirements, | |
955a72ce TZ |
297 | which means drivers need to have a special framebuffer for fbdev. The main |
298 | issue is that it uses some fields in struct page itself, which breaks shmem | |
299 | gem objects (and other things). To support defio, affected drivers require | |
300 | the use of a shadow buffer, which may add CPU and memory overhead. | |
be5cadc7 DV |
301 | |
302 | Possible solution would be to write our own defio mmap code in the drm fbdev | |
303 | emulation. It would need to fully wrap the existing mmap ops, forwarding | |
304 | everything after it has done the write-protect/mkwrite trickery: | |
305 | ||
306 | - In the drm_fbdev_fb_mmap helper, if we need defio, change the | |
307 | default page prots to write-protected with something like this:: | |
308 | ||
309 | vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot); | |
310 | ||
311 | - Set the mkwrite and fsync callbacks with similar implementions to the core | |
312 | fbdev defio stuff. These should all work on plain ptes, they don't actually | |
313 | require a struct page. uff. These should all work on plain ptes, they don't | |
314 | actually require a struct page. | |
315 | ||
316 | - Track the dirty pages in a separate structure (bitfield with one bit per page | |
317 | should work) to avoid clobbering struct page. | |
318 | ||
319 | Might be good to also have some igt testcases for this. | |
320 | ||
321 | Contact: Daniel Vetter, Noralf Tronnes | |
322 | ||
a5e5cf98 DV |
323 | Level: Advanced |
324 | ||
b39b5394 NT |
325 | struct drm_gem_object_funcs |
326 | --------------------------- | |
327 | ||
328 | GEM objects can now have a function table instead of having the callbacks on the | |
d693def4 TZ |
329 | DRM driver struct. This is now the preferred way. Callbacks in drivers have been |
330 | converted, except for struct drm_driver.gem_prime_mmap. | |
8db420ac | 331 | |
a5e5cf98 DV |
332 | Level: Intermediate |
333 | ||
69b22f51 DV |
334 | connector register/unregister fixes |
335 | ----------------------------------- | |
336 | ||
337 | - For most connectors it's a no-op to call drm_connector_register/unregister | |
338 | directly from driver code, drm_dev_register/unregister take care of this | |
339 | already. We can remove all of them. | |
340 | ||
341 | - For dp drivers it's a bit more a mess, since we need the connector to be | |
342 | registered when calling drm_dp_aux_register. Fix this by instead calling | |
343 | drm_dp_aux_init, and moving the actual registering into a late_register | |
344 | callback as recommended in the kerneldoc. | |
345 | ||
a5e5cf98 DV |
346 | Level: Intermediate |
347 | ||
700496fa DV |
348 | Remove load/unload callbacks from all non-DRIVER_LEGACY drivers |
349 | --------------------------------------------------------------- | |
350 | ||
351 | The load/unload callbacks in struct &drm_driver are very much midlayers, plus | |
352 | for historical reasons they get the ordering wrong (and we can't fix that) | |
353 | between setting up the &drm_driver structure and calling drm_dev_register(). | |
354 | ||
355 | - Rework drivers to no longer use the load/unload callbacks, directly coding the | |
356 | load/unload sequence into the driver's probe function. | |
357 | ||
358 | - Once all non-DRIVER_LEGACY drivers are converted, disallow the load/unload | |
359 | callbacks for all modern drivers. | |
360 | ||
361 | Contact: Daniel Vetter | |
362 | ||
363 | Level: Intermediate | |
364 | ||
a92d083d LP |
365 | Replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi |
366 | --------------------------------------------------------------- | |
367 | ||
368 | Once EDID is parsed, the monitor HDMI support information is available through | |
369 | drm_display_info.is_hdmi. Many drivers still call drm_detect_hdmi_monitor() to | |
370 | retrieve the same information, which is less efficient. | |
371 | ||
372 | Audit each individual driver calling drm_detect_hdmi_monitor() and switch to | |
373 | drm_display_info.is_hdmi if applicable. | |
374 | ||
375 | Contact: Laurent Pinchart, respective driver maintainers | |
376 | ||
377 | Level: Intermediate | |
378 | ||
c3274799 EV |
379 | Consolidate custom driver modeset properties |
380 | -------------------------------------------- | |
381 | ||
382 | Before atomic modeset took place, many drivers where creating their own | |
383 | properties. Among other things, atomic brought the requirement that custom, | |
384 | driver specific properties should not be used. | |
385 | ||
386 | For this task, we aim to introduce core helpers or reuse the existing ones | |
387 | if available: | |
388 | ||
389 | A quick, unconfirmed, examples list. | |
390 | ||
391 | Introduce core helpers: | |
392 | - audio (amdgpu, intel, gma500, radeon) | |
393 | - brightness, contrast, etc (armada, nouveau) - overlay only (?) | |
394 | - broadcast rgb (gma500, intel) | |
395 | - colorkey (armada, nouveau, rcar) - overlay only (?) | |
396 | - dither (amdgpu, nouveau, radeon) - varies across drivers | |
397 | - underscan family (amdgpu, radeon, nouveau) | |
398 | ||
399 | Already in core: | |
400 | - colorspace (sti) | |
401 | - tv format names, enhancements (gma500, intel) | |
402 | - tv overscan, margins, etc. (gma500, intel) | |
403 | - zorder (omapdrm) - same as zpos (?) | |
404 | ||
405 | ||
406 | Contact: Emil Velikov, respective driver maintainers | |
407 | ||
408 | Level: Intermediate | |
6142b1b8 | 409 | |
7938f421 LDM |
410 | Use struct iosys_map throughout codebase |
411 | ---------------------------------------- | |
49a3f51d | 412 | |
7938f421 | 413 | Pointers to shared device memory are stored in struct iosys_map. Each |
49a3f51d | 414 | instance knows whether it refers to system or I/O memory. Most of the DRM-wide |
7938f421 | 415 | interface have been converted to use struct iosys_map, but implementations |
49a3f51d TZ |
416 | often still use raw pointers. |
417 | ||
7938f421 | 418 | The task is to use struct iosys_map where it makes sense. |
49a3f51d | 419 | |
7938f421 LDM |
420 | * Memory managers should use struct iosys_map for dma-buf-imported buffers. |
421 | * TTM might benefit from using struct iosys_map internally. | |
422 | * Framebuffer copying and blitting helpers should operate on struct iosys_map. | |
49a3f51d TZ |
423 | |
424 | Contact: Thomas Zimmermann <tzimmermann@suse.de>, Christian König, Daniel Vetter | |
425 | ||
426 | Level: Intermediate | |
427 | ||
84e9dfd5 TZ |
428 | Review all drivers for setting struct drm_mode_config.{max_width,max_height} correctly |
429 | -------------------------------------------------------------------------------------- | |
430 | ||
431 | The values in struct drm_mode_config.{max_width,max_height} describe the | |
432 | maximum supported framebuffer size. It's the virtual screen size, but many | |
433 | drivers treat it like limitations of the physical resolution. | |
434 | ||
435 | The maximum width depends on the hardware's maximum scanline pitch. The | |
436 | maximum height depends on the amount of addressable video memory. Review all | |
437 | drivers to initialize the fields to the correct values. | |
438 | ||
439 | Contact: Thomas Zimmermann <tzimmermann@suse.de> | |
440 | ||
441 | Level: Intermediate | |
442 | ||
bb7eb3b1 TZ |
443 | Request memory regions in all drivers |
444 | ------------------------------------- | |
445 | ||
446 | Go through all drivers and add code to request the memory regions that the | |
447 | driver uses. This requires adding calls to request_mem_region(), | |
448 | pci_request_region() or similar functions. Use helpers for managed cleanup | |
449 | where possible. | |
450 | ||
451 | Drivers are pretty bad at doing this and there used to be conflicts among | |
452 | DRM and fbdev drivers. Still, it's the correct thing to do. | |
453 | ||
454 | Contact: Thomas Zimmermann <tzimmermann@suse.de> | |
455 | ||
456 | Level: Starter | |
457 | ||
c3274799 | 458 | |
0e70dad0 TR |
459 | Core refactorings |
460 | ================= | |
461 | ||
0e70dad0 TR |
462 | Make panic handling work |
463 | ------------------------ | |
464 | ||
465 | This is a really varied tasks with lots of little bits and pieces: | |
466 | ||
467 | * The panic path can't be tested currently, leading to constant breaking. The | |
468 | main issue here is that panics can be triggered from hardirq contexts and | |
469 | hence all panic related callback can run in hardirq context. It would be | |
470 | awesome if we could test at least the fbdev helper code and driver code by | |
471 | e.g. trigger calls through drm debugfs files. hardirq context could be | |
472 | achieved by using an IPI to the local processor. | |
473 | ||
474 | * There's a massive confusion of different panic handlers. DRM fbdev emulation | |
4db3189c DV |
475 | helpers had their own (long removed), but on top of that the fbcon code itself |
476 | also has one. We need to make sure that they stop fighting over each other. | |
477 | This is worked around by checking ``oops_in_progress`` at various entry points | |
478 | into the DRM fbdev emulation helpers. A much cleaner approach here would be to | |
479 | switch fbcon to the `threaded printk support | |
480 | <https://lwn.net/Articles/800946/>`_. | |
0e70dad0 TR |
481 | |
482 | * ``drm_can_sleep()`` is a mess. It hides real bugs in normal operations and | |
483 | isn't a full solution for panic paths. We need to make sure that it only | |
484 | returns true if there's a panic going on for real, and fix up all the | |
485 | fallout. | |
486 | ||
487 | * The panic handler must never sleep, which also means it can't ever | |
488 | ``mutex_lock()``. Also it can't grab any other lock unconditionally, not | |
489 | even spinlocks (because NMI and hardirq can panic too). We need to either | |
490 | make sure to not call such paths, or trylock everything. Really tricky. | |
491 | ||
4db3189c DV |
492 | * A clean solution would be an entirely separate panic output support in KMS, |
493 | bypassing the current fbcon support. See `[PATCH v2 0/3] drm: Add panic handling | |
494 | <https://lore.kernel.org/dri-devel/20190311174218.51899-1-noralf@tronnes.org/>`_. | |
0e70dad0 | 495 | |
4db3189c DV |
496 | * Encoding the actual oops and preceding dmesg in a QR might help with the |
497 | dread "important stuff scrolled away" problem. See `[RFC][PATCH] Oops messages | |
498 | transfer using QR codes | |
499 | <https://lore.kernel.org/lkml/1446217392-11981-1-git-send-email-alexandru.murtaza@intel.com/>`_ | |
500 | for some example code that could be reused. | |
0e70dad0 TR |
501 | |
502 | Contact: Daniel Vetter | |
503 | ||
a5e5cf98 DV |
504 | Level: Advanced |
505 | ||
0cad7f71 DV |
506 | Clean up the debugfs support |
507 | ---------------------------- | |
508 | ||
509 | There's a bunch of issues with it: | |
510 | ||
511 | - The drm_info_list ->show() function doesn't even bother to cast to the drm | |
512 | structure for you. This is lazy. | |
513 | ||
514 | - We probably want to have some support for debugfs files on crtc/connectors and | |
515 | maybe other kms objects directly in core. There's even drm_print support in | |
516 | the funcs for these objects to dump kms state, so it's all there. And then the | |
517 | ->show() functions should obviously give you a pointer to the right object. | |
518 | ||
519 | - The drm_info_list stuff is centered on drm_minor instead of drm_device. For | |
520 | anything we want to print drm_device (or maybe drm_file) is the right thing. | |
521 | ||
522 | - The drm_driver->debugfs_init hooks we have is just an artifact of the old | |
523 | midlayered load sequence. DRM debugfs should work more like sysfs, where you | |
524 | can create properties/files for an object anytime you want, and the core | |
525 | takes care of publishing/unpuplishing all the files at register/unregister | |
526 | time. Drivers shouldn't need to worry about these technicalities, and fixing | |
527 | this (together with the drm_minor->drm_device move) would allow us to remove | |
528 | debugfs_init. | |
529 | ||
bbbb6fda DV |
530 | Previous RFC that hasn't landed yet: https://lore.kernel.org/dri-devel/20200513114130.28641-2-wambui.karugax@gmail.com/ |
531 | ||
0cad7f71 DV |
532 | Contact: Daniel Vetter |
533 | ||
a5e5cf98 DV |
534 | Level: Intermediate |
535 | ||
6a56d09b DV |
536 | Object lifetime fixes |
537 | --------------------- | |
538 | ||
539 | There's two related issues here | |
540 | ||
541 | - Cleanup up the various ->destroy callbacks, which often are all the same | |
542 | simple code. | |
81a7bd4a | 543 | |
6a56d09b DV |
544 | - Lots of drivers erroneously allocate DRM modeset objects using devm_kzalloc, |
545 | which results in use-after free issues on driver unload. This can be serious | |
546 | trouble even for drivers for hardware integrated on the SoC due to | |
547 | EPROBE_DEFERRED backoff. | |
81a7bd4a | 548 | |
6a56d09b DV |
549 | Both these problems can be solved by switching over to drmm_kzalloc(), and the |
550 | various convenience wrappers provided, e.g. drmm_crtc_alloc_with_planes(), | |
551 | drmm_universal_plane_alloc(), ... and so on. | |
e6a3e405 | 552 | |
6a56d09b | 553 | Contact: Daniel Vetter |
e6a3e405 | 554 | |
a5e5cf98 DV |
555 | Level: Intermediate |
556 | ||
659ab7a4 TZ |
557 | Remove automatic page mapping from dma-buf importing |
558 | ---------------------------------------------------- | |
559 | ||
560 | When importing dma-bufs, the dma-buf and PRIME frameworks automatically map | |
561 | imported pages into the importer's DMA area. drm_gem_prime_fd_to_handle() and | |
562 | drm_gem_prime_handle_to_fd() require that importers call dma_buf_attach() | |
563 | even if they never do actual device DMA, but only CPU access through | |
564 | dma_buf_vmap(). This is a problem for USB devices, which do not support DMA | |
565 | operations. | |
566 | ||
567 | To fix the issue, automatic page mappings should be removed from the | |
568 | buffer-sharing code. Fixing this is a bit more involved, since the import/export | |
569 | cache is also tied to &drm_gem_object.import_attach. Meanwhile we paper over | |
570 | this problem for USB devices by fishing out the USB host controller device, as | |
571 | long as that supports DMA. Otherwise importing can still needlessly fail. | |
572 | ||
573 | Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter | |
574 | ||
575 | Level: Advanced | |
576 | ||
577 | ||
0e70dad0 TR |
578 | Better Testing |
579 | ============== | |
580 | ||
596c35b1 JMC |
581 | Add unit tests using the Kernel Unit Testing (KUnit) framework |
582 | -------------------------------------------------------------- | |
583 | ||
584 | The `KUnit <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_ | |
585 | provides a common framework for unit tests within the Linux kernel. Having a | |
586 | test suite would allow to identify regressions earlier. | |
587 | ||
588 | A good candidate for the first unit tests are the format-conversion helpers in | |
589 | ``drm_format_helper.c``. | |
590 | ||
591 | Contact: Javier Martinez Canillas <javierm@redhat.com> | |
592 | ||
593 | Level: Intermediate | |
594 | ||
0e70dad0 TR |
595 | Enable trinity for DRM |
596 | ---------------------- | |
597 | ||
598 | And fix up the fallout. Should be really interesting ... | |
599 | ||
a5e5cf98 DV |
600 | Level: Advanced |
601 | ||
0e70dad0 TR |
602 | Make KMS tests in i-g-t generic |
603 | ------------------------------- | |
604 | ||
605 | The i915 driver team maintains an extensive testsuite for the i915 DRM driver, | |
606 | including tons of testcases for corner-cases in the modesetting API. It would | |
607 | be awesome if those tests (at least the ones not relying on Intel-specific GEM | |
608 | features) could be made to run on any KMS driver. | |
609 | ||
610 | Basic work to run i-g-t tests on non-i915 is done, what's now missing is mass- | |
611 | converting things over. For modeset tests we also first need a bit of | |
612 | infrastructure to use dumb buffers for untiled buffers, to be able to run all | |
613 | the non-i915 specific modeset tests. | |
614 | ||
a5e5cf98 DV |
615 | Level: Advanced |
616 | ||
ad9ff96f HM |
617 | Extend virtual test driver (VKMS) |
618 | --------------------------------- | |
619 | ||
620 | See the documentation of :ref:`VKMS <vkms>` for more details. This is an ideal | |
621 | internship task, since it only requires a virtual machine and can be sized to | |
622 | fit the available time. | |
623 | ||
a5e5cf98 DV |
624 | Level: See details |
625 | ||
3c745e0b DV |
626 | Backlight Refactoring |
627 | --------------------- | |
628 | ||
629 | Backlight drivers have a triple enable/disable state, which is a bit overkill. | |
630 | Plan to fix this: | |
631 | ||
632 | 1. Roll out backlight_enable() and backlight_disable() helpers everywhere. This | |
633 | has started already. | |
634 | 2. In all, only look at one of the three status bits set by the above helpers. | |
635 | 3. Remove the other two status bits. | |
636 | ||
637 | Contact: Daniel Vetter | |
638 | ||
a5e5cf98 DV |
639 | Level: Intermediate |
640 | ||
0e70dad0 TR |
641 | Driver Specific |
642 | =============== | |
643 | ||
0a26a45d HW |
644 | AMD DC Display Driver |
645 | --------------------- | |
646 | ||
647 | AMD DC is the display driver for AMD devices starting with Vega. There has been | |
648 | a bunch of progress cleaning it up but there's still plenty of work to be done. | |
649 | ||
650 | See drivers/gpu/drm/amd/display/TODO for tasks. | |
651 | ||
652 | Contact: Harry Wentland, Alex Deucher | |
653 | ||
2985c964 TZ |
654 | vmwgfx: Replace hashtable with Linux' implementation |
655 | ---------------------------------------------------- | |
656 | ||
657 | The vmwgfx driver uses its own hashtable implementation. Replace the | |
658 | code with Linux' implementation and update the callers. It's mostly a | |
659 | refactoring task, but the interfaces are different. | |
660 | ||
661 | Contact: Zack Rusin, Thomas Zimmermann <tzimmermann@suse.de> | |
662 | ||
663 | Level: Intermediate | |
664 | ||
ce256008 NT |
665 | Bootsplash |
666 | ========== | |
667 | ||
668 | There is support in place now for writing internal DRM clients making it | |
669 | possible to pick up the bootsplash work that was rejected because it was written | |
670 | for fbdev. | |
671 | ||
672 | - [v6,8/8] drm/client: Hack: Add bootsplash example | |
673 | https://patchwork.freedesktop.org/patch/306579/ | |
674 | ||
675 | - [RFC PATCH v2 00/13] Kernel based bootsplash | |
05a5f51c | 676 | https://lore.kernel.org/r/20171213194755.3409-1-mstaudt@suse.de |
ce256008 NT |
677 | |
678 | Contact: Sam Ravnborg | |
679 | ||
a5e5cf98 DV |
680 | Level: Advanced |
681 | ||
4f96b1bc HG |
682 | Brightness handling on devices with multiple internal panels |
683 | ============================================================ | |
684 | ||
685 | On x86/ACPI devices there can be multiple backlight firmware interfaces: | |
686 | (ACPI) video, vendor specific and others. As well as direct/native (PWM) | |
687 | register programming by the KMS driver. | |
688 | ||
689 | To deal with this backlight drivers used on x86/ACPI call | |
690 | acpi_video_get_backlight_type() which has heuristics (+quirks) to select | |
691 | which backlight interface to use; and backlight drivers which do not match | |
692 | the returned type will not register themselves, so that only one backlight | |
693 | device gets registered (in a single GPU setup, see below). | |
694 | ||
695 | At the moment this more or less assumes that there will only | |
696 | be 1 (internal) panel on a system. | |
697 | ||
698 | On systems with 2 panels this may be a problem, depending on | |
699 | what interface acpi_video_get_backlight_type() selects: | |
700 | ||
701 | 1. native: in this case the KMS driver is expected to know which backlight | |
702 | device belongs to which output so everything should just work. | |
703 | 2. video: this does support controlling multiple backlights, but some work | |
704 | will need to be done to get the output <-> backlight device mapping | |
705 | ||
706 | The above assumes both panels will require the same backlight interface type. | |
707 | Things will break on systems with multiple panels where the 2 panels need | |
708 | a different type of control. E.g. one panel needs ACPI video backlight control, | |
709 | where as the other is using native backlight control. Currently in this case | |
710 | only one of the 2 required backlight devices will get registered, based on | |
711 | the acpi_video_get_backlight_type() return value. | |
712 | ||
713 | If this (theoretical) case ever shows up, then supporting this will need some | |
714 | work. A possible solution here would be to pass a device and connector-name | |
715 | to acpi_video_get_backlight_type() so that it can deal with this. | |
716 | ||
717 | Note in a way we already have a case where userspace sees 2 panels, | |
718 | in dual GPU laptop setups with a mux. On those systems we may see | |
719 | either 2 native backlight devices; or 2 native backlight devices. | |
720 | ||
721 | Userspace already has code to deal with this by detecting if the related | |
722 | panel is active (iow which way the mux between the GPU and the panels | |
723 | points) and then uses that backlight device. Userspace here very much | |
724 | assumes a single panel though. It picks only 1 of the 2 backlight devices | |
725 | and then only uses that one. | |
726 | ||
727 | Note that all userspace code (that I know off) is currently hardcoded | |
728 | to assume a single panel. | |
729 | ||
730 | Before the recent changes to not register multiple (e.g. video + native) | |
731 | /sys/class/backlight devices for a single panel (on a single GPU laptop), | |
732 | userspace would see multiple backlight devices all controlling the same | |
733 | backlight. | |
734 | ||
735 | To deal with this userspace had to always picks one preferred device under | |
736 | /sys/class/backlight and will ignore the others. So to support brightness | |
737 | control on multiple panels userspace will need to be updated too. | |
738 | ||
739 | There are plans to allow brightness control through the KMS API by adding | |
740 | a "display brightness" property to drm_connector objects for panels. This | |
741 | solves a number of issues with the /sys/class/backlight API, including not | |
742 | being able to map a sysfs backlight device to a specific connector. Any | |
743 | userspace changes to add support for brightness control on devices with | |
744 | multiple panels really should build on top of this new KMS property. | |
745 | ||
746 | Contact: Hans de Goede | |
747 | ||
748 | Level: Advanced | |
749 | ||
0e70dad0 TR |
750 | Outside DRM |
751 | =========== | |
3c2ed9ce TZ |
752 | |
753 | Convert fbdev drivers to DRM | |
754 | ---------------------------- | |
755 | ||
0f9c4296 | 756 | There are plenty of fbdev drivers for older hardware. Some hardware has |
3c2ed9ce TZ |
757 | become obsolete, but some still provides good(-enough) framebuffers. The |
758 | drivers that are still useful should be converted to DRM and afterwards | |
759 | removed from fbdev. | |
760 | ||
761 | Very simple fbdev drivers can best be converted by starting with a new | |
762 | DRM driver. Simple KMS helpers and SHMEM should be able to handle any | |
763 | existing hardware. The new driver's call-back functions are filled from | |
764 | existing fbdev code. | |
765 | ||
766 | More complex fbdev drivers can be refactored step-by-step into a DRM | |
767 | driver with the help of the DRM fbconv helpers. [1] These helpers provide | |
768 | the transition layer between the DRM core infrastructure and the fbdev | |
769 | driver interface. Create a new DRM driver on top of the fbconv helpers, | |
770 | copy over the fbdev driver, and hook it up to the DRM code. Examples for | |
771 | several fbdev drivers are available at [1] and a tutorial of this process | |
772 | available at [2]. The result is a primitive DRM driver that can run X11 | |
773 | and Weston. | |
774 | ||
775 | - [1] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv | |
776 | - [2] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c | |
777 | ||
778 | Contact: Thomas Zimmermann <tzimmermann@suse.de> | |
a5e5cf98 DV |
779 | |
780 | Level: Advanced |