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 | |
225 | struct dma_buf_map, drivers with frambuffers in I/O memory can be supported | |
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 | |
237 | helpers could further benefit from using struct dma_buf_map instead of | |
238 | raw pointers. | |
239 | ||
240 | Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter | |
241 | ||
242 | Level: Advanced | |
243 | ||
244 | ||
2c81bdc8 DV |
245 | drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup |
246 | ----------------------------------------------------------------- | |
247 | ||
248 | A lot more drivers could be switched over to the drm_gem_framebuffer helpers. | |
249 | Various hold-ups: | |
250 | ||
251 | - Need to switch over to the generic dirty tracking code using | |
252 | drm_atomic_helper_dirtyfb first (e.g. qxl). | |
253 | ||
254 | - Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb | |
255 | setup code can't be deleted. | |
256 | ||
257 | - Many drivers wrap drm_gem_fb_create() only to check for valid formats. For | |
258 | atomic drivers we could check for valid formats by calling | |
259 | drm_plane_check_pixel_format() against all planes, and pass if any plane | |
260 | supports the format. For non-atomic that's not possible since like the format | |
261 | list for the primary plane is fake and we'd therefor reject valid formats. | |
262 | ||
263 | - Many drivers subclass drm_framebuffer, we'd need a embedding compatible | |
264 | version of the varios drm_gem_fb_create functions. Maybe called | |
265 | drm_gem_fb_create/_with_dirty/_with_funcs as needed. | |
266 | ||
267 | Contact: Daniel Vetter | |
268 | ||
269 | Level: Intermediate | |
270 | ||
66499101 DV |
271 | Clean up mmap forwarding |
272 | ------------------------ | |
273 | ||
274 | A lot of drivers forward gem mmap calls to dma-buf mmap for imported buffers. | |
275 | And also a lot of them forward dma-buf mmap to the gem mmap implementations. | |
8de6ca2e | 276 | There's drm_gem_prime_mmap() for this now, but still needs to be rolled out. |
66499101 DV |
277 | |
278 | Contact: Daniel Vetter | |
279 | ||
a5e5cf98 DV |
280 | Level: Intermediate |
281 | ||
be5cadc7 DV |
282 | Generic fbdev defio support |
283 | --------------------------- | |
284 | ||
285 | The defio support code in the fbdev core has some very specific requirements, | |
955a72ce TZ |
286 | which means drivers need to have a special framebuffer for fbdev. The main |
287 | issue is that it uses some fields in struct page itself, which breaks shmem | |
288 | gem objects (and other things). To support defio, affected drivers require | |
289 | the use of a shadow buffer, which may add CPU and memory overhead. | |
be5cadc7 DV |
290 | |
291 | Possible solution would be to write our own defio mmap code in the drm fbdev | |
292 | emulation. It would need to fully wrap the existing mmap ops, forwarding | |
293 | everything after it has done the write-protect/mkwrite trickery: | |
294 | ||
295 | - In the drm_fbdev_fb_mmap helper, if we need defio, change the | |
296 | default page prots to write-protected with something like this:: | |
297 | ||
298 | vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot); | |
299 | ||
300 | - Set the mkwrite and fsync callbacks with similar implementions to the core | |
301 | fbdev defio stuff. These should all work on plain ptes, they don't actually | |
302 | require a struct page. uff. These should all work on plain ptes, they don't | |
303 | actually require a struct page. | |
304 | ||
305 | - Track the dirty pages in a separate structure (bitfield with one bit per page | |
306 | should work) to avoid clobbering struct page. | |
307 | ||
308 | Might be good to also have some igt testcases for this. | |
309 | ||
310 | Contact: Daniel Vetter, Noralf Tronnes | |
311 | ||
a5e5cf98 DV |
312 | Level: Advanced |
313 | ||
39aead83 DV |
314 | Garbage collect fbdev scrolling acceleration |
315 | -------------------------------------------- | |
316 | ||
317 | Scroll acceleration is disabled in fbcon by hard-wiring p->scrollmode = | |
318 | SCROLL_REDRAW. There's a ton of code this will allow us to remove: | |
fa388231 | 319 | |
39aead83 | 320 | - lots of code in fbcon.c |
fa388231 | 321 | |
39aead83 DV |
322 | - a bunch of the hooks in fbcon_ops, maybe the remaining hooks could be called |
323 | directly instead of the function table (with a switch on p->rotate) | |
fa388231 | 324 | |
39aead83 DV |
325 | - fb_copyarea is unused after this, and can be deleted from all drivers |
326 | ||
327 | Note that not all acceleration code can be deleted, since clearing and cursor | |
328 | support is still accelerated, which might be good candidates for further | |
329 | deletion projects. | |
330 | ||
331 | Contact: Daniel Vetter | |
332 | ||
333 | Level: Intermediate | |
334 | ||
1aecabb5 DV |
335 | idr_init_base() |
336 | --------------- | |
337 | ||
338 | DRM core&drivers uses a lot of idr (integer lookup directories) for mapping | |
339 | userspace IDs to internal objects, and in most places ID=0 means NULL and hence | |
340 | is never used. Switching to idr_init_base() for these would make the idr more | |
341 | efficient. | |
342 | ||
343 | Contact: Daniel Vetter | |
344 | ||
a5e5cf98 DV |
345 | Level: Starter |
346 | ||
b39b5394 NT |
347 | struct drm_gem_object_funcs |
348 | --------------------------- | |
349 | ||
350 | GEM objects can now have a function table instead of having the callbacks on the | |
d693def4 TZ |
351 | DRM driver struct. This is now the preferred way. Callbacks in drivers have been |
352 | converted, except for struct drm_driver.gem_prime_mmap. | |
8db420ac | 353 | |
a5e5cf98 DV |
354 | Level: Intermediate |
355 | ||
22be8740 SP |
356 | Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate |
357 | --------------------------------------------------------- | |
358 | ||
359 | For cases where drivers are attempting to grab the modeset locks with a local | |
360 | acquire context. Replace the boilerplate code surrounding | |
361 | drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN() and | |
362 | DRM_MODESET_LOCK_ALL_END() instead. | |
363 | ||
7da15640 | 364 | This should also be done for all places where drm_modeset_lock_all() is still |
22be8740 SP |
365 | used. |
366 | ||
367 | As a reference, take a look at the conversions already completed in drm core. | |
368 | ||
369 | Contact: Sean Paul, respective driver maintainers | |
370 | ||
a5e5cf98 DV |
371 | Level: Starter |
372 | ||
e57924d4 DV |
373 | Rename CMA helpers to DMA helpers |
374 | --------------------------------- | |
375 | ||
376 | CMA (standing for contiguous memory allocator) is really a bit an accident of | |
377 | what these were used for first, a much better name would be DMA helpers. In the | |
378 | text these should even be called coherent DMA memory helpers (so maybe CDM, but | |
379 | no one knows what that means) since underneath they just use dma_alloc_coherent. | |
380 | ||
381 | Contact: Laurent Pinchart, Daniel Vetter | |
382 | ||
a5e5cf98 DV |
383 | Level: Intermediate (mostly because it is a huge tasks without good partial |
384 | milestones, not technically itself that challenging) | |
385 | ||
69b22f51 DV |
386 | connector register/unregister fixes |
387 | ----------------------------------- | |
388 | ||
389 | - For most connectors it's a no-op to call drm_connector_register/unregister | |
390 | directly from driver code, drm_dev_register/unregister take care of this | |
391 | already. We can remove all of them. | |
392 | ||
393 | - For dp drivers it's a bit more a mess, since we need the connector to be | |
394 | registered when calling drm_dp_aux_register. Fix this by instead calling | |
395 | drm_dp_aux_init, and moving the actual registering into a late_register | |
396 | callback as recommended in the kerneldoc. | |
397 | ||
a5e5cf98 DV |
398 | Level: Intermediate |
399 | ||
700496fa DV |
400 | Remove load/unload callbacks from all non-DRIVER_LEGACY drivers |
401 | --------------------------------------------------------------- | |
402 | ||
403 | The load/unload callbacks in struct &drm_driver are very much midlayers, plus | |
404 | for historical reasons they get the ordering wrong (and we can't fix that) | |
405 | between setting up the &drm_driver structure and calling drm_dev_register(). | |
406 | ||
407 | - Rework drivers to no longer use the load/unload callbacks, directly coding the | |
408 | load/unload sequence into the driver's probe function. | |
409 | ||
410 | - Once all non-DRIVER_LEGACY drivers are converted, disallow the load/unload | |
411 | callbacks for all modern drivers. | |
412 | ||
413 | Contact: Daniel Vetter | |
414 | ||
415 | Level: Intermediate | |
416 | ||
a92d083d LP |
417 | Replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi |
418 | --------------------------------------------------------------- | |
419 | ||
420 | Once EDID is parsed, the monitor HDMI support information is available through | |
421 | drm_display_info.is_hdmi. Many drivers still call drm_detect_hdmi_monitor() to | |
422 | retrieve the same information, which is less efficient. | |
423 | ||
424 | Audit each individual driver calling drm_detect_hdmi_monitor() and switch to | |
425 | drm_display_info.is_hdmi if applicable. | |
426 | ||
427 | Contact: Laurent Pinchart, respective driver maintainers | |
428 | ||
429 | Level: Intermediate | |
430 | ||
c3274799 EV |
431 | Consolidate custom driver modeset properties |
432 | -------------------------------------------- | |
433 | ||
434 | Before atomic modeset took place, many drivers where creating their own | |
435 | properties. Among other things, atomic brought the requirement that custom, | |
436 | driver specific properties should not be used. | |
437 | ||
438 | For this task, we aim to introduce core helpers or reuse the existing ones | |
439 | if available: | |
440 | ||
441 | A quick, unconfirmed, examples list. | |
442 | ||
443 | Introduce core helpers: | |
444 | - audio (amdgpu, intel, gma500, radeon) | |
445 | - brightness, contrast, etc (armada, nouveau) - overlay only (?) | |
446 | - broadcast rgb (gma500, intel) | |
447 | - colorkey (armada, nouveau, rcar) - overlay only (?) | |
448 | - dither (amdgpu, nouveau, radeon) - varies across drivers | |
449 | - underscan family (amdgpu, radeon, nouveau) | |
450 | ||
451 | Already in core: | |
452 | - colorspace (sti) | |
453 | - tv format names, enhancements (gma500, intel) | |
454 | - tv overscan, margins, etc. (gma500, intel) | |
455 | - zorder (omapdrm) - same as zpos (?) | |
456 | ||
457 | ||
458 | Contact: Emil Velikov, respective driver maintainers | |
459 | ||
460 | Level: Intermediate | |
6142b1b8 | 461 | |
49a3f51d TZ |
462 | Use struct dma_buf_map throughout codebase |
463 | ------------------------------------------ | |
464 | ||
465 | Pointers to shared device memory are stored in struct dma_buf_map. Each | |
466 | instance knows whether it refers to system or I/O memory. Most of the DRM-wide | |
467 | interface have been converted to use struct dma_buf_map, but implementations | |
468 | often still use raw pointers. | |
469 | ||
470 | The task is to use struct dma_buf_map where it makes sense. | |
471 | ||
472 | * Memory managers should use struct dma_buf_map for dma-buf-imported buffers. | |
473 | * TTM might benefit from using struct dma_buf_map internally. | |
474 | * Framebuffer copying and blitting helpers should operate on struct dma_buf_map. | |
475 | ||
476 | Contact: Thomas Zimmermann <tzimmermann@suse.de>, Christian König, Daniel Vetter | |
477 | ||
478 | Level: Intermediate | |
479 | ||
c3274799 | 480 | |
0e70dad0 TR |
481 | Core refactorings |
482 | ================= | |
483 | ||
0e70dad0 TR |
484 | Make panic handling work |
485 | ------------------------ | |
486 | ||
487 | This is a really varied tasks with lots of little bits and pieces: | |
488 | ||
489 | * The panic path can't be tested currently, leading to constant breaking. The | |
490 | main issue here is that panics can be triggered from hardirq contexts and | |
491 | hence all panic related callback can run in hardirq context. It would be | |
492 | awesome if we could test at least the fbdev helper code and driver code by | |
493 | e.g. trigger calls through drm debugfs files. hardirq context could be | |
494 | achieved by using an IPI to the local processor. | |
495 | ||
496 | * There's a massive confusion of different panic handlers. DRM fbdev emulation | |
497 | helpers have one, but on top of that the fbcon code itself also has one. We | |
498 | need to make sure that they stop fighting over each another. | |
499 | ||
500 | * ``drm_can_sleep()`` is a mess. It hides real bugs in normal operations and | |
501 | isn't a full solution for panic paths. We need to make sure that it only | |
502 | returns true if there's a panic going on for real, and fix up all the | |
503 | fallout. | |
504 | ||
505 | * The panic handler must never sleep, which also means it can't ever | |
506 | ``mutex_lock()``. Also it can't grab any other lock unconditionally, not | |
507 | even spinlocks (because NMI and hardirq can panic too). We need to either | |
508 | make sure to not call such paths, or trylock everything. Really tricky. | |
509 | ||
510 | * For the above locking troubles reasons it's pretty much impossible to | |
511 | attempt a synchronous modeset from panic handlers. The only thing we could | |
512 | try to achive is an atomic ``set_base`` of the primary plane, and hope that | |
513 | it shows up. Everything else probably needs to be delayed to some worker or | |
514 | something else which happens later on. Otherwise it just kills the box | |
515 | harder, prevent the panic from going out on e.g. netconsole. | |
516 | ||
517 | * There's also proposal for a simplied DRM console instead of the full-blown | |
518 | fbcon and DRM fbdev emulation. Any kind of panic handling tricks should | |
519 | obviously work for both console, in case we ever get kmslog merged. | |
520 | ||
521 | Contact: Daniel Vetter | |
522 | ||
a5e5cf98 DV |
523 | Level: Advanced |
524 | ||
0cad7f71 DV |
525 | Clean up the debugfs support |
526 | ---------------------------- | |
527 | ||
528 | There's a bunch of issues with it: | |
529 | ||
530 | - The drm_info_list ->show() function doesn't even bother to cast to the drm | |
531 | structure for you. This is lazy. | |
532 | ||
533 | - We probably want to have some support for debugfs files on crtc/connectors and | |
534 | maybe other kms objects directly in core. There's even drm_print support in | |
535 | the funcs for these objects to dump kms state, so it's all there. And then the | |
536 | ->show() functions should obviously give you a pointer to the right object. | |
537 | ||
538 | - The drm_info_list stuff is centered on drm_minor instead of drm_device. For | |
539 | anything we want to print drm_device (or maybe drm_file) is the right thing. | |
540 | ||
541 | - The drm_driver->debugfs_init hooks we have is just an artifact of the old | |
542 | midlayered load sequence. DRM debugfs should work more like sysfs, where you | |
543 | can create properties/files for an object anytime you want, and the core | |
544 | takes care of publishing/unpuplishing all the files at register/unregister | |
545 | time. Drivers shouldn't need to worry about these technicalities, and fixing | |
546 | this (together with the drm_minor->drm_device move) would allow us to remove | |
547 | debugfs_init. | |
548 | ||
bbbb6fda DV |
549 | Previous RFC that hasn't landed yet: https://lore.kernel.org/dri-devel/20200513114130.28641-2-wambui.karugax@gmail.com/ |
550 | ||
0cad7f71 DV |
551 | Contact: Daniel Vetter |
552 | ||
a5e5cf98 DV |
553 | Level: Intermediate |
554 | ||
6a56d09b DV |
555 | Object lifetime fixes |
556 | --------------------- | |
557 | ||
558 | There's two related issues here | |
559 | ||
560 | - Cleanup up the various ->destroy callbacks, which often are all the same | |
561 | simple code. | |
81a7bd4a | 562 | |
6a56d09b DV |
563 | - Lots of drivers erroneously allocate DRM modeset objects using devm_kzalloc, |
564 | which results in use-after free issues on driver unload. This can be serious | |
565 | trouble even for drivers for hardware integrated on the SoC due to | |
566 | EPROBE_DEFERRED backoff. | |
81a7bd4a | 567 | |
6a56d09b DV |
568 | Both these problems can be solved by switching over to drmm_kzalloc(), and the |
569 | various convenience wrappers provided, e.g. drmm_crtc_alloc_with_planes(), | |
570 | drmm_universal_plane_alloc(), ... and so on. | |
e6a3e405 | 571 | |
6a56d09b | 572 | Contact: Daniel Vetter |
e6a3e405 | 573 | |
a5e5cf98 DV |
574 | Level: Intermediate |
575 | ||
659ab7a4 TZ |
576 | Remove automatic page mapping from dma-buf importing |
577 | ---------------------------------------------------- | |
578 | ||
579 | When importing dma-bufs, the dma-buf and PRIME frameworks automatically map | |
580 | imported pages into the importer's DMA area. drm_gem_prime_fd_to_handle() and | |
581 | drm_gem_prime_handle_to_fd() require that importers call dma_buf_attach() | |
582 | even if they never do actual device DMA, but only CPU access through | |
583 | dma_buf_vmap(). This is a problem for USB devices, which do not support DMA | |
584 | operations. | |
585 | ||
586 | To fix the issue, automatic page mappings should be removed from the | |
587 | buffer-sharing code. Fixing this is a bit more involved, since the import/export | |
588 | cache is also tied to &drm_gem_object.import_attach. Meanwhile we paper over | |
589 | this problem for USB devices by fishing out the USB host controller device, as | |
590 | long as that supports DMA. Otherwise importing can still needlessly fail. | |
591 | ||
592 | Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter | |
593 | ||
594 | Level: Advanced | |
595 | ||
596 | ||
0e70dad0 TR |
597 | Better Testing |
598 | ============== | |
599 | ||
600 | Enable trinity for DRM | |
601 | ---------------------- | |
602 | ||
603 | And fix up the fallout. Should be really interesting ... | |
604 | ||
a5e5cf98 DV |
605 | Level: Advanced |
606 | ||
0e70dad0 TR |
607 | Make KMS tests in i-g-t generic |
608 | ------------------------------- | |
609 | ||
610 | The i915 driver team maintains an extensive testsuite for the i915 DRM driver, | |
611 | including tons of testcases for corner-cases in the modesetting API. It would | |
612 | be awesome if those tests (at least the ones not relying on Intel-specific GEM | |
613 | features) could be made to run on any KMS driver. | |
614 | ||
615 | Basic work to run i-g-t tests on non-i915 is done, what's now missing is mass- | |
616 | converting things over. For modeset tests we also first need a bit of | |
617 | infrastructure to use dumb buffers for untiled buffers, to be able to run all | |
618 | the non-i915 specific modeset tests. | |
619 | ||
a5e5cf98 DV |
620 | Level: Advanced |
621 | ||
ad9ff96f HM |
622 | Extend virtual test driver (VKMS) |
623 | --------------------------------- | |
624 | ||
625 | See the documentation of :ref:`VKMS <vkms>` for more details. This is an ideal | |
626 | internship task, since it only requires a virtual machine and can be sized to | |
627 | fit the available time. | |
628 | ||
a5e5cf98 DV |
629 | Level: See details |
630 | ||
3c745e0b DV |
631 | Backlight Refactoring |
632 | --------------------- | |
633 | ||
634 | Backlight drivers have a triple enable/disable state, which is a bit overkill. | |
635 | Plan to fix this: | |
636 | ||
637 | 1. Roll out backlight_enable() and backlight_disable() helpers everywhere. This | |
638 | has started already. | |
639 | 2. In all, only look at one of the three status bits set by the above helpers. | |
640 | 3. Remove the other two status bits. | |
641 | ||
642 | Contact: Daniel Vetter | |
643 | ||
a5e5cf98 DV |
644 | Level: Intermediate |
645 | ||
0e70dad0 TR |
646 | Driver Specific |
647 | =============== | |
648 | ||
0a26a45d HW |
649 | AMD DC Display Driver |
650 | --------------------- | |
651 | ||
652 | AMD DC is the display driver for AMD devices starting with Vega. There has been | |
653 | a bunch of progress cleaning it up but there's still plenty of work to be done. | |
654 | ||
655 | See drivers/gpu/drm/amd/display/TODO for tasks. | |
656 | ||
657 | Contact: Harry Wentland, Alex Deucher | |
658 | ||
ce256008 NT |
659 | Bootsplash |
660 | ========== | |
661 | ||
662 | There is support in place now for writing internal DRM clients making it | |
663 | possible to pick up the bootsplash work that was rejected because it was written | |
664 | for fbdev. | |
665 | ||
666 | - [v6,8/8] drm/client: Hack: Add bootsplash example | |
667 | https://patchwork.freedesktop.org/patch/306579/ | |
668 | ||
669 | - [RFC PATCH v2 00/13] Kernel based bootsplash | |
05a5f51c | 670 | https://lore.kernel.org/r/20171213194755.3409-1-mstaudt@suse.de |
ce256008 NT |
671 | |
672 | Contact: Sam Ravnborg | |
673 | ||
a5e5cf98 DV |
674 | Level: Advanced |
675 | ||
0e70dad0 TR |
676 | Outside DRM |
677 | =========== | |
3c2ed9ce TZ |
678 | |
679 | Convert fbdev drivers to DRM | |
680 | ---------------------------- | |
681 | ||
0f9c4296 | 682 | There are plenty of fbdev drivers for older hardware. Some hardware has |
3c2ed9ce TZ |
683 | become obsolete, but some still provides good(-enough) framebuffers. The |
684 | drivers that are still useful should be converted to DRM and afterwards | |
685 | removed from fbdev. | |
686 | ||
687 | Very simple fbdev drivers can best be converted by starting with a new | |
688 | DRM driver. Simple KMS helpers and SHMEM should be able to handle any | |
689 | existing hardware. The new driver's call-back functions are filled from | |
690 | existing fbdev code. | |
691 | ||
692 | More complex fbdev drivers can be refactored step-by-step into a DRM | |
693 | driver with the help of the DRM fbconv helpers. [1] These helpers provide | |
694 | the transition layer between the DRM core infrastructure and the fbdev | |
695 | driver interface. Create a new DRM driver on top of the fbconv helpers, | |
696 | copy over the fbdev driver, and hook it up to the DRM code. Examples for | |
697 | several fbdev drivers are available at [1] and a tutorial of this process | |
698 | available at [2]. The result is a primitive DRM driver that can run X11 | |
699 | and Weston. | |
700 | ||
701 | - [1] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv | |
702 | - [2] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c | |
703 | ||
704 | Contact: Thomas Zimmermann <tzimmermann@suse.de> | |
a5e5cf98 DV |
705 | |
706 | Level: Advanced |