forked from ~ljy/RK356X_SDK_RELEASE

blame | history | patch | commit | commitdiff
hc
2024-05-10 10ebd8556b7990499c896a550e3d416b444211e6 
 kernel/Documentation/gpu/todo.rst
....@@ -7,43 +7,36 @@
77 This section contains a list of smaller janitorial tasks in the kernel DRM
88 graphics subsystem useful as newbie projects. Or for slow rainy days.
99 
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
+
1026 Subsystem-wide refactorings
1127 ===========================
1228 
13
-De-midlayer drivers
14
--------------------
29
+Remove custom dumb_map_offset implementations
30
+---------------------------------------------
1531 
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_pci.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.
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.
2236 
23
-Once all existing drivers are converted we can also remove those bus support
24
-files for USB and platform devices.
37
+Contact: Daniel Vetter, respective driver maintainers
2538 
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
39
+Level: Intermediate
4740 
4841 Convert existing KMS drivers to atomic modesetting
4942 --------------------------------------------------
....@@ -63,6 +56,8 @@
6356 
6457 Contact: Daniel Vetter, respective driver maintainers
6558 
59
+Level: Advanced
60
+
6661 Clean up the clipped coordination confusion around planes
6762 ---------------------------------------------------------
6863 
....@@ -74,6 +69,30 @@
7469 helpers.
7570 
7671 Contact: Ville Syrjälä, Daniel Vetter, driver maintainers
72
+
73
+Level: Advanced
74
+
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
7796 
7897 Convert early atomic drivers to async commit helpers
7998 ----------------------------------------------------
....@@ -88,29 +107,7 @@
88107 
89108 Contact: Daniel Vetter, respective driver maintainers
90109 
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
-
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
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
110
+Level: Advanced
114111 
115112 Fallout from atomic KMS
116113 -----------------------
....@@ -127,7 +124,8 @@
127124   the acquire context explicitly on stack and then also pass it down into
128125   drivers explicitly so that the legacy-on-atomic functions can use them.
129126 
130
-  Except for some driver code this is done.
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().
131129 
132130 * A bunch of the vtable hooks are now in the wrong place: DRM has a split
133131   between core vfunc tables (named ``drm_foo_funcs``), which are used to
....@@ -137,14 +135,9 @@
137135   ``_helper_funcs`` since they are not part of the core ABI. There's a
138136   ``FIXME`` comment in the kerneldoc for each such case in ``drm_crtc.h``.
139137 
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
-
145
-  This was almost done, but new drivers added a few more cases again.
146
-
147138 Contact: Daniel Vetter
139
+
140
+Level: Intermediate
148141 
149142 Get rid of dev->struct_mutex from GEM drivers
150143 ---------------------------------------------
....@@ -164,20 +157,21 @@
164157 reliably take that lock any more. Instead state needs to be protected with
165158 suitable subordinate locks or some cleanup work pushed to a worker thread. For
166159 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``.
160
+fine-grained per-buffer object and per-context lockings scheme. Currently only
161
+the ``msm`` and `i915` drivers use ``struct_mutex``.
170162 
171163 Contact: Daniel Vetter, respective driver maintainers
172164 
173
-Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent
174
-----------------------------------------------------------------------------
165
+Level: Advanced
166
+
167
+Convert logging to drm_* functions with drm_device paramater
168
+------------------------------------------------------------
175169 
176170 For drivers which could have multiple instances, it is necessary to
177171 differentiate between which is which in the logs. Since DRM_INFO/WARN/ERROR
178172 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.
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.
181175 
182176 Before you start this conversion please contact the relevant maintainers to make
183177 sure your work will be merged - not everyone agrees that the DRM dmesg macros
....@@ -185,50 +179,99 @@
185179 
186180 Contact: Sean Paul, Maintainer of the driver you plan to convert
187181 
182
+Level: Starter
183
+
188184 Convert drivers to use simple modeset suspend/resume
189185 ----------------------------------------------------
190186 
191187 Most drivers (except i915 and nouveau) that use
192188 drm_atomic_helper_suspend/resume() can probably be converted to use
193
-drm_mode_config_helper_suspend/resume().
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.
194191 
195192 Contact: Maintainer of the driver you plan to convert
196193 
197
-Convert drivers to use drm_fb_helper_fbdev_setup/teardown()
198
------------------------------------------------------------
194
+Level: Intermediate
199195 
200
-Most drivers can use drm_fb_helper_fbdev_setup() except maybe:
196
+Convert drivers to use drm_fbdev_generic_setup()
197
+------------------------------------------------
201198 
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().
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).
212202 
213203 Contact: Maintainer of the driver you plan to convert
204
+
205
+Level: Intermediate
206
+
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
214232 
215233 Clean up mmap forwarding
216234 ------------------------
217235 
218236 A lot of drivers forward gem mmap calls to dma-buf mmap for imported buffers.
219237 And also a lot of them forward dma-buf mmap to the gem mmap implementations.
220
-Would be great to refactor this all into a set of small common helpers.
238
+There's drm_gem_prime_mmap() for this now, but still needs to be rolled out.
221239 
222240 Contact: Daniel Vetter
223241 
224
-Put a reservation_object into drm_gem_object
225
---------------------------------------------
242
+Level: Intermediate
226243 
227
-This would remove the need for the ->gem_prime_res_obj callback. It would also
228
-allow us to implement generic helpers for waiting for a bo, allowing for quite a
229
-bit of refactoring in the various wait ioctl implementations.
244
+Generic fbdev defio support
245
+---------------------------
230246 
231
-Contact: Daniel Vetter
247
+The defio support code in the fbdev core has some very specific requirements,
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.
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
+
274
+Level: Advanced
232275 
233276 idr_init_base()
234277 ---------------
....@@ -240,63 +283,175 @@
240283 
241284 Contact: Daniel Vetter
242285 
243
-Core refactorings
244
-=================
286
+Level: Starter
245287 
246
-Clean up the DRM header mess
247
-----------------------------
288
+struct drm_gem_object_funcs
289
+---------------------------
248290 
249
-Currently the DRM subsystem has only one global header, ``drmP.h``. This is
250
-used both for functions exported to helper libraries and drivers and functions
251
-only used internally in the ``drm.ko`` module. The goal would be to move all
252
-header declarations not needed outside of ``drm.ko`` into
253
-``drivers/gpu/drm/drm_*_internal.h`` header files. ``EXPORT_SYMBOL`` also
254
-needs to be dropped for these functions.
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.
255293 
256
-This would nicely tie in with the below task to create kerneldoc after the API
257
-is cleaned up. Or with the "hide legacy cruft better" task.
294
+We also need a 2nd version of the CMA define that doesn't require the
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.
258297 
259
-Note that this is well in progress, but ``drmP.h`` is still huge. The updated
260
-plan is to switch to per-file driver API headers, which will also structure
261
-the kerneldoc better. This should also allow more fine-grained ``#include``
262
-directives.
298
+Level: Intermediate
263299 
264
-In the end no .c file should need to include ``drmP.h`` anymore.
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
+
308
+This should also be done for all places where drm_modeset_lock_all() is still
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
+
315
+Level: Starter
316
+
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
+
327
+Level: Intermediate (mostly because it is a huge tasks without good partial
328
+milestones, not technically itself that challenging)
329
+
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
+
342
+Level: Intermediate
343
+
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.
265356 
266357 Contact: Daniel Vetter
267358 
268
-Add missing kerneldoc for exported functions
359
+Level: Intermediate
360
+
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
+
375
+Consolidate custom driver modeset properties
269376 --------------------------------------------
270377 
271
-The DRM reference documentation is still lacking kerneldoc in a few areas. The
272
-task would be to clean up interfaces like moving functions around between
273
-files to better group them and improving the interfaces like dropping return
274
-values for functions that never fail. Then write kerneldoc for all exported
275
-functions and an overview section and integrate it all into the drm book.
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.
276381 
277
-See https://dri.freedesktop.org/docs/drm/ for what's there already.
382
+For this task, we aim to introduce core helpers or reuse the existing ones
383
+if available:
278384 
279
-Contact: Daniel Vetter
385
+A quick, unconfirmed, examples list.
280386 
281
-Hide legacy cruft better
282
-------------------------
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)
283394 
284
-Way back DRM supported only drivers which shadow-attached to PCI devices with
285
-userspace or fbdev drivers setting up outputs. Modern DRM drivers take charge
286
-of the entire device, you can spot them with the DRIVER_MODESET flag.
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 (?)
287400 
288
-Unfortunately there's still large piles of legacy code around which needs to
289
-be hidden so that driver writers don't accidentally end up using it. And to
290
-prevent security issues in those legacy IOCTLs from being exploited on modern
291
-drivers. This has multiple possible subtasks:
292401 
293
-* Extract support code for legacy features into a ``drm-legacy.ko`` kernel
294
-  module and compile it only when one of the legacy drivers is enabled.
402
+Contact: Emil Velikov, respective driver maintainers
295403 
296
-This is mostly done, the only thing left is to split up ``drm_irq.c`` into
297
-legacy cruft and the parts needed by modern KMS drivers.
404
+Level: Intermediate
298405 
299
-Contact: Daniel Vetter
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
+
452
+
453
+Core refactorings
454
+=================
300455 
301456 Make panic handling work
302457 ------------------------
....@@ -337,6 +492,8 @@
337492 
338493 Contact: Daniel Vetter
339494 
495
+Level: Advanced
496
+
340497 Clean up the debugfs support
341498 ----------------------------
342499 
....@@ -361,19 +518,50 @@
361518   this (together with the drm_minor->drm_device move) would allow us to remove
362519   debugfs_init.
363520 
521
+- Drop the return code and error checking from all debugfs functions. Greg KH is
522
+  working on this already.
523
+
364524 Contact: Daniel Vetter
525
+
526
+Level: Intermediate
365527 
366528 KMS cleanups
367529 ------------
368530 
369531 Some of these date from the very introduction of KMS in 2008 ...
370532 
371
-- drm_mode_config.crtc_idr is misnamed, since it contains all KMS object. Should
372
-  be renamed to drm_mode_config.object_idr.
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.
373537 
374
-- drm_display_mode doesn't need to be derived from drm_mode_object. That's
375
-  leftovers from older (never merged into upstream) KMS designs where modes
376
-  where set using their ID, including support to add/remove modes.
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
+
543
+Level: Intermediate
544
+
545
+Remove automatic page mapping from dma-buf importing
546
+----------------------------------------------------
547
+
548
+When importing dma-bufs, the dma-buf and PRIME frameworks automatically map
549
+imported pages into the importer's DMA area. drm_gem_prime_fd_to_handle() and
550
+drm_gem_prime_handle_to_fd() require that importers call dma_buf_attach()
551
+even if they never do actual device DMA, but only CPU access through
552
+dma_buf_vmap(). This is a problem for USB devices, which do not support DMA
553
+operations.
554
+
555
+To fix the issue, automatic page mappings should be removed from the
556
+buffer-sharing code. Fixing this is a bit more involved, since the import/export
557
+cache is also tied to &drm_gem_object.import_attach. Meanwhile we paper over
558
+this problem for USB devices by fishing out the USB host controller device, as
559
+long as that supports DMA. Otherwise importing can still needlessly fail.
560
+
561
+Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter
562
+
563
+Level: Advanced
564
+
377565 
378566 Better Testing
379567 ==============
....@@ -382,6 +570,8 @@
382570 ----------------------
383571 
384572 And fix up the fallout. Should be really interesting ...
573
+
574
+Level: Advanced
385575 
386576 Make KMS tests in i-g-t generic
387577 -------------------------------
....@@ -396,67 +586,36 @@
396586 infrastructure to use dumb buffers for untiled buffers, to be able to run all
397587 the non-i915 specific modeset tests.
398588 
399
-Contact: Daniel Vetter
589
+Level: Advanced
400590 
401
-Create a virtual KMS driver for testing (vkms)
402
-----------------------------------------------
591
+Extend virtual test driver (VKMS)
592
+---------------------------------
403593 
404
-With all the latest helpers it should be fairly simple to create a virtual KMS
405
-driver useful for testing, or for running X or similar on headless machines
406
-(to be able to still use the GPU). This would be similar to vgem, but aimed at
407
-the modeset side.
408
-
409
-Once the basics are there there's tons of possibilities to extend it.
594
+See the documentation of :ref:`VKMS <vkms>` for more details. This is an ideal
595
+internship task, since it only requires a virtual machine and can be sized to
596
+fit the available time.
410597 
411598 Contact: Daniel Vetter
599
+
600
+Level: See details
601
+
602
+Backlight Refactoring
603
+---------------------
604
+
605
+Backlight drivers have a triple enable/disable state, which is a bit overkill.
606
+Plan to fix this:
607
+
608
+1. Roll out backlight_enable() and backlight_disable() helpers everywhere. This
609
+   has started already.
610
+2. In all, only look at one of the three status bits set by the above helpers.
611
+3. Remove the other two status bits.
612
+
613
+Contact: Daniel Vetter
614
+
615
+Level: Intermediate
412616 
413617 Driver Specific
414618 ===============
415
-
416
-tinydrm
417
--------
418
-
419
-Tinydrm is the helper driver for really simple fb drivers. The goal is to make
420
-those drivers as simple as possible, so lots of room for refactoring:
421
-
422
-- backlight helpers, probably best to put them into a new drm_backlight.c.
423
-  This is because drivers/video is de-facto unmaintained. We could also
424
-  move drivers/video/backlight to drivers/gpu/backlight and take it all
425
-  over within drm-misc, but that's more work. Backlight helpers require a fair
426
-  bit of reworking and refactoring. A simple example is the enabling of a backlight.
427
-  Tinydrm has helpers for this. It would be good if other drivers can also use the
428
-  helper. However, there are various cases we need to consider i.e different
429
-  drivers seem to have different ways of enabling/disabling a backlight.
430
-  We also need to consider the backlight drivers (like gpio_backlight). The situation
431
-  is further complicated by the fact that the backlight is tied to fbdev
432
-  via fb_notifier_callback() which has complicated logic. For further details, refer
433
-  to the following discussion thread:
434
-  https://groups.google.com/forum/#!topic/outreachy-kernel/8rBe30lwtdA
435
-
436
-- spi helpers, probably best put into spi core/helper code. Thierry said
437
-  the spi maintainer is fast&reactive, so shouldn't be a big issue.
438
-
439
-- extract the mipi-dbi helper (well, the non-tinydrm specific parts at
440
-  least) into a separate helper, like we have for mipi-dsi already. Or follow
441
-  one of the ideas for having a shared dsi/dbi helper, abstracting away the
442
-  transport details more.
443
-
444
-- tinydrm_gem_cma_prime_import_sg_table should probably go into the cma
445
-  helpers, as a _vmapped variant (since not every driver needs the vmap).
446
-  And tinydrm_gem_cma_free_object could the be merged into
447
-  drm_gem_cma_free_object().
448
-
449
-- tinydrm_fb_create we could move into drm_simple_pipe, only need to add
450
-  the fb_create hook to drm_simple_pipe_funcs, which would again simplify a
451
-  bunch of things (since it gives you a one-stop vfunc for simple drivers).
452
-
453
-- Quick aside: The unregister devm stuff is kinda getting the lifetimes of
454
-  a drm_device wrong. Doesn't matter, since everyone else gets it wrong
455
-  too :-)
456
-
457
-- also rework the drm_framebuffer_funcs->dirty hook wire-up, see above.
458
-
459
-Contact: Noralf Trønnes, Daniel Vetter
460619 
461620 AMD DC Display Driver
462621 ---------------------
....@@ -468,12 +627,51 @@
468627 
469628 Contact: Harry Wentland, Alex Deucher
470629 
471
-i915
472
-----
630
+Bootsplash
631
+==========
473632 
474
-- Our early/late pm callbacks could be removed in favour of using
475
-  device_link_add to model the dependency between i915 and snd_had. See
476
-  https://dri.freedesktop.org/docs/drm/driver-api/device_link.html
633
+There is support in place now for writing internal DRM clients making it
634
+possible to pick up the bootsplash work that was rejected because it was written
635
+for fbdev.
636
+
637
+- [v6,8/8] drm/client: Hack: Add bootsplash example
638
+  https://patchwork.freedesktop.org/patch/306579/
639
+
640
+- [RFC PATCH v2 00/13] Kernel based bootsplash
641
+  https://lkml.org/lkml/2017/12/13/764
642
+
643
+Contact: Sam Ravnborg
644
+
645
+Level: Advanced
477646 
478647 Outside DRM
479648 ===========
649
+
650
+Convert fbdev drivers to DRM
651
+----------------------------
652
+
653
+There are plenty of fbdev drivers for older hardware. Some hwardware has
654
+become obsolete, but some still provides good(-enough) framebuffers. The
655
+drivers that are still useful should be converted to DRM and afterwards
656
+removed from fbdev.
657
+
658
+Very simple fbdev drivers can best be converted by starting with a new
659
+DRM driver. Simple KMS helpers and SHMEM should be able to handle any
660
+existing hardware. The new driver's call-back functions are filled from
661
+existing fbdev code.
662
+
663
+More complex fbdev drivers can be refactored step-by-step into a DRM
664
+driver with the help of the DRM fbconv helpers. [1] These helpers provide
665
+the transition layer between the DRM core infrastructure and the fbdev
666
+driver interface. Create a new DRM driver on top of the fbconv helpers,
667
+copy over the fbdev driver, and hook it up to the DRM code. Examples for
668
+several fbdev drivers are available at [1] and a tutorial of this process
669
+available at [2]. The result is a primitive DRM driver that can run X11
670
+and Weston.
671
+
672
+ - [1] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv
673
+ - [2] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c
674
+
675
+Contact: Thomas Zimmermann <tzimmermann@suse.de>
676
+
677
+Level: Advanced