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