]>
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`` | |
19 | and ``drm_platform.c``. The goal is to get rid of the driver's ``->load`` / | |
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 | |
65 | ||
66 | Convert early atomic drivers to async commit helpers | |
67 | ---------------------------------------------------- | |
68 | ||
69 | For the first year the atomic modeset helpers didn't support asynchronous / | |
70 | nonblocking commits, and every driver had to hand-roll them. This is fixed | |
71 | now, but there's still a pile of existing drivers that easily could be | |
72 | converted over to the new infrastructure. | |
73 | ||
74 | One issue with the helpers is that they require that drivers handle completion | |
75 | events for atomic commits correctly. But fixing these bugs is good anyway. | |
76 | ||
77 | Contact: Daniel Vetter, respective driver maintainers | |
78 | ||
79 | Fallout from atomic KMS | |
80 | ----------------------- | |
81 | ||
82 | ``drm_atomic_helper.c`` provides a batch of functions which implement legacy | |
83 | IOCTLs on top of the new atomic driver interface. Which is really nice for | |
84 | gradual conversion of drivers, but unfortunately the semantic mismatches are | |
85 | a bit too severe. So there's some follow-up work to adjust the function | |
86 | interfaces to fix these issues: | |
87 | ||
88 | * atomic needs the lock acquire context. At the moment that's passed around | |
89 | implicitly with some horrible hacks, and it's also allocate with | |
90 | ``GFP_NOFAIL`` behind the scenes. All legacy paths need to start allocating | |
91 | the acquire context explicitly on stack and then also pass it down into | |
92 | drivers explicitly so that the legacy-on-atomic functions can use them. | |
93 | ||
94 | * A bunch of the vtable hooks are now in the wrong place: DRM has a split | |
95 | between core vfunc tables (named ``drm_foo_funcs``), which are used to | |
96 | implement the userspace ABI. And then there's the optional hooks for the | |
97 | helper libraries (name ``drm_foo_helper_funcs``), which are purely for | |
98 | internal use. Some of these hooks should be move from ``_funcs`` to | |
99 | ``_helper_funcs`` since they are not part of the core ABI. There's a | |
100 | ``FIXME`` comment in the kerneldoc for each such case in ``drm_crtc.h``. | |
101 | ||
102 | * There's a new helper ``drm_atomic_helper_best_encoder()`` which could be | |
103 | used by all atomic drivers which don't select the encoder for a given | |
104 | connector at runtime. That's almost all of them, and would allow us to get | |
105 | rid of a lot of ``best_encoder`` boilerplate in drivers. | |
106 | ||
107 | Contact: Daniel Vetter | |
108 | ||
109 | Get rid of dev->struct_mutex from GEM drivers | |
110 | --------------------------------------------- | |
111 | ||
112 | ``dev->struct_mutex`` is the Big DRM Lock from legacy days and infested | |
113 | everything. Nowadays in modern drivers the only bit where it's mandatory is | |
114 | serializing GEM buffer object destruction. Which unfortunately means drivers | |
115 | have to keep track of that lock and either call ``unreference`` or | |
116 | ``unreference_locked`` depending upon context. | |
117 | ||
118 | Core GEM doesn't have a need for ``struct_mutex`` any more since kernel 4.8, | |
119 | and there's a ``gem_free_object_unlocked`` callback for any drivers which are | |
120 | entirely ``struct_mutex`` free. | |
121 | ||
122 | For drivers that need ``struct_mutex`` it should be replaced with a driver- | |
123 | private lock. The tricky part is the BO free functions, since those can't | |
124 | reliably take that lock any more. Instead state needs to be protected with | |
125 | suitable subordinate locks or some cleanup work pushed to a worker thread. For | |
126 | performance-critical drivers it might also be better to go with a more | |
127 | fine-grained per-buffer object and per-context lockings scheme. Currently the | |
128 | following drivers still use ``struct_mutex``: ``msm``, ``omapdrm`` and | |
129 | ``udl``. | |
130 | ||
131 | Contact: Daniel Vetter | |
132 | ||
133 | Core refactorings | |
134 | ================= | |
135 | ||
136 | Use new IDR deletion interface to clean up drm_gem_handle_delete() | |
137 | ------------------------------------------------------------------ | |
138 | ||
139 | See the "This is gross" comment -- apparently the IDR system now can return an | |
140 | error code instead of oopsing. | |
141 | ||
142 | Clean up the DRM header mess | |
143 | ---------------------------- | |
144 | ||
145 | Currently the DRM subsystem has only one global header, ``drmP.h``. This is | |
146 | used both for functions exported to helper libraries and drivers and functions | |
147 | only used internally in the ``drm.ko`` module. The goal would be to move all | |
148 | header declarations not needed outside of ``drm.ko`` into | |
149 | ``drivers/gpu/drm/drm_*_internal.h`` header files. ``EXPORT_SYMBOL`` also | |
150 | needs to be dropped for these functions. | |
151 | ||
152 | This would nicely tie in with the below task to create kerneldoc after the API | |
153 | is cleaned up. Or with the "hide legacy cruft better" task. | |
154 | ||
155 | Note that this is well in progress, but ``drmP.h`` is still huge. The updated | |
156 | plan is to switch to per-file driver API headers, which will also structure | |
157 | the kerneldoc better. This should also allow more fine-grained ``#include`` | |
158 | directives. | |
159 | ||
160 | Contact: Daniel Vetter | |
161 | ||
162 | Add missing kerneldoc for exported functions | |
163 | -------------------------------------------- | |
164 | ||
165 | The DRM reference documentation is still lacking kerneldoc in a few areas. The | |
166 | task would be to clean up interfaces like moving functions around between | |
167 | files to better group them and improving the interfaces like dropping return | |
168 | values for functions that never fail. Then write kerneldoc for all exported | |
169 | functions and an overview section and integrate it all into the drm DocBook. | |
170 | ||
171 | See https://dri.freedesktop.org/docs/drm/ for what's there already. | |
172 | ||
173 | Contact: Daniel Vetter | |
174 | ||
175 | Hide legacy cruft better | |
176 | ------------------------ | |
177 | ||
178 | Way back DRM supported only drivers which shadow-attached to PCI devices with | |
179 | userspace or fbdev drivers setting up outputs. Modern DRM drivers take charge | |
180 | of the entire device, you can spot them with the DRIVER_MODESET flag. | |
181 | ||
182 | Unfortunately there's still large piles of legacy code around which needs to | |
183 | be hidden so that driver writers don't accidentally end up using it. And to | |
184 | prevent security issues in those legacy IOCTLs from being exploited on modern | |
185 | drivers. This has multiple possible subtasks: | |
186 | ||
187 | * Make sure legacy IOCTLs can't be used on modern drivers. | |
188 | * Extract support code for legacy features into a ``drm-legacy.ko`` kernel | |
189 | module and compile it only when one of the legacy drivers is enabled. | |
190 | * Extract legacy functions into their own headers and remove it that from the | |
191 | monolithic ``drmP.h`` header. | |
192 | * Remove any lingering cruft from the OS abstraction layer from modern | |
193 | drivers. | |
194 | ||
195 | This is mostly done, the only thing left is to split up ``drm_irq.c`` into | |
196 | legacy cruft and the parts needed by modern KMS drivers. | |
197 | ||
198 | Contact: Daniel Vetter | |
199 | ||
200 | Make panic handling work | |
201 | ------------------------ | |
202 | ||
203 | This is a really varied tasks with lots of little bits and pieces: | |
204 | ||
205 | * The panic path can't be tested currently, leading to constant breaking. The | |
206 | main issue here is that panics can be triggered from hardirq contexts and | |
207 | hence all panic related callback can run in hardirq context. It would be | |
208 | awesome if we could test at least the fbdev helper code and driver code by | |
209 | e.g. trigger calls through drm debugfs files. hardirq context could be | |
210 | achieved by using an IPI to the local processor. | |
211 | ||
212 | * There's a massive confusion of different panic handlers. DRM fbdev emulation | |
213 | helpers have one, but on top of that the fbcon code itself also has one. We | |
214 | need to make sure that they stop fighting over each another. | |
215 | ||
216 | * ``drm_can_sleep()`` is a mess. It hides real bugs in normal operations and | |
217 | isn't a full solution for panic paths. We need to make sure that it only | |
218 | returns true if there's a panic going on for real, and fix up all the | |
219 | fallout. | |
220 | ||
221 | * The panic handler must never sleep, which also means it can't ever | |
222 | ``mutex_lock()``. Also it can't grab any other lock unconditionally, not | |
223 | even spinlocks (because NMI and hardirq can panic too). We need to either | |
224 | make sure to not call such paths, or trylock everything. Really tricky. | |
225 | ||
226 | * For the above locking troubles reasons it's pretty much impossible to | |
227 | attempt a synchronous modeset from panic handlers. The only thing we could | |
228 | try to achive is an atomic ``set_base`` of the primary plane, and hope that | |
229 | it shows up. Everything else probably needs to be delayed to some worker or | |
230 | something else which happens later on. Otherwise it just kills the box | |
231 | harder, prevent the panic from going out on e.g. netconsole. | |
232 | ||
233 | * There's also proposal for a simplied DRM console instead of the full-blown | |
234 | fbcon and DRM fbdev emulation. Any kind of panic handling tricks should | |
235 | obviously work for both console, in case we ever get kmslog merged. | |
236 | ||
237 | Contact: Daniel Vetter | |
238 | ||
239 | Better Testing | |
240 | ============== | |
241 | ||
242 | Enable trinity for DRM | |
243 | ---------------------- | |
244 | ||
245 | And fix up the fallout. Should be really interesting ... | |
246 | ||
247 | Make KMS tests in i-g-t generic | |
248 | ------------------------------- | |
249 | ||
250 | The i915 driver team maintains an extensive testsuite for the i915 DRM driver, | |
251 | including tons of testcases for corner-cases in the modesetting API. It would | |
252 | be awesome if those tests (at least the ones not relying on Intel-specific GEM | |
253 | features) could be made to run on any KMS driver. | |
254 | ||
255 | Basic work to run i-g-t tests on non-i915 is done, what's now missing is mass- | |
256 | converting things over. For modeset tests we also first need a bit of | |
257 | infrastructure to use dumb buffers for untiled buffers, to be able to run all | |
258 | the non-i915 specific modeset tests. | |
259 | ||
260 | Contact: Daniel Vetter | |
261 | ||
262 | Create a virtual KMS driver for testing (vkms) | |
263 | ---------------------------------------------- | |
264 | ||
265 | With all the latest helpers it should be fairly simple to create a virtual KMS | |
266 | driver useful for testing, or for running X or similar on headless machines | |
267 | (to be able to still use the GPU). This would be similar to vgem, but aimed at | |
268 | the modeset side. | |
269 | ||
270 | Once the basics are there there's tons of possibilities to extend it. | |
271 | ||
272 | Contact: Daniel Vetter | |
273 | ||
274 | Driver Specific | |
275 | =============== | |
276 | ||
277 | Outside DRM | |
278 | =========== | |
279 | ||
280 | Better kerneldoc | |
281 | ---------------- | |
282 | ||
283 | This is pretty much done, but there's some advanced topics: | |
284 | ||
285 | Come up with a way to hyperlink to struct members. Currently you can hyperlink | |
286 | to the struct using ``#struct_name``, but not to a member within. Would need | |
287 | buy-in from kerneldoc maintainers, and the big question is how to make it work | |
288 | without totally unsightly | |
289 | ``drm_foo_bar_really_long_structure->even_longer_memeber`` all over the text | |
290 | which breaks text flow. | |
291 | ||
292 | Figure out how to integrate the asciidoc support for ascii-diagrams. We have a | |
293 | few of those (e.g. to describe mode timings), and asciidoc supports converting | |
294 | some ascii-art dialect into pngs. Would be really pretty to make that work. | |
295 | ||
296 | Contact: Daniel Vetter, Jani Nikula | |
297 | ||
298 | Jani is working on this already, hopefully lands in 4.8. |