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