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 | ||
39dea70d DV |
13 | Remove custom dumb_map_offset implementations |
14 | --------------------------------------------- | |
15 | ||
16 | All GEM based drivers should be using drm_gem_create_mmap_offset() instead. | |
17 | Audit each individual driver, make sure it'll work with the generic | |
18 | implementation (there's lots of outdated locking leftovers in various | |
19 | implementations), and then remove it. | |
20 | ||
21 | Contact: Daniel Vetter, respective driver maintainers | |
22 | ||
0e70dad0 TR |
23 | Convert existing KMS drivers to atomic modesetting |
24 | -------------------------------------------------- | |
25 | ||
26 | 3.19 has the atomic modeset interfaces and helpers, so drivers can now be | |
27 | converted over. Modern compositors like Wayland or Surfaceflinger on Android | |
28 | really want an atomic modeset interface, so this is all about the bright | |
29 | future. | |
30 | ||
31 | There is a conversion guide for atomic and all you need is a GPU for a | |
32 | non-converted driver (again virtual HW drivers for KVM are still all | |
33 | suitable). | |
34 | ||
35 | As part of this drivers also need to convert to universal plane (which means | |
36 | exposing primary & cursor as proper plane objects). But that's much easier to | |
37 | do by directly using the new atomic helper driver callbacks. | |
38 | ||
39 | Contact: Daniel Vetter, respective driver maintainers | |
1a80cc1c DV |
40 | |
41 | Clean up the clipped coordination confusion around planes | |
42 | --------------------------------------------------------- | |
43 | ||
44 | We have a helper to get this right with drm_plane_helper_check_update(), but | |
45 | it's not consistently used. This should be fixed, preferrably in the atomic | |
46 | helpers (and drivers then moved over to clipped coordinates). Probably the | |
47 | helper should also be moved from drm_plane_helper.c to the atomic helpers, to | |
48 | avoid confusion - the other helpers in that file are all deprecated legacy | |
49 | helpers. | |
50 | ||
51 | Contact: Ville Syrjälä, Daniel Vetter, driver maintainers | |
4e8be453 | 52 | |
0e70dad0 TR |
53 | Convert early atomic drivers to async commit helpers |
54 | ---------------------------------------------------- | |
55 | ||
56 | For the first year the atomic modeset helpers didn't support asynchronous / | |
57 | nonblocking commits, and every driver had to hand-roll them. This is fixed | |
58 | now, but there's still a pile of existing drivers that easily could be | |
59 | converted over to the new infrastructure. | |
60 | ||
61 | One issue with the helpers is that they require that drivers handle completion | |
62 | events for atomic commits correctly. But fixing these bugs is good anyway. | |
63 | ||
64 | Contact: Daniel Vetter, respective driver maintainers | |
65 | ||
66 | Fallout from atomic KMS | |
67 | ----------------------- | |
68 | ||
69 | ``drm_atomic_helper.c`` provides a batch of functions which implement legacy | |
70 | IOCTLs on top of the new atomic driver interface. Which is really nice for | |
71 | gradual conversion of drivers, but unfortunately the semantic mismatches are | |
72 | a bit too severe. So there's some follow-up work to adjust the function | |
73 | interfaces to fix these issues: | |
74 | ||
75 | * atomic needs the lock acquire context. At the moment that's passed around | |
76 | implicitly with some horrible hacks, and it's also allocate with | |
77 | ``GFP_NOFAIL`` behind the scenes. All legacy paths need to start allocating | |
78 | the acquire context explicitly on stack and then also pass it down into | |
79 | drivers explicitly so that the legacy-on-atomic functions can use them. | |
80 | ||
2ec04b33 DV |
81 | Except for some driver code this is done. This task should be finished by |
82 | adding WARN_ON(!drm_drv_uses_atomic_modeset) in drm_modeset_lock_all(). | |
be05fe13 | 83 | |
0e70dad0 TR |
84 | * A bunch of the vtable hooks are now in the wrong place: DRM has a split |
85 | between core vfunc tables (named ``drm_foo_funcs``), which are used to | |
86 | implement the userspace ABI. And then there's the optional hooks for the | |
87 | helper libraries (name ``drm_foo_helper_funcs``), which are purely for | |
88 | internal use. Some of these hooks should be move from ``_funcs`` to | |
89 | ``_helper_funcs`` since they are not part of the core ABI. There's a | |
90 | ``FIXME`` comment in the kerneldoc for each such case in ``drm_crtc.h``. | |
91 | ||
0e70dad0 TR |
92 | Contact: Daniel Vetter |
93 | ||
94 | Get rid of dev->struct_mutex from GEM drivers | |
95 | --------------------------------------------- | |
96 | ||
97 | ``dev->struct_mutex`` is the Big DRM Lock from legacy days and infested | |
98 | everything. Nowadays in modern drivers the only bit where it's mandatory is | |
99 | serializing GEM buffer object destruction. Which unfortunately means drivers | |
100 | have to keep track of that lock and either call ``unreference`` or | |
101 | ``unreference_locked`` depending upon context. | |
102 | ||
103 | Core GEM doesn't have a need for ``struct_mutex`` any more since kernel 4.8, | |
104 | and there's a ``gem_free_object_unlocked`` callback for any drivers which are | |
105 | entirely ``struct_mutex`` free. | |
106 | ||
107 | For drivers that need ``struct_mutex`` it should be replaced with a driver- | |
108 | private lock. The tricky part is the BO free functions, since those can't | |
109 | reliably take that lock any more. Instead state needs to be protected with | |
110 | suitable subordinate locks or some cleanup work pushed to a worker thread. For | |
111 | performance-critical drivers it might also be better to go with a more | |
2ec04b33 DV |
112 | fine-grained per-buffer object and per-context lockings scheme. Currently only the |
113 | ``msm`` driver still use ``struct_mutex``. | |
0e70dad0 | 114 | |
085c6c09 | 115 | Contact: Daniel Vetter, respective driver maintainers |
0e70dad0 | 116 | |
45ae2787 SP |
117 | Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent |
118 | ---------------------------------------------------------------------------- | |
119 | ||
120 | For drivers which could have multiple instances, it is necessary to | |
121 | differentiate between which is which in the logs. Since DRM_INFO/WARN/ERROR | |
122 | don't do this, drivers used dev_info/warn/err to make this differentiation. We | |
123 | now have DRM_DEV_* variants of the drm print macros, so we can start to convert | |
124 | those drivers back to using drm-formwatted specific log messages. | |
125 | ||
9f446781 DV |
126 | Before you start this conversion please contact the relevant maintainers to make |
127 | sure your work will be merged - not everyone agrees that the DRM dmesg macros | |
128 | are better. | |
129 | ||
45ae2787 SP |
130 | Contact: Sean Paul, Maintainer of the driver you plan to convert |
131 | ||
3233fc0a NT |
132 | Convert drivers to use simple modeset suspend/resume |
133 | ---------------------------------------------------- | |
134 | ||
135 | Most drivers (except i915 and nouveau) that use | |
136 | drm_atomic_helper_suspend/resume() can probably be converted to use | |
2ec04b33 DV |
137 | drm_mode_config_helper_suspend/resume(). Also there's still open-coded version |
138 | of the atomic suspend/resume code in older atomic modeset drivers. | |
3233fc0a NT |
139 | |
140 | Contact: Maintainer of the driver you plan to convert | |
141 | ||
ee05baa0 NT |
142 | Convert drivers to use drm_fb_helper_fbdev_setup/teardown() |
143 | ----------------------------------------------------------- | |
144 | ||
145 | Most drivers can use drm_fb_helper_fbdev_setup() except maybe: | |
146 | ||
147 | - amdgpu which has special logic to decide whether to call | |
148 | drm_helper_disable_unused_functions() | |
149 | ||
150 | - armada which isn't atomic and doesn't call | |
151 | drm_helper_disable_unused_functions() | |
152 | ||
153 | - i915 which calls drm_fb_helper_initial_config() in a worker | |
154 | ||
155 | Drivers that use drm_framebuffer_remove() to clean up the fbdev framebuffer can | |
156 | probably use drm_fb_helper_fbdev_teardown(). | |
157 | ||
158 | Contact: Maintainer of the driver you plan to convert | |
159 | ||
66499101 DV |
160 | Clean up mmap forwarding |
161 | ------------------------ | |
162 | ||
163 | A lot of drivers forward gem mmap calls to dma-buf mmap for imported buffers. | |
164 | And also a lot of them forward dma-buf mmap to the gem mmap implementations. | |
165 | Would be great to refactor this all into a set of small common helpers. | |
166 | ||
167 | Contact: Daniel Vetter | |
168 | ||
be5cadc7 DV |
169 | Generic fbdev defio support |
170 | --------------------------- | |
171 | ||
172 | The defio support code in the fbdev core has some very specific requirements, | |
173 | which means drivers need to have a special framebuffer for fbdev. Which prevents | |
174 | us from using the generic fbdev emulation code everywhere. The main issue is | |
175 | that it uses some fields in struct page itself, which breaks shmem gem objects | |
176 | (and other things). | |
177 | ||
178 | Possible solution would be to write our own defio mmap code in the drm fbdev | |
179 | emulation. It would need to fully wrap the existing mmap ops, forwarding | |
180 | everything after it has done the write-protect/mkwrite trickery: | |
181 | ||
182 | - In the drm_fbdev_fb_mmap helper, if we need defio, change the | |
183 | default page prots to write-protected with something like this:: | |
184 | ||
185 | vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot); | |
186 | ||
187 | - Set the mkwrite and fsync callbacks with similar implementions to the core | |
188 | fbdev defio stuff. These should all work on plain ptes, they don't actually | |
189 | require a struct page. uff. These should all work on plain ptes, they don't | |
190 | actually require a struct page. | |
191 | ||
192 | - Track the dirty pages in a separate structure (bitfield with one bit per page | |
193 | should work) to avoid clobbering struct page. | |
194 | ||
195 | Might be good to also have some igt testcases for this. | |
196 | ||
197 | Contact: Daniel Vetter, Noralf Tronnes | |
198 | ||
1ba62714 | 199 | Remove the ->gem_prime_res_obj callback |
66499101 DV |
200 | -------------------------------------------- |
201 | ||
1ba62714 RH |
202 | The ->gem_prime_res_obj callback can be removed from drivers by using the |
203 | reservation_object in the drm_gem_object. It may also be possible to use the | |
204 | generic drm_gem_reservation_object_wait helper for waiting for a bo. | |
66499101 DV |
205 | |
206 | Contact: Daniel Vetter | |
207 | ||
1aecabb5 DV |
208 | idr_init_base() |
209 | --------------- | |
210 | ||
211 | DRM core&drivers uses a lot of idr (integer lookup directories) for mapping | |
212 | userspace IDs to internal objects, and in most places ID=0 means NULL and hence | |
213 | is never used. Switching to idr_init_base() for these would make the idr more | |
214 | efficient. | |
215 | ||
216 | Contact: Daniel Vetter | |
217 | ||
f0014881 NT |
218 | Defaults for .gem_prime_import and export |
219 | ----------------------------------------- | |
220 | ||
221 | Most drivers don't need to set drm_driver->gem_prime_import and | |
222 | ->gem_prime_export now that drm_gem_prime_import() and drm_gem_prime_export() | |
223 | are the default. | |
224 | ||
b39b5394 NT |
225 | struct drm_gem_object_funcs |
226 | --------------------------- | |
227 | ||
228 | GEM objects can now have a function table instead of having the callbacks on the | |
229 | DRM driver struct. This is now the preferred way and drivers can be moved over. | |
230 | ||
836334fd DV |
231 | DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS already support this, but |
232 | DRM_GEM_VRAM_DRIVER_PRIME does not yet and needs to be aligned with the previous | |
233 | two. We also need a 2nd version of the CMA define that doesn't require the | |
234 | vmapping to be present (different hook for prime importing). Plus this needs to | |
235 | be rolled out to all drivers using their own implementations, too. | |
8db420ac | 236 | |
22be8740 SP |
237 | Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate |
238 | --------------------------------------------------------- | |
239 | ||
240 | For cases where drivers are attempting to grab the modeset locks with a local | |
241 | acquire context. Replace the boilerplate code surrounding | |
242 | drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN() and | |
243 | DRM_MODESET_LOCK_ALL_END() instead. | |
244 | ||
245 | This should also be done for all places where drm_modest_lock_all() is still | |
246 | used. | |
247 | ||
248 | As a reference, take a look at the conversions already completed in drm core. | |
249 | ||
250 | Contact: Sean Paul, respective driver maintainers | |
251 | ||
e57924d4 DV |
252 | Rename CMA helpers to DMA helpers |
253 | --------------------------------- | |
254 | ||
255 | CMA (standing for contiguous memory allocator) is really a bit an accident of | |
256 | what these were used for first, a much better name would be DMA helpers. In the | |
257 | text these should even be called coherent DMA memory helpers (so maybe CDM, but | |
258 | no one knows what that means) since underneath they just use dma_alloc_coherent. | |
259 | ||
260 | Contact: Laurent Pinchart, Daniel Vetter | |
261 | ||
d60ea31a SP |
262 | Convert direct mode.vrefresh accesses to use drm_mode_vrefresh() |
263 | ---------------------------------------------------------------- | |
264 | ||
265 | drm_display_mode.vrefresh isn't guaranteed to be populated. As such, using it | |
266 | is risky and has been known to cause div-by-zero bugs. Fortunately, drm core | |
267 | has helper which will use mode.vrefresh if it's !0 and will calculate it from | |
268 | the timings when it's 0. | |
269 | ||
270 | Use simple search/replace, or (more fun) cocci to replace instances of direct | |
271 | vrefresh access with a call to the helper. Check out | |
272 | https://lists.freedesktop.org/archives/dri-devel/2019-January/205186.html for | |
273 | inspiration. | |
274 | ||
275 | Once all instances of vrefresh have been converted, remove vrefresh from | |
276 | drm_display_mode to avoid future use. | |
277 | ||
278 | Contact: Sean Paul | |
279 | ||
280 | Remove drm_display_mode.hsync | |
281 | ----------------------------- | |
282 | ||
283 | We have drm_mode_hsync() to calculate this from hsync_start/end, since drivers | |
284 | shouldn't/don't use this, remove this member to avoid any temptations to use it | |
285 | in the future. If there is any debug code using drm_display_mode.hsync, convert | |
286 | it to use drm_mode_hsync() instead. | |
287 | ||
288 | Contact: Sean Paul | |
289 | ||
03a9606e NT |
290 | drm_fb_helper tasks |
291 | ------------------- | |
292 | ||
293 | - drm_fb_helper_restore_fbdev_mode_unlocked() should call restore_fbdev_mode() | |
294 | not the _force variant so it can bail out if there is a master. But first | |
295 | these igt tests need to be fixed: kms_fbcon_fbt@psr and | |
296 | kms_fbcon_fbt@psr-suspend. | |
297 | ||
d81294af NT |
298 | - The max connector argument for drm_fb_helper_init() and |
299 | drm_fb_helper_fbdev_setup() isn't used anymore and can be removed. | |
300 | ||
e5852bee NT |
301 | - The helper doesn't keep an array of connectors anymore so these can be |
302 | removed: drm_fb_helper_single_add_all_connectors(), | |
303 | drm_fb_helper_add_one_connector() and drm_fb_helper_remove_one_connector(). | |
304 | ||
0e70dad0 TR |
305 | Core refactorings |
306 | ================= | |
307 | ||
0e70dad0 TR |
308 | Clean up the DRM header mess |
309 | ---------------------------- | |
310 | ||
2ec04b33 DV |
311 | The DRM subsystem originally had only one huge global header, ``drmP.h``. This |
312 | is now split up, but many source files still include it. The remaining part of | |
313 | the cleanup work here is to replace any ``#include <drm/drmP.h>`` by only the | |
314 | headers needed (and fixing up any missing pre-declarations in the headers). | |
0e70dad0 | 315 | |
085c6c09 DV |
316 | In the end no .c file should need to include ``drmP.h`` anymore. |
317 | ||
0e70dad0 TR |
318 | Contact: Daniel Vetter |
319 | ||
320 | Add missing kerneldoc for exported functions | |
321 | -------------------------------------------- | |
322 | ||
323 | The DRM reference documentation is still lacking kerneldoc in a few areas. The | |
324 | task would be to clean up interfaces like moving functions around between | |
325 | files to better group them and improving the interfaces like dropping return | |
326 | values for functions that never fail. Then write kerneldoc for all exported | |
ff41c419 | 327 | functions and an overview section and integrate it all into the drm book. |
0e70dad0 TR |
328 | |
329 | See https://dri.freedesktop.org/docs/drm/ for what's there already. | |
330 | ||
331 | Contact: Daniel Vetter | |
332 | ||
0e70dad0 TR |
333 | Make panic handling work |
334 | ------------------------ | |
335 | ||
336 | This is a really varied tasks with lots of little bits and pieces: | |
337 | ||
338 | * The panic path can't be tested currently, leading to constant breaking. The | |
339 | main issue here is that panics can be triggered from hardirq contexts and | |
340 | hence all panic related callback can run in hardirq context. It would be | |
341 | awesome if we could test at least the fbdev helper code and driver code by | |
342 | e.g. trigger calls through drm debugfs files. hardirq context could be | |
343 | achieved by using an IPI to the local processor. | |
344 | ||
345 | * There's a massive confusion of different panic handlers. DRM fbdev emulation | |
346 | helpers have one, but on top of that the fbcon code itself also has one. We | |
347 | need to make sure that they stop fighting over each another. | |
348 | ||
349 | * ``drm_can_sleep()`` is a mess. It hides real bugs in normal operations and | |
350 | isn't a full solution for panic paths. We need to make sure that it only | |
351 | returns true if there's a panic going on for real, and fix up all the | |
352 | fallout. | |
353 | ||
354 | * The panic handler must never sleep, which also means it can't ever | |
355 | ``mutex_lock()``. Also it can't grab any other lock unconditionally, not | |
356 | even spinlocks (because NMI and hardirq can panic too). We need to either | |
357 | make sure to not call such paths, or trylock everything. Really tricky. | |
358 | ||
359 | * For the above locking troubles reasons it's pretty much impossible to | |
360 | attempt a synchronous modeset from panic handlers. The only thing we could | |
361 | try to achive is an atomic ``set_base`` of the primary plane, and hope that | |
362 | it shows up. Everything else probably needs to be delayed to some worker or | |
363 | something else which happens later on. Otherwise it just kills the box | |
364 | harder, prevent the panic from going out on e.g. netconsole. | |
365 | ||
366 | * There's also proposal for a simplied DRM console instead of the full-blown | |
367 | fbcon and DRM fbdev emulation. Any kind of panic handling tricks should | |
368 | obviously work for both console, in case we ever get kmslog merged. | |
369 | ||
370 | Contact: Daniel Vetter | |
371 | ||
0cad7f71 DV |
372 | Clean up the debugfs support |
373 | ---------------------------- | |
374 | ||
375 | There's a bunch of issues with it: | |
376 | ||
377 | - The drm_info_list ->show() function doesn't even bother to cast to the drm | |
378 | structure for you. This is lazy. | |
379 | ||
380 | - We probably want to have some support for debugfs files on crtc/connectors and | |
381 | maybe other kms objects directly in core. There's even drm_print support in | |
382 | the funcs for these objects to dump kms state, so it's all there. And then the | |
383 | ->show() functions should obviously give you a pointer to the right object. | |
384 | ||
385 | - The drm_info_list stuff is centered on drm_minor instead of drm_device. For | |
386 | anything we want to print drm_device (or maybe drm_file) is the right thing. | |
387 | ||
388 | - The drm_driver->debugfs_init hooks we have is just an artifact of the old | |
389 | midlayered load sequence. DRM debugfs should work more like sysfs, where you | |
390 | can create properties/files for an object anytime you want, and the core | |
391 | takes care of publishing/unpuplishing all the files at register/unregister | |
392 | time. Drivers shouldn't need to worry about these technicalities, and fixing | |
393 | this (together with the drm_minor->drm_device move) would allow us to remove | |
394 | debugfs_init. | |
395 | ||
396 | Contact: Daniel Vetter | |
397 | ||
81a7bd4a DV |
398 | KMS cleanups |
399 | ------------ | |
400 | ||
401 | Some of these date from the very introduction of KMS in 2008 ... | |
402 | ||
e6a3e405 DV |
403 | - Make ->funcs and ->helper_private vtables optional. There's a bunch of empty |
404 | function tables in drivers, but before we can remove them we need to make sure | |
405 | that all the users in helpers and drivers do correctly check for a NULL | |
406 | vtable. | |
407 | ||
408 | - Cleanup up the various ->destroy callbacks. A lot of them just wrapt the | |
409 | drm_*_cleanup implementations and can be removed. Some tack a kfree() at the | |
410 | end, for which we could add drm_*_cleanup_kfree(). And then there's the (for | |
411 | historical reasons) misnamed drm_primary_helper_destroy() function. | |
412 | ||
0e70dad0 TR |
413 | Better Testing |
414 | ============== | |
415 | ||
416 | Enable trinity for DRM | |
417 | ---------------------- | |
418 | ||
419 | And fix up the fallout. Should be really interesting ... | |
420 | ||
421 | Make KMS tests in i-g-t generic | |
422 | ------------------------------- | |
423 | ||
424 | The i915 driver team maintains an extensive testsuite for the i915 DRM driver, | |
425 | including tons of testcases for corner-cases in the modesetting API. It would | |
426 | be awesome if those tests (at least the ones not relying on Intel-specific GEM | |
427 | features) could be made to run on any KMS driver. | |
428 | ||
429 | Basic work to run i-g-t tests on non-i915 is done, what's now missing is mass- | |
430 | converting things over. For modeset tests we also first need a bit of | |
431 | infrastructure to use dumb buffers for untiled buffers, to be able to run all | |
432 | the non-i915 specific modeset tests. | |
433 | ||
ad9ff96f HM |
434 | Extend virtual test driver (VKMS) |
435 | --------------------------------- | |
436 | ||
437 | See the documentation of :ref:`VKMS <vkms>` for more details. This is an ideal | |
438 | internship task, since it only requires a virtual machine and can be sized to | |
439 | fit the available time. | |
440 | ||
0e70dad0 TR |
441 | Contact: Daniel Vetter |
442 | ||
0e70dad0 TR |
443 | Driver Specific |
444 | =============== | |
445 | ||
f217f554 DV |
446 | tinydrm |
447 | ------- | |
448 | ||
449 | Tinydrm is the helper driver for really simple fb drivers. The goal is to make | |
450 | those drivers as simple as possible, so lots of room for refactoring: | |
451 | ||
452 | - backlight helpers, probably best to put them into a new drm_backlight.c. | |
453 | This is because drivers/video is de-facto unmaintained. We could also | |
454 | move drivers/video/backlight to drivers/gpu/backlight and take it all | |
9949b355 MM |
455 | over within drm-misc, but that's more work. Backlight helpers require a fair |
456 | bit of reworking and refactoring. A simple example is the enabling of a backlight. | |
457 | Tinydrm has helpers for this. It would be good if other drivers can also use the | |
458 | helper. However, there are various cases we need to consider i.e different | |
459 | drivers seem to have different ways of enabling/disabling a backlight. | |
460 | We also need to consider the backlight drivers (like gpio_backlight). The situation | |
461 | is further complicated by the fact that the backlight is tied to fbdev | |
462 | via fb_notifier_callback() which has complicated logic. For further details, refer | |
463 | to the following discussion thread: | |
464 | https://groups.google.com/forum/#!topic/outreachy-kernel/8rBe30lwtdA | |
f217f554 DV |
465 | |
466 | - spi helpers, probably best put into spi core/helper code. Thierry said | |
467 | the spi maintainer is fast&reactive, so shouldn't be a big issue. | |
468 | ||
469 | - extract the mipi-dbi helper (well, the non-tinydrm specific parts at | |
470 | least) into a separate helper, like we have for mipi-dsi already. Or follow | |
471 | one of the ideas for having a shared dsi/dbi helper, abstracting away the | |
472 | transport details more. | |
473 | ||
f217f554 DV |
474 | Contact: Noralf Trønnes, Daniel Vetter |
475 | ||
0a26a45d HW |
476 | AMD DC Display Driver |
477 | --------------------- | |
478 | ||
479 | AMD DC is the display driver for AMD devices starting with Vega. There has been | |
480 | a bunch of progress cleaning it up but there's still plenty of work to be done. | |
481 | ||
482 | See drivers/gpu/drm/amd/display/TODO for tasks. | |
483 | ||
484 | Contact: Harry Wentland, Alex Deucher | |
485 | ||
7b3b61b6 DV |
486 | i915 |
487 | ---- | |
488 | ||
489 | - Our early/late pm callbacks could be removed in favour of using | |
490 | device_link_add to model the dependency between i915 and snd_had. See | |
491 | https://dri.freedesktop.org/docs/drm/driver-api/device_link.html | |
492 | ||
ce256008 NT |
493 | Bootsplash |
494 | ========== | |
495 | ||
496 | There is support in place now for writing internal DRM clients making it | |
497 | possible to pick up the bootsplash work that was rejected because it was written | |
498 | for fbdev. | |
499 | ||
500 | - [v6,8/8] drm/client: Hack: Add bootsplash example | |
501 | https://patchwork.freedesktop.org/patch/306579/ | |
502 | ||
503 | - [RFC PATCH v2 00/13] Kernel based bootsplash | |
504 | https://lkml.org/lkml/2017/12/13/764 | |
505 | ||
506 | Contact: Sam Ravnborg | |
507 | ||
0e70dad0 TR |
508 | Outside DRM |
509 | =========== |