]>
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 | ||
10 | Subsystem-wide refactorings | |
11 | =========================== | |
12 | ||
13 | De-midlayer drivers | |
14 | ------------------- | |
15 | ||
16 | With the recent ``drm_bus`` cleanup patches for 3.17 it is no longer required | |
17 | to have a ``drm_bus`` structure set up. Drivers can directly set up the | |
18 | ``drm_device`` structure instead of relying on bus methods in ``drm_usb.c`` | |
085c6c09 | 19 | and ``drm_pci.c``. The goal is to get rid of the driver's ``->load`` / |
0e70dad0 TR |
20 | ``->unload`` callbacks and open-code the load/unload sequence properly, using |
21 | the new two-stage ``drm_device`` setup/teardown. | |
22 | ||
23 | Once all existing drivers are converted we can also remove those bus support | |
24 | files for USB and platform devices. | |
25 | ||
26 | All you need is a GPU for a non-converted driver (currently almost all of | |
27 | them, but also all the virtual ones used by KVM, so everyone qualifies). | |
28 | ||
29 | Contact: Daniel Vetter, Thierry Reding, respective driver maintainers | |
30 | ||
31 | Switch from reference/unreference to get/put | |
32 | -------------------------------------------- | |
33 | ||
34 | For some reason DRM core uses ``reference``/``unreference`` suffixes for | |
35 | refcounting functions, but kernel uses ``get``/``put`` (e.g. | |
36 | ``kref_get``/``put()``). It would be good to switch over for consistency, and | |
37 | it's shorter. Needs to be done in 3 steps for each pair of functions: | |
38 | ||
39 | * Create new ``get``/``put`` functions, define the old names as compatibility | |
40 | wrappers | |
41 | * Switch over each file/driver using a cocci-generated spatch. | |
42 | * Once all users of the old names are gone, remove them. | |
43 | ||
44 | This way drivers/patches in the progress of getting merged won't break. | |
45 | ||
46 | Contact: Daniel Vetter | |
47 | ||
48 | Convert existing KMS drivers to atomic modesetting | |
49 | -------------------------------------------------- | |
50 | ||
51 | 3.19 has the atomic modeset interfaces and helpers, so drivers can now be | |
52 | converted over. Modern compositors like Wayland or Surfaceflinger on Android | |
53 | really want an atomic modeset interface, so this is all about the bright | |
54 | future. | |
55 | ||
56 | There is a conversion guide for atomic and all you need is a GPU for a | |
57 | non-converted driver (again virtual HW drivers for KVM are still all | |
58 | suitable). | |
59 | ||
60 | As part of this drivers also need to convert to universal plane (which means | |
61 | exposing primary & cursor as proper plane objects). But that's much easier to | |
62 | do by directly using the new atomic helper driver callbacks. | |
63 | ||
64 | Contact: Daniel Vetter, respective driver maintainers | |
1a80cc1c DV |
65 | |
66 | Clean up the clipped coordination confusion around planes | |
67 | --------------------------------------------------------- | |
68 | ||
69 | We have a helper to get this right with drm_plane_helper_check_update(), but | |
70 | it's not consistently used. This should be fixed, preferrably in the atomic | |
71 | helpers (and drivers then moved over to clipped coordinates). Probably the | |
72 | helper should also be moved from drm_plane_helper.c to the atomic helpers, to | |
73 | avoid confusion - the other helpers in that file are all deprecated legacy | |
74 | helpers. | |
75 | ||
76 | Contact: Ville Syrjälä, Daniel Vetter, driver maintainers | |
4e8be453 | 77 | |
0e70dad0 TR |
78 | Convert early atomic drivers to async commit helpers |
79 | ---------------------------------------------------- | |
80 | ||
81 | For the first year the atomic modeset helpers didn't support asynchronous / | |
82 | nonblocking commits, and every driver had to hand-roll them. This is fixed | |
83 | now, but there's still a pile of existing drivers that easily could be | |
84 | converted over to the new infrastructure. | |
85 | ||
86 | One issue with the helpers is that they require that drivers handle completion | |
87 | events for atomic commits correctly. But fixing these bugs is good anyway. | |
88 | ||
89 | Contact: Daniel Vetter, respective driver maintainers | |
90 | ||
f217f554 DV |
91 | Better manual-upload support for atomic |
92 | --------------------------------------- | |
93 | ||
94 | This would be especially useful for tinydrm: | |
95 | ||
96 | - Add a struct drm_rect dirty_clip to drm_crtc_state. When duplicating the | |
97 | crtc state, clear that to the max values, x/y = 0 and w/h = MAX_INT, in | |
98 | __drm_atomic_helper_crtc_duplicate_state(). | |
99 | ||
0cac6ac1 TR |
100 | - Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm\_ |
101 | prefix ofc and using drm_fb\_. drm_framebuffer.c makes sense since this | |
f217f554 DV |
102 | is a function useful to implement the fb->dirty function. |
103 | ||
104 | - Create a new drm_fb_dirty function which does essentially what e.g. | |
105 | mipi_dbi_fb_dirty does. You can use e.g. drm_atomic_helper_update_plane as the | |
106 | template. But instead of doing a simple full-screen plane update, this new | |
107 | helper also sets crtc_state->dirty_clip to the right coordinates. And of | |
108 | course it needs to check whether the fb is actually active (and maybe where), | |
109 | so there's some book-keeping involved. There's also some good fun involved in | |
110 | scaling things appropriately. For that case we might simply give up and | |
111 | declare the entire area covered by the plane as dirty. | |
112 | ||
113 | Contact: Noralf Trønnes, Daniel Vetter | |
114 | ||
0e70dad0 TR |
115 | Fallout from atomic KMS |
116 | ----------------------- | |
117 | ||
118 | ``drm_atomic_helper.c`` provides a batch of functions which implement legacy | |
119 | IOCTLs on top of the new atomic driver interface. Which is really nice for | |
120 | gradual conversion of drivers, but unfortunately the semantic mismatches are | |
121 | a bit too severe. So there's some follow-up work to adjust the function | |
122 | interfaces to fix these issues: | |
123 | ||
124 | * atomic needs the lock acquire context. At the moment that's passed around | |
125 | implicitly with some horrible hacks, and it's also allocate with | |
126 | ``GFP_NOFAIL`` behind the scenes. All legacy paths need to start allocating | |
127 | the acquire context explicitly on stack and then also pass it down into | |
128 | drivers explicitly so that the legacy-on-atomic functions can use them. | |
129 | ||
be05fe13 DV |
130 | Except for some driver code this is done. |
131 | ||
0e70dad0 TR |
132 | * A bunch of the vtable hooks are now in the wrong place: DRM has a split |
133 | between core vfunc tables (named ``drm_foo_funcs``), which are used to | |
134 | implement the userspace ABI. And then there's the optional hooks for the | |
135 | helper libraries (name ``drm_foo_helper_funcs``), which are purely for | |
136 | internal use. Some of these hooks should be move from ``_funcs`` to | |
137 | ``_helper_funcs`` since they are not part of the core ABI. There's a | |
138 | ``FIXME`` comment in the kerneldoc for each such case in ``drm_crtc.h``. | |
139 | ||
140 | * There's a new helper ``drm_atomic_helper_best_encoder()`` which could be | |
141 | used by all atomic drivers which don't select the encoder for a given | |
142 | connector at runtime. That's almost all of them, and would allow us to get | |
143 | rid of a lot of ``best_encoder`` boilerplate in drivers. | |
144 | ||
be05fe13 DV |
145 | This was almost done, but new drivers added a few more cases again. |
146 | ||
0e70dad0 TR |
147 | Contact: Daniel Vetter |
148 | ||
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, | |
159 | and there's a ``gem_free_object_unlocked`` callback for any drivers which are | |
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 | |
167 | fine-grained per-buffer object and per-context lockings scheme. Currently the | |
168 | following drivers still use ``struct_mutex``: ``msm``, ``omapdrm`` and | |
169 | ``udl``. | |
170 | ||
085c6c09 | 171 | Contact: Daniel Vetter, respective driver maintainers |
0e70dad0 | 172 | |
45ae2787 SP |
173 | Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent |
174 | ---------------------------------------------------------------------------- | |
175 | ||
176 | For drivers which could have multiple instances, it is necessary to | |
177 | differentiate between which is which in the logs. Since DRM_INFO/WARN/ERROR | |
178 | don't do this, drivers used dev_info/warn/err to make this differentiation. We | |
179 | now have DRM_DEV_* variants of the drm print macros, so we can start to convert | |
180 | those drivers back to using drm-formwatted specific log messages. | |
181 | ||
9f446781 DV |
182 | Before you start this conversion please contact the relevant maintainers to make |
183 | sure your work will be merged - not everyone agrees that the DRM dmesg macros | |
184 | are better. | |
185 | ||
45ae2787 SP |
186 | Contact: Sean Paul, Maintainer of the driver you plan to convert |
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 | |
193 | drm_mode_config_helper_suspend/resume(). | |
194 | ||
195 | Contact: Maintainer of the driver you plan to convert | |
196 | ||
ee05baa0 NT |
197 | Convert drivers to use drm_fb_helper_fbdev_setup/teardown() |
198 | ----------------------------------------------------------- | |
199 | ||
200 | Most drivers can use drm_fb_helper_fbdev_setup() except maybe: | |
201 | ||
202 | - amdgpu which has special logic to decide whether to call | |
203 | drm_helper_disable_unused_functions() | |
204 | ||
205 | - armada which isn't atomic and doesn't call | |
206 | drm_helper_disable_unused_functions() | |
207 | ||
208 | - i915 which calls drm_fb_helper_initial_config() in a worker | |
209 | ||
210 | Drivers that use drm_framebuffer_remove() to clean up the fbdev framebuffer can | |
211 | probably use drm_fb_helper_fbdev_teardown(). | |
212 | ||
213 | Contact: Maintainer of the driver you plan to convert | |
214 | ||
1aecabb5 DV |
215 | idr_init_base() |
216 | --------------- | |
217 | ||
218 | DRM core&drivers uses a lot of idr (integer lookup directories) for mapping | |
219 | userspace IDs to internal objects, and in most places ID=0 means NULL and hence | |
220 | is never used. Switching to idr_init_base() for these would make the idr more | |
221 | efficient. | |
222 | ||
223 | Contact: Daniel Vetter | |
224 | ||
0e70dad0 TR |
225 | Core refactorings |
226 | ================= | |
227 | ||
0e70dad0 TR |
228 | Clean up the DRM header mess |
229 | ---------------------------- | |
230 | ||
231 | Currently the DRM subsystem has only one global header, ``drmP.h``. This is | |
232 | used both for functions exported to helper libraries and drivers and functions | |
233 | only used internally in the ``drm.ko`` module. The goal would be to move all | |
234 | header declarations not needed outside of ``drm.ko`` into | |
235 | ``drivers/gpu/drm/drm_*_internal.h`` header files. ``EXPORT_SYMBOL`` also | |
236 | needs to be dropped for these functions. | |
237 | ||
238 | This would nicely tie in with the below task to create kerneldoc after the API | |
239 | is cleaned up. Or with the "hide legacy cruft better" task. | |
240 | ||
241 | Note that this is well in progress, but ``drmP.h`` is still huge. The updated | |
242 | plan is to switch to per-file driver API headers, which will also structure | |
243 | the kerneldoc better. This should also allow more fine-grained ``#include`` | |
244 | directives. | |
245 | ||
085c6c09 DV |
246 | In the end no .c file should need to include ``drmP.h`` anymore. |
247 | ||
0e70dad0 TR |
248 | Contact: Daniel Vetter |
249 | ||
250 | Add missing kerneldoc for exported functions | |
251 | -------------------------------------------- | |
252 | ||
253 | The DRM reference documentation is still lacking kerneldoc in a few areas. The | |
254 | task would be to clean up interfaces like moving functions around between | |
255 | files to better group them and improving the interfaces like dropping return | |
256 | values for functions that never fail. Then write kerneldoc for all exported | |
ff41c419 | 257 | functions and an overview section and integrate it all into the drm book. |
0e70dad0 TR |
258 | |
259 | See https://dri.freedesktop.org/docs/drm/ for what's there already. | |
260 | ||
261 | Contact: Daniel Vetter | |
262 | ||
263 | Hide legacy cruft better | |
264 | ------------------------ | |
265 | ||
266 | Way back DRM supported only drivers which shadow-attached to PCI devices with | |
267 | userspace or fbdev drivers setting up outputs. Modern DRM drivers take charge | |
268 | of the entire device, you can spot them with the DRIVER_MODESET flag. | |
269 | ||
270 | Unfortunately there's still large piles of legacy code around which needs to | |
271 | be hidden so that driver writers don't accidentally end up using it. And to | |
272 | prevent security issues in those legacy IOCTLs from being exploited on modern | |
273 | drivers. This has multiple possible subtasks: | |
274 | ||
0e70dad0 TR |
275 | * Extract support code for legacy features into a ``drm-legacy.ko`` kernel |
276 | module and compile it only when one of the legacy drivers is enabled. | |
0e70dad0 TR |
277 | |
278 | This is mostly done, the only thing left is to split up ``drm_irq.c`` into | |
279 | legacy cruft and the parts needed by modern KMS drivers. | |
280 | ||
281 | Contact: Daniel Vetter | |
282 | ||
283 | Make panic handling work | |
284 | ------------------------ | |
285 | ||
286 | This is a really varied tasks with lots of little bits and pieces: | |
287 | ||
288 | * The panic path can't be tested currently, leading to constant breaking. The | |
289 | main issue here is that panics can be triggered from hardirq contexts and | |
290 | hence all panic related callback can run in hardirq context. It would be | |
291 | awesome if we could test at least the fbdev helper code and driver code by | |
292 | e.g. trigger calls through drm debugfs files. hardirq context could be | |
293 | achieved by using an IPI to the local processor. | |
294 | ||
295 | * There's a massive confusion of different panic handlers. DRM fbdev emulation | |
296 | helpers have one, but on top of that the fbcon code itself also has one. We | |
297 | need to make sure that they stop fighting over each another. | |
298 | ||
299 | * ``drm_can_sleep()`` is a mess. It hides real bugs in normal operations and | |
300 | isn't a full solution for panic paths. We need to make sure that it only | |
301 | returns true if there's a panic going on for real, and fix up all the | |
302 | fallout. | |
303 | ||
304 | * The panic handler must never sleep, which also means it can't ever | |
305 | ``mutex_lock()``. Also it can't grab any other lock unconditionally, not | |
306 | even spinlocks (because NMI and hardirq can panic too). We need to either | |
307 | make sure to not call such paths, or trylock everything. Really tricky. | |
308 | ||
309 | * For the above locking troubles reasons it's pretty much impossible to | |
310 | attempt a synchronous modeset from panic handlers. The only thing we could | |
311 | try to achive is an atomic ``set_base`` of the primary plane, and hope that | |
312 | it shows up. Everything else probably needs to be delayed to some worker or | |
313 | something else which happens later on. Otherwise it just kills the box | |
314 | harder, prevent the panic from going out on e.g. netconsole. | |
315 | ||
316 | * There's also proposal for a simplied DRM console instead of the full-blown | |
317 | fbcon and DRM fbdev emulation. Any kind of panic handling tricks should | |
318 | obviously work for both console, in case we ever get kmslog merged. | |
319 | ||
320 | Contact: Daniel Vetter | |
321 | ||
0cad7f71 DV |
322 | Clean up the debugfs support |
323 | ---------------------------- | |
324 | ||
325 | There's a bunch of issues with it: | |
326 | ||
327 | - The drm_info_list ->show() function doesn't even bother to cast to the drm | |
328 | structure for you. This is lazy. | |
329 | ||
330 | - We probably want to have some support for debugfs files on crtc/connectors and | |
331 | maybe other kms objects directly in core. There's even drm_print support in | |
332 | the funcs for these objects to dump kms state, so it's all there. And then the | |
333 | ->show() functions should obviously give you a pointer to the right object. | |
334 | ||
335 | - The drm_info_list stuff is centered on drm_minor instead of drm_device. For | |
336 | anything we want to print drm_device (or maybe drm_file) is the right thing. | |
337 | ||
338 | - The drm_driver->debugfs_init hooks we have is just an artifact of the old | |
339 | midlayered load sequence. DRM debugfs should work more like sysfs, where you | |
340 | can create properties/files for an object anytime you want, and the core | |
341 | takes care of publishing/unpuplishing all the files at register/unregister | |
342 | time. Drivers shouldn't need to worry about these technicalities, and fixing | |
343 | this (together with the drm_minor->drm_device move) would allow us to remove | |
344 | debugfs_init. | |
345 | ||
346 | Contact: Daniel Vetter | |
347 | ||
81a7bd4a DV |
348 | KMS cleanups |
349 | ------------ | |
350 | ||
351 | Some of these date from the very introduction of KMS in 2008 ... | |
352 | ||
353 | - drm_mode_config.crtc_idr is misnamed, since it contains all KMS object. Should | |
354 | be renamed to drm_mode_config.object_idr. | |
355 | ||
356 | - drm_display_mode doesn't need to be derived from drm_mode_object. That's | |
357 | leftovers from older (never merged into upstream) KMS designs where modes | |
358 | where set using their ID, including support to add/remove modes. | |
359 | ||
0e70dad0 TR |
360 | Better Testing |
361 | ============== | |
362 | ||
363 | Enable trinity for DRM | |
364 | ---------------------- | |
365 | ||
366 | And fix up the fallout. Should be really interesting ... | |
367 | ||
368 | Make KMS tests in i-g-t generic | |
369 | ------------------------------- | |
370 | ||
371 | The i915 driver team maintains an extensive testsuite for the i915 DRM driver, | |
372 | including tons of testcases for corner-cases in the modesetting API. It would | |
373 | be awesome if those tests (at least the ones not relying on Intel-specific GEM | |
374 | features) could be made to run on any KMS driver. | |
375 | ||
376 | Basic work to run i-g-t tests on non-i915 is done, what's now missing is mass- | |
377 | converting things over. For modeset tests we also first need a bit of | |
378 | infrastructure to use dumb buffers for untiled buffers, to be able to run all | |
379 | the non-i915 specific modeset tests. | |
380 | ||
381 | Contact: Daniel Vetter | |
382 | ||
383 | Create a virtual KMS driver for testing (vkms) | |
384 | ---------------------------------------------- | |
385 | ||
386 | With all the latest helpers it should be fairly simple to create a virtual KMS | |
387 | driver useful for testing, or for running X or similar on headless machines | |
388 | (to be able to still use the GPU). This would be similar to vgem, but aimed at | |
389 | the modeset side. | |
390 | ||
391 | Once the basics are there there's tons of possibilities to extend it. | |
392 | ||
393 | Contact: Daniel Vetter | |
394 | ||
395 | Driver Specific | |
396 | =============== | |
397 | ||
f217f554 DV |
398 | tinydrm |
399 | ------- | |
400 | ||
401 | Tinydrm is the helper driver for really simple fb drivers. The goal is to make | |
402 | those drivers as simple as possible, so lots of room for refactoring: | |
403 | ||
404 | - backlight helpers, probably best to put them into a new drm_backlight.c. | |
405 | This is because drivers/video is de-facto unmaintained. We could also | |
406 | move drivers/video/backlight to drivers/gpu/backlight and take it all | |
9949b355 MM |
407 | over within drm-misc, but that's more work. Backlight helpers require a fair |
408 | bit of reworking and refactoring. A simple example is the enabling of a backlight. | |
409 | Tinydrm has helpers for this. It would be good if other drivers can also use the | |
410 | helper. However, there are various cases we need to consider i.e different | |
411 | drivers seem to have different ways of enabling/disabling a backlight. | |
412 | We also need to consider the backlight drivers (like gpio_backlight). The situation | |
413 | is further complicated by the fact that the backlight is tied to fbdev | |
414 | via fb_notifier_callback() which has complicated logic. For further details, refer | |
415 | to the following discussion thread: | |
416 | https://groups.google.com/forum/#!topic/outreachy-kernel/8rBe30lwtdA | |
f217f554 DV |
417 | |
418 | - spi helpers, probably best put into spi core/helper code. Thierry said | |
419 | the spi maintainer is fast&reactive, so shouldn't be a big issue. | |
420 | ||
421 | - extract the mipi-dbi helper (well, the non-tinydrm specific parts at | |
422 | least) into a separate helper, like we have for mipi-dsi already. Or follow | |
423 | one of the ideas for having a shared dsi/dbi helper, abstracting away the | |
424 | transport details more. | |
425 | ||
f217f554 DV |
426 | - tinydrm_gem_cma_prime_import_sg_table should probably go into the cma |
427 | helpers, as a _vmapped variant (since not every driver needs the vmap). | |
428 | And tinydrm_gem_cma_free_object could the be merged into | |
429 | drm_gem_cma_free_object(). | |
430 | ||
431 | - tinydrm_fb_create we could move into drm_simple_pipe, only need to add | |
432 | the fb_create hook to drm_simple_pipe_funcs, which would again simplify a | |
433 | bunch of things (since it gives you a one-stop vfunc for simple drivers). | |
434 | ||
435 | - Quick aside: The unregister devm stuff is kinda getting the lifetimes of | |
436 | a drm_device wrong. Doesn't matter, since everyone else gets it wrong | |
437 | too :-) | |
438 | ||
f217f554 DV |
439 | - also rework the drm_framebuffer_funcs->dirty hook wire-up, see above. |
440 | ||
441 | Contact: Noralf Trønnes, Daniel Vetter | |
442 | ||
0a26a45d HW |
443 | AMD DC Display Driver |
444 | --------------------- | |
445 | ||
446 | AMD DC is the display driver for AMD devices starting with Vega. There has been | |
447 | a bunch of progress cleaning it up but there's still plenty of work to be done. | |
448 | ||
449 | See drivers/gpu/drm/amd/display/TODO for tasks. | |
450 | ||
451 | Contact: Harry Wentland, Alex Deucher | |
452 | ||
7b3b61b6 DV |
453 | i915 |
454 | ---- | |
455 | ||
456 | - Our early/late pm callbacks could be removed in favour of using | |
457 | device_link_add to model the dependency between i915 and snd_had. See | |
458 | https://dri.freedesktop.org/docs/drm/driver-api/device_link.html | |
459 | ||
0e70dad0 TR |
460 | Outside DRM |
461 | =========== |