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 | ||
e2e2e008 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 | ||
e2e2e008 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 | |
461 | ||
6142b1b8 VS |
462 | Plumb drm_atomic_state all over |
463 | ------------------------------- | |
464 | ||
465 | Currently various atomic functions take just a single or a handful of | |
466 | object states (eg. plane state). While that single object state can | |
467 | suffice for some simple cases, we often have to dig out additional | |
468 | object states for dealing with various dependencies between the individual | |
469 | objects or the hardware they represent. The process of digging out the | |
470 | additional states is rather non-intuitive and error prone. | |
471 | ||
472 | To fix that most functions should rather take the overall | |
473 | drm_atomic_state as one of their parameters. The other parameters | |
474 | would generally be the object(s) we mainly want to interact with. | |
475 | ||
476 | For example, instead of | |
477 | ||
478 | .. code-block:: c | |
479 | ||
480 | int (*atomic_check)(struct drm_plane *plane, struct drm_plane_state *state); | |
481 | ||
482 | we would have something like | |
483 | ||
484 | .. code-block:: c | |
485 | ||
486 | int (*atomic_check)(struct drm_plane *plane, struct drm_atomic_state *state); | |
487 | ||
488 | The implementation can then trivially gain access to any required object | |
489 | state(s) via drm_atomic_get_plane_state(), drm_atomic_get_new_plane_state(), | |
490 | drm_atomic_get_old_plane_state(), and their equivalents for | |
491 | other object types. | |
492 | ||
493 | Additionally many drivers currently access the object->state pointer | |
494 | directly in their commit functions. That is not going to work if we | |
495 | eg. want to allow deeper commit pipelines as those pointers could | |
496 | then point to the states corresponding to a future commit instead of | |
497 | the current commit we're trying to process. Also non-blocking commits | |
498 | execute locklessly so there are serious concerns with dereferencing | |
499 | the object->state pointers without holding the locks that protect them. | |
500 | Use of drm_atomic_get_new_plane_state(), drm_atomic_get_old_plane_state(), | |
501 | etc. avoids these problems as well since they relate to a specific | |
502 | commit via the passed in drm_atomic_state. | |
503 | ||
504 | Contact: Ville Syrjälä, Daniel Vetter | |
505 | ||
506 | Level: Intermediate | |
507 | ||
49a3f51d TZ |
508 | Use struct dma_buf_map throughout codebase |
509 | ------------------------------------------ | |
510 | ||
511 | Pointers to shared device memory are stored in struct dma_buf_map. Each | |
512 | instance knows whether it refers to system or I/O memory. Most of the DRM-wide | |
513 | interface have been converted to use struct dma_buf_map, but implementations | |
514 | often still use raw pointers. | |
515 | ||
516 | The task is to use struct dma_buf_map where it makes sense. | |
517 | ||
518 | * Memory managers should use struct dma_buf_map for dma-buf-imported buffers. | |
519 | * TTM might benefit from using struct dma_buf_map internally. | |
520 | * Framebuffer copying and blitting helpers should operate on struct dma_buf_map. | |
521 | ||
522 | Contact: Thomas Zimmermann <tzimmermann@suse.de>, Christian König, Daniel Vetter | |
523 | ||
524 | Level: Intermediate | |
525 | ||
c3274799 | 526 | |
0e70dad0 TR |
527 | Core refactorings |
528 | ================= | |
529 | ||
0e70dad0 TR |
530 | Make panic handling work |
531 | ------------------------ | |
532 | ||
533 | This is a really varied tasks with lots of little bits and pieces: | |
534 | ||
535 | * The panic path can't be tested currently, leading to constant breaking. The | |
536 | main issue here is that panics can be triggered from hardirq contexts and | |
537 | hence all panic related callback can run in hardirq context. It would be | |
538 | awesome if we could test at least the fbdev helper code and driver code by | |
539 | e.g. trigger calls through drm debugfs files. hardirq context could be | |
540 | achieved by using an IPI to the local processor. | |
541 | ||
542 | * There's a massive confusion of different panic handlers. DRM fbdev emulation | |
543 | helpers have one, but on top of that the fbcon code itself also has one. We | |
544 | need to make sure that they stop fighting over each another. | |
545 | ||
546 | * ``drm_can_sleep()`` is a mess. It hides real bugs in normal operations and | |
547 | isn't a full solution for panic paths. We need to make sure that it only | |
548 | returns true if there's a panic going on for real, and fix up all the | |
549 | fallout. | |
550 | ||
551 | * The panic handler must never sleep, which also means it can't ever | |
552 | ``mutex_lock()``. Also it can't grab any other lock unconditionally, not | |
553 | even spinlocks (because NMI and hardirq can panic too). We need to either | |
554 | make sure to not call such paths, or trylock everything. Really tricky. | |
555 | ||
556 | * For the above locking troubles reasons it's pretty much impossible to | |
557 | attempt a synchronous modeset from panic handlers. The only thing we could | |
558 | try to achive is an atomic ``set_base`` of the primary plane, and hope that | |
559 | it shows up. Everything else probably needs to be delayed to some worker or | |
560 | something else which happens later on. Otherwise it just kills the box | |
561 | harder, prevent the panic from going out on e.g. netconsole. | |
562 | ||
563 | * There's also proposal for a simplied DRM console instead of the full-blown | |
564 | fbcon and DRM fbdev emulation. Any kind of panic handling tricks should | |
565 | obviously work for both console, in case we ever get kmslog merged. | |
566 | ||
567 | Contact: Daniel Vetter | |
568 | ||
a5e5cf98 DV |
569 | Level: Advanced |
570 | ||
0cad7f71 DV |
571 | Clean up the debugfs support |
572 | ---------------------------- | |
573 | ||
574 | There's a bunch of issues with it: | |
575 | ||
576 | - The drm_info_list ->show() function doesn't even bother to cast to the drm | |
577 | structure for you. This is lazy. | |
578 | ||
579 | - We probably want to have some support for debugfs files on crtc/connectors and | |
580 | maybe other kms objects directly in core. There's even drm_print support in | |
581 | the funcs for these objects to dump kms state, so it's all there. And then the | |
582 | ->show() functions should obviously give you a pointer to the right object. | |
583 | ||
584 | - The drm_info_list stuff is centered on drm_minor instead of drm_device. For | |
585 | anything we want to print drm_device (or maybe drm_file) is the right thing. | |
586 | ||
587 | - The drm_driver->debugfs_init hooks we have is just an artifact of the old | |
588 | midlayered load sequence. DRM debugfs should work more like sysfs, where you | |
589 | can create properties/files for an object anytime you want, and the core | |
590 | takes care of publishing/unpuplishing all the files at register/unregister | |
591 | time. Drivers shouldn't need to worry about these technicalities, and fixing | |
592 | this (together with the drm_minor->drm_device move) would allow us to remove | |
593 | debugfs_init. | |
594 | ||
595 | Contact: Daniel Vetter | |
596 | ||
a5e5cf98 DV |
597 | Level: Intermediate |
598 | ||
81a7bd4a DV |
599 | KMS cleanups |
600 | ------------ | |
601 | ||
602 | Some of these date from the very introduction of KMS in 2008 ... | |
603 | ||
e6a3e405 DV |
604 | - Make ->funcs and ->helper_private vtables optional. There's a bunch of empty |
605 | function tables in drivers, but before we can remove them we need to make sure | |
606 | that all the users in helpers and drivers do correctly check for a NULL | |
607 | vtable. | |
608 | ||
609 | - Cleanup up the various ->destroy callbacks. A lot of them just wrapt the | |
610 | drm_*_cleanup implementations and can be removed. Some tack a kfree() at the | |
611 | end, for which we could add drm_*_cleanup_kfree(). And then there's the (for | |
612 | historical reasons) misnamed drm_primary_helper_destroy() function. | |
613 | ||
a5e5cf98 DV |
614 | Level: Intermediate |
615 | ||
0e70dad0 TR |
616 | Better Testing |
617 | ============== | |
618 | ||
619 | Enable trinity for DRM | |
620 | ---------------------- | |
621 | ||
622 | And fix up the fallout. Should be really interesting ... | |
623 | ||
a5e5cf98 DV |
624 | Level: Advanced |
625 | ||
0e70dad0 TR |
626 | Make KMS tests in i-g-t generic |
627 | ------------------------------- | |
628 | ||
629 | The i915 driver team maintains an extensive testsuite for the i915 DRM driver, | |
630 | including tons of testcases for corner-cases in the modesetting API. It would | |
631 | be awesome if those tests (at least the ones not relying on Intel-specific GEM | |
632 | features) could be made to run on any KMS driver. | |
633 | ||
634 | Basic work to run i-g-t tests on non-i915 is done, what's now missing is mass- | |
635 | converting things over. For modeset tests we also first need a bit of | |
636 | infrastructure to use dumb buffers for untiled buffers, to be able to run all | |
637 | the non-i915 specific modeset tests. | |
638 | ||
a5e5cf98 DV |
639 | Level: Advanced |
640 | ||
ad9ff96f HM |
641 | Extend virtual test driver (VKMS) |
642 | --------------------------------- | |
643 | ||
644 | See the documentation of :ref:`VKMS <vkms>` for more details. This is an ideal | |
645 | internship task, since it only requires a virtual machine and can be sized to | |
646 | fit the available time. | |
647 | ||
0e70dad0 TR |
648 | Contact: Daniel Vetter |
649 | ||
a5e5cf98 DV |
650 | Level: See details |
651 | ||
3c745e0b DV |
652 | Backlight Refactoring |
653 | --------------------- | |
654 | ||
655 | Backlight drivers have a triple enable/disable state, which is a bit overkill. | |
656 | Plan to fix this: | |
657 | ||
658 | 1. Roll out backlight_enable() and backlight_disable() helpers everywhere. This | |
659 | has started already. | |
660 | 2. In all, only look at one of the three status bits set by the above helpers. | |
661 | 3. Remove the other two status bits. | |
662 | ||
663 | Contact: Daniel Vetter | |
664 | ||
a5e5cf98 DV |
665 | Level: Intermediate |
666 | ||
0e70dad0 TR |
667 | Driver Specific |
668 | =============== | |
669 | ||
0a26a45d HW |
670 | AMD DC Display Driver |
671 | --------------------- | |
672 | ||
673 | AMD DC is the display driver for AMD devices starting with Vega. There has been | |
674 | a bunch of progress cleaning it up but there's still plenty of work to be done. | |
675 | ||
676 | See drivers/gpu/drm/amd/display/TODO for tasks. | |
677 | ||
678 | Contact: Harry Wentland, Alex Deucher | |
679 | ||
ce256008 NT |
680 | Bootsplash |
681 | ========== | |
682 | ||
683 | There is support in place now for writing internal DRM clients making it | |
684 | possible to pick up the bootsplash work that was rejected because it was written | |
685 | for fbdev. | |
686 | ||
687 | - [v6,8/8] drm/client: Hack: Add bootsplash example | |
688 | https://patchwork.freedesktop.org/patch/306579/ | |
689 | ||
690 | - [RFC PATCH v2 00/13] Kernel based bootsplash | |
691 | https://lkml.org/lkml/2017/12/13/764 | |
692 | ||
693 | Contact: Sam Ravnborg | |
694 | ||
a5e5cf98 DV |
695 | Level: Advanced |
696 | ||
0e70dad0 TR |
697 | Outside DRM |
698 | =========== | |
3c2ed9ce TZ |
699 | |
700 | Convert fbdev drivers to DRM | |
701 | ---------------------------- | |
702 | ||
703 | There are plenty of fbdev drivers for older hardware. Some hwardware has | |
704 | become obsolete, but some still provides good(-enough) framebuffers. The | |
705 | drivers that are still useful should be converted to DRM and afterwards | |
706 | removed from fbdev. | |
707 | ||
708 | Very simple fbdev drivers can best be converted by starting with a new | |
709 | DRM driver. Simple KMS helpers and SHMEM should be able to handle any | |
710 | existing hardware. The new driver's call-back functions are filled from | |
711 | existing fbdev code. | |
712 | ||
713 | More complex fbdev drivers can be refactored step-by-step into a DRM | |
714 | driver with the help of the DRM fbconv helpers. [1] These helpers provide | |
715 | the transition layer between the DRM core infrastructure and the fbdev | |
716 | driver interface. Create a new DRM driver on top of the fbconv helpers, | |
717 | copy over the fbdev driver, and hook it up to the DRM code. Examples for | |
718 | several fbdev drivers are available at [1] and a tutorial of this process | |
719 | available at [2]. The result is a primitive DRM driver that can run X11 | |
720 | and Weston. | |
721 | ||
722 | - [1] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv | |
723 | - [2] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c | |
724 | ||
725 | Contact: Thomas Zimmermann <tzimmermann@suse.de> | |
a5e5cf98 DV |
726 | |
727 | Level: Advanced |