From 10ebd8556b7990499c896a550e3d416b444211e6 Mon Sep 17 00:00:00 2001 From: hc <hc@nodka.com> Date: Fri, 10 May 2024 02:23:07 +0000 Subject: [PATCH] add led --- kernel/Documentation/gpu/todo.rst | 584 +++++++++++++++++++++++++++++++++++++++------------------- 1 files changed, 391 insertions(+), 193 deletions(-) diff --git a/kernel/Documentation/gpu/todo.rst b/kernel/Documentation/gpu/todo.rst index a7c150d..2884160 100644 --- a/kernel/Documentation/gpu/todo.rst +++ b/kernel/Documentation/gpu/todo.rst @@ -7,43 +7,36 @@ This section contains a list of smaller janitorial tasks in the kernel DRM graphics subsystem useful as newbie projects. Or for slow rainy days. +Difficulty +---------- + +To make it easier task are categorized into different levels: + +Starter: Good tasks to get started with the DRM subsystem. + +Intermediate: Tasks which need some experience with working in the DRM +subsystem, or some specific GPU/display graphics knowledge. For debugging issue +it's good to have the relevant hardware (or a virtual driver set up) available +for testing. + +Advanced: Tricky tasks that need fairly good understanding of the DRM subsystem +and graphics topics. Generally need the relevant hardware for development and +testing. + Subsystem-wide refactorings =========================== -De-midlayer drivers -------------------- +Remove custom dumb_map_offset implementations +--------------------------------------------- -With the recent ``drm_bus`` cleanup patches for 3.17 it is no longer required -to have a ``drm_bus`` structure set up. Drivers can directly set up the -``drm_device`` structure instead of relying on bus methods in ``drm_usb.c`` -and ``drm_pci.c``. The goal is to get rid of the driver's ``->load`` / -``->unload`` callbacks and open-code the load/unload sequence properly, using -the new two-stage ``drm_device`` setup/teardown. +All GEM based drivers should be using drm_gem_create_mmap_offset() instead. +Audit each individual driver, make sure it'll work with the generic +implementation (there's lots of outdated locking leftovers in various +implementations), and then remove it. -Once all existing drivers are converted we can also remove those bus support -files for USB and platform devices. +Contact: Daniel Vetter, respective driver maintainers -All you need is a GPU for a non-converted driver (currently almost all of -them, but also all the virtual ones used by KVM, so everyone qualifies). - -Contact: Daniel Vetter, Thierry Reding, respective driver maintainers - -Switch from reference/unreference to get/put --------------------------------------------- - -For some reason DRM core uses ``reference``/``unreference`` suffixes for -refcounting functions, but kernel uses ``get``/``put`` (e.g. -``kref_get``/``put()``). It would be good to switch over for consistency, and -it's shorter. Needs to be done in 3 steps for each pair of functions: - -* Create new ``get``/``put`` functions, define the old names as compatibility - wrappers -* Switch over each file/driver using a cocci-generated spatch. -* Once all users of the old names are gone, remove them. - -This way drivers/patches in the progress of getting merged won't break. - -Contact: Daniel Vetter +Level: Intermediate Convert existing KMS drivers to atomic modesetting -------------------------------------------------- @@ -63,6 +56,8 @@ Contact: Daniel Vetter, respective driver maintainers +Level: Advanced + Clean up the clipped coordination confusion around planes --------------------------------------------------------- @@ -74,6 +69,30 @@ helpers. Contact: Ville Syrjälä, Daniel Vetter, driver maintainers + +Level: Advanced + +Improve plane atomic_check helpers +---------------------------------- + +Aside from the clipped coordinates right above there's a few suboptimal things +with the current helpers: + +- drm_plane_helper_funcs->atomic_check gets called for enabled or disabled + planes. At best this seems to confuse drivers, worst it means they blow up + when the plane is disabled without the CRTC. The only special handling is + resetting values in the plane state structures, which instead should be moved + into the drm_plane_funcs->atomic_duplicate_state functions. + +- Once that's done, helpers could stop calling ->atomic_check for disabled + planes. + +- Then we could go through all the drivers and remove the more-or-less confused + checks for plane_state->fb and plane_state->crtc. + +Contact: Daniel Vetter + +Level: Advanced Convert early atomic drivers to async commit helpers ---------------------------------------------------- @@ -88,29 +107,7 @@ Contact: Daniel Vetter, respective driver maintainers -Better manual-upload support for atomic ---------------------------------------- - -This would be especially useful for tinydrm: - -- Add a struct drm_rect dirty_clip to drm_crtc_state. When duplicating the - crtc state, clear that to the max values, x/y = 0 and w/h = MAX_INT, in - __drm_atomic_helper_crtc_duplicate_state(). - -- Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm\_ - prefix ofc and using drm_fb\_. drm_framebuffer.c makes sense since this - is a function useful to implement the fb->dirty function. - -- Create a new drm_fb_dirty function which does essentially what e.g. - mipi_dbi_fb_dirty does. You can use e.g. drm_atomic_helper_update_plane as the - template. But instead of doing a simple full-screen plane update, this new - helper also sets crtc_state->dirty_clip to the right coordinates. And of - course it needs to check whether the fb is actually active (and maybe where), - so there's some book-keeping involved. There's also some good fun involved in - scaling things appropriately. For that case we might simply give up and - declare the entire area covered by the plane as dirty. - -Contact: Noralf Trønnes, Daniel Vetter +Level: Advanced Fallout from atomic KMS ----------------------- @@ -127,7 +124,8 @@ the acquire context explicitly on stack and then also pass it down into drivers explicitly so that the legacy-on-atomic functions can use them. - Except for some driver code this is done. + Except for some driver code this is done. This task should be finished by + adding WARN_ON(!drm_drv_uses_atomic_modeset) in drm_modeset_lock_all(). * A bunch of the vtable hooks are now in the wrong place: DRM has a split between core vfunc tables (named ``drm_foo_funcs``), which are used to @@ -137,14 +135,9 @@ ``_helper_funcs`` since they are not part of the core ABI. There's a ``FIXME`` comment in the kerneldoc for each such case in ``drm_crtc.h``. -* There's a new helper ``drm_atomic_helper_best_encoder()`` which could be - used by all atomic drivers which don't select the encoder for a given - connector at runtime. That's almost all of them, and would allow us to get - rid of a lot of ``best_encoder`` boilerplate in drivers. - - This was almost done, but new drivers added a few more cases again. - Contact: Daniel Vetter + +Level: Intermediate Get rid of dev->struct_mutex from GEM drivers --------------------------------------------- @@ -164,20 +157,21 @@ reliably take that lock any more. Instead state needs to be protected with suitable subordinate locks or some cleanup work pushed to a worker thread. For performance-critical drivers it might also be better to go with a more -fine-grained per-buffer object and per-context lockings scheme. Currently the -following drivers still use ``struct_mutex``: ``msm``, ``omapdrm`` and -``udl``. +fine-grained per-buffer object and per-context lockings scheme. Currently only +the ``msm`` and `i915` drivers use ``struct_mutex``. Contact: Daniel Vetter, respective driver maintainers -Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent ----------------------------------------------------------------------------- +Level: Advanced + +Convert logging to drm_* functions with drm_device paramater +------------------------------------------------------------ For drivers which could have multiple instances, it is necessary to differentiate between which is which in the logs. Since DRM_INFO/WARN/ERROR don't do this, drivers used dev_info/warn/err to make this differentiation. We -now have DRM_DEV_* variants of the drm print macros, so we can start to convert -those drivers back to using drm-formwatted specific log messages. +now have drm_* variants of the drm print functions, so we can start to convert +those drivers back to using drm-formatted specific log messages. Before you start this conversion please contact the relevant maintainers to make sure your work will be merged - not everyone agrees that the DRM dmesg macros @@ -185,50 +179,99 @@ Contact: Sean Paul, Maintainer of the driver you plan to convert +Level: Starter + Convert drivers to use simple modeset suspend/resume ---------------------------------------------------- Most drivers (except i915 and nouveau) that use drm_atomic_helper_suspend/resume() can probably be converted to use -drm_mode_config_helper_suspend/resume(). +drm_mode_config_helper_suspend/resume(). Also there's still open-coded version +of the atomic suspend/resume code in older atomic modeset drivers. Contact: Maintainer of the driver you plan to convert -Convert drivers to use drm_fb_helper_fbdev_setup/teardown() ------------------------------------------------------------ +Level: Intermediate -Most drivers can use drm_fb_helper_fbdev_setup() except maybe: +Convert drivers to use drm_fbdev_generic_setup() +------------------------------------------------ -- amdgpu which has special logic to decide whether to call - drm_helper_disable_unused_functions() - -- armada which isn't atomic and doesn't call - drm_helper_disable_unused_functions() - -- i915 which calls drm_fb_helper_initial_config() in a worker - -Drivers that use drm_framebuffer_remove() to clean up the fbdev framebuffer can -probably use drm_fb_helper_fbdev_teardown(). +Most drivers can use drm_fbdev_generic_setup(). Driver have to implement +atomic modesetting and GEM vmap support. Current generic fbdev emulation +expects the framebuffer in system memory (or system-like memory). Contact: Maintainer of the driver you plan to convert + +Level: Intermediate + +drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup +----------------------------------------------------------------- + +A lot more drivers could be switched over to the drm_gem_framebuffer helpers. +Various hold-ups: + +- Need to switch over to the generic dirty tracking code using + drm_atomic_helper_dirtyfb first (e.g. qxl). + +- Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb + setup code can't be deleted. + +- Many drivers wrap drm_gem_fb_create() only to check for valid formats. For + atomic drivers we could check for valid formats by calling + drm_plane_check_pixel_format() against all planes, and pass if any plane + supports the format. For non-atomic that's not possible since like the format + list for the primary plane is fake and we'd therefor reject valid formats. + +- Many drivers subclass drm_framebuffer, we'd need a embedding compatible + version of the varios drm_gem_fb_create functions. Maybe called + drm_gem_fb_create/_with_dirty/_with_funcs as needed. + +Contact: Daniel Vetter + +Level: Intermediate Clean up mmap forwarding ------------------------ A lot of drivers forward gem mmap calls to dma-buf mmap for imported buffers. And also a lot of them forward dma-buf mmap to the gem mmap implementations. -Would be great to refactor this all into a set of small common helpers. +There's drm_gem_prime_mmap() for this now, but still needs to be rolled out. Contact: Daniel Vetter -Put a reservation_object into drm_gem_object --------------------------------------------- +Level: Intermediate -This would remove the need for the ->gem_prime_res_obj callback. It would also -allow us to implement generic helpers for waiting for a bo, allowing for quite a -bit of refactoring in the various wait ioctl implementations. +Generic fbdev defio support +--------------------------- -Contact: Daniel Vetter +The defio support code in the fbdev core has some very specific requirements, +which means drivers need to have a special framebuffer for fbdev. The main +issue is that it uses some fields in struct page itself, which breaks shmem +gem objects (and other things). To support defio, affected drivers require +the use of a shadow buffer, which may add CPU and memory overhead. + +Possible solution would be to write our own defio mmap code in the drm fbdev +emulation. It would need to fully wrap the existing mmap ops, forwarding +everything after it has done the write-protect/mkwrite trickery: + +- In the drm_fbdev_fb_mmap helper, if we need defio, change the + default page prots to write-protected with something like this:: + + vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot); + +- Set the mkwrite and fsync callbacks with similar implementions to the core + fbdev defio stuff. These should all work on plain ptes, they don't actually + require a struct page. uff. These should all work on plain ptes, they don't + actually require a struct page. + +- Track the dirty pages in a separate structure (bitfield with one bit per page + should work) to avoid clobbering struct page. + +Might be good to also have some igt testcases for this. + +Contact: Daniel Vetter, Noralf Tronnes + +Level: Advanced idr_init_base() --------------- @@ -240,63 +283,175 @@ Contact: Daniel Vetter -Core refactorings -================= +Level: Starter -Clean up the DRM header mess ----------------------------- +struct drm_gem_object_funcs +--------------------------- -Currently the DRM subsystem has only one global header, ``drmP.h``. This is -used both for functions exported to helper libraries and drivers and functions -only used internally in the ``drm.ko`` module. The goal would be to move all -header declarations not needed outside of ``drm.ko`` into -``drivers/gpu/drm/drm_*_internal.h`` header files. ``EXPORT_SYMBOL`` also -needs to be dropped for these functions. +GEM objects can now have a function table instead of having the callbacks on the +DRM driver struct. This is now the preferred way and drivers can be moved over. -This would nicely tie in with the below task to create kerneldoc after the API -is cleaned up. Or with the "hide legacy cruft better" task. +We also need a 2nd version of the CMA define that doesn't require the +vmapping to be present (different hook for prime importing). Plus this needs to +be rolled out to all drivers using their own implementations, too. -Note that this is well in progress, but ``drmP.h`` is still huge. The updated -plan is to switch to per-file driver API headers, which will also structure -the kerneldoc better. This should also allow more fine-grained ``#include`` -directives. +Level: Intermediate -In the end no .c file should need to include ``drmP.h`` anymore. +Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate +--------------------------------------------------------- + +For cases where drivers are attempting to grab the modeset locks with a local +acquire context. Replace the boilerplate code surrounding +drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN() and +DRM_MODESET_LOCK_ALL_END() instead. + +This should also be done for all places where drm_modeset_lock_all() is still +used. + +As a reference, take a look at the conversions already completed in drm core. + +Contact: Sean Paul, respective driver maintainers + +Level: Starter + +Rename CMA helpers to DMA helpers +--------------------------------- + +CMA (standing for contiguous memory allocator) is really a bit an accident of +what these were used for first, a much better name would be DMA helpers. In the +text these should even be called coherent DMA memory helpers (so maybe CDM, but +no one knows what that means) since underneath they just use dma_alloc_coherent. + +Contact: Laurent Pinchart, Daniel Vetter + +Level: Intermediate (mostly because it is a huge tasks without good partial +milestones, not technically itself that challenging) + +connector register/unregister fixes +----------------------------------- + +- For most connectors it's a no-op to call drm_connector_register/unregister + directly from driver code, drm_dev_register/unregister take care of this + already. We can remove all of them. + +- For dp drivers it's a bit more a mess, since we need the connector to be + registered when calling drm_dp_aux_register. Fix this by instead calling + drm_dp_aux_init, and moving the actual registering into a late_register + callback as recommended in the kerneldoc. + +Level: Intermediate + +Remove load/unload callbacks from all non-DRIVER_LEGACY drivers +--------------------------------------------------------------- + +The load/unload callbacks in struct &drm_driver are very much midlayers, plus +for historical reasons they get the ordering wrong (and we can't fix that) +between setting up the &drm_driver structure and calling drm_dev_register(). + +- Rework drivers to no longer use the load/unload callbacks, directly coding the + load/unload sequence into the driver's probe function. + +- Once all non-DRIVER_LEGACY drivers are converted, disallow the load/unload + callbacks for all modern drivers. Contact: Daniel Vetter -Add missing kerneldoc for exported functions +Level: Intermediate + +Replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi +--------------------------------------------------------------- + +Once EDID is parsed, the monitor HDMI support information is available through +drm_display_info.is_hdmi. Many drivers still call drm_detect_hdmi_monitor() to +retrieve the same information, which is less efficient. + +Audit each individual driver calling drm_detect_hdmi_monitor() and switch to +drm_display_info.is_hdmi if applicable. + +Contact: Laurent Pinchart, respective driver maintainers + +Level: Intermediate + +Consolidate custom driver modeset properties -------------------------------------------- -The DRM reference documentation is still lacking kerneldoc in a few areas. The -task would be to clean up interfaces like moving functions around between -files to better group them and improving the interfaces like dropping return -values for functions that never fail. Then write kerneldoc for all exported -functions and an overview section and integrate it all into the drm book. +Before atomic modeset took place, many drivers where creating their own +properties. Among other things, atomic brought the requirement that custom, +driver specific properties should not be used. -See https://dri.freedesktop.org/docs/drm/ for what's there already. +For this task, we aim to introduce core helpers or reuse the existing ones +if available: -Contact: Daniel Vetter +A quick, unconfirmed, examples list. -Hide legacy cruft better ------------------------- +Introduce core helpers: +- audio (amdgpu, intel, gma500, radeon) +- brightness, contrast, etc (armada, nouveau) - overlay only (?) +- broadcast rgb (gma500, intel) +- colorkey (armada, nouveau, rcar) - overlay only (?) +- dither (amdgpu, nouveau, radeon) - varies across drivers +- underscan family (amdgpu, radeon, nouveau) -Way back DRM supported only drivers which shadow-attached to PCI devices with -userspace or fbdev drivers setting up outputs. Modern DRM drivers take charge -of the entire device, you can spot them with the DRIVER_MODESET flag. +Already in core: +- colorspace (sti) +- tv format names, enhancements (gma500, intel) +- tv overscan, margins, etc. (gma500, intel) +- zorder (omapdrm) - same as zpos (?) -Unfortunately there's still large piles of legacy code around which needs to -be hidden so that driver writers don't accidentally end up using it. And to -prevent security issues in those legacy IOCTLs from being exploited on modern -drivers. This has multiple possible subtasks: -* Extract support code for legacy features into a ``drm-legacy.ko`` kernel - module and compile it only when one of the legacy drivers is enabled. +Contact: Emil Velikov, respective driver maintainers -This is mostly done, the only thing left is to split up ``drm_irq.c`` into -legacy cruft and the parts needed by modern KMS drivers. +Level: Intermediate -Contact: Daniel Vetter +Plumb drm_atomic_state all over +------------------------------- + +Currently various atomic functions take just a single or a handful of +object states (eg. plane state). While that single object state can +suffice for some simple cases, we often have to dig out additional +object states for dealing with various dependencies between the individual +objects or the hardware they represent. The process of digging out the +additional states is rather non-intuitive and error prone. + +To fix that most functions should rather take the overall +drm_atomic_state as one of their parameters. The other parameters +would generally be the object(s) we mainly want to interact with. + +For example, instead of + +.. code-block:: c + + int (*atomic_check)(struct drm_plane *plane, struct drm_plane_state *state); + +we would have something like + +.. code-block:: c + + int (*atomic_check)(struct drm_plane *plane, struct drm_atomic_state *state); + +The implementation can then trivially gain access to any required object +state(s) via drm_atomic_get_plane_state(), drm_atomic_get_new_plane_state(), +drm_atomic_get_old_plane_state(), and their equivalents for +other object types. + +Additionally many drivers currently access the object->state pointer +directly in their commit functions. That is not going to work if we +eg. want to allow deeper commit pipelines as those pointers could +then point to the states corresponding to a future commit instead of +the current commit we're trying to process. Also non-blocking commits +execute locklessly so there are serious concerns with dereferencing +the object->state pointers without holding the locks that protect them. +Use of drm_atomic_get_new_plane_state(), drm_atomic_get_old_plane_state(), +etc. avoids these problems as well since they relate to a specific +commit via the passed in drm_atomic_state. + +Contact: Ville Syrjälä, Daniel Vetter + +Level: Intermediate + + +Core refactorings +================= Make panic handling work ------------------------ @@ -337,6 +492,8 @@ Contact: Daniel Vetter +Level: Advanced + Clean up the debugfs support ---------------------------- @@ -361,19 +518,50 @@ this (together with the drm_minor->drm_device move) would allow us to remove debugfs_init. +- Drop the return code and error checking from all debugfs functions. Greg KH is + working on this already. + Contact: Daniel Vetter + +Level: Intermediate KMS cleanups ------------ Some of these date from the very introduction of KMS in 2008 ... -- drm_mode_config.crtc_idr is misnamed, since it contains all KMS object. Should - be renamed to drm_mode_config.object_idr. +- Make ->funcs and ->helper_private vtables optional. There's a bunch of empty + function tables in drivers, but before we can remove them we need to make sure + that all the users in helpers and drivers do correctly check for a NULL + vtable. -- drm_display_mode doesn't need to be derived from drm_mode_object. That's - leftovers from older (never merged into upstream) KMS designs where modes - where set using their ID, including support to add/remove modes. +- Cleanup up the various ->destroy callbacks. A lot of them just wrapt the + drm_*_cleanup implementations and can be removed. Some tack a kfree() at the + end, for which we could add drm_*_cleanup_kfree(). And then there's the (for + historical reasons) misnamed drm_primary_helper_destroy() function. + +Level: Intermediate + +Remove automatic page mapping from dma-buf importing +---------------------------------------------------- + +When importing dma-bufs, the dma-buf and PRIME frameworks automatically map +imported pages into the importer's DMA area. drm_gem_prime_fd_to_handle() and +drm_gem_prime_handle_to_fd() require that importers call dma_buf_attach() +even if they never do actual device DMA, but only CPU access through +dma_buf_vmap(). This is a problem for USB devices, which do not support DMA +operations. + +To fix the issue, automatic page mappings should be removed from the +buffer-sharing code. Fixing this is a bit more involved, since the import/export +cache is also tied to &drm_gem_object.import_attach. Meanwhile we paper over +this problem for USB devices by fishing out the USB host controller device, as +long as that supports DMA. Otherwise importing can still needlessly fail. + +Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter + +Level: Advanced + Better Testing ============== @@ -382,6 +570,8 @@ ---------------------- And fix up the fallout. Should be really interesting ... + +Level: Advanced Make KMS tests in i-g-t generic ------------------------------- @@ -396,67 +586,36 @@ infrastructure to use dumb buffers for untiled buffers, to be able to run all the non-i915 specific modeset tests. -Contact: Daniel Vetter +Level: Advanced -Create a virtual KMS driver for testing (vkms) ----------------------------------------------- +Extend virtual test driver (VKMS) +--------------------------------- -With all the latest helpers it should be fairly simple to create a virtual KMS -driver useful for testing, or for running X or similar on headless machines -(to be able to still use the GPU). This would be similar to vgem, but aimed at -the modeset side. - -Once the basics are there there's tons of possibilities to extend it. +See the documentation of :ref:`VKMS <vkms>` for more details. This is an ideal +internship task, since it only requires a virtual machine and can be sized to +fit the available time. Contact: Daniel Vetter + +Level: See details + +Backlight Refactoring +--------------------- + +Backlight drivers have a triple enable/disable state, which is a bit overkill. +Plan to fix this: + +1. Roll out backlight_enable() and backlight_disable() helpers everywhere. This + has started already. +2. In all, only look at one of the three status bits set by the above helpers. +3. Remove the other two status bits. + +Contact: Daniel Vetter + +Level: Intermediate Driver Specific =============== - -tinydrm -------- - -Tinydrm is the helper driver for really simple fb drivers. The goal is to make -those drivers as simple as possible, so lots of room for refactoring: - -- backlight helpers, probably best to put them into a new drm_backlight.c. - This is because drivers/video is de-facto unmaintained. We could also - move drivers/video/backlight to drivers/gpu/backlight and take it all - over within drm-misc, but that's more work. Backlight helpers require a fair - bit of reworking and refactoring. A simple example is the enabling of a backlight. - Tinydrm has helpers for this. It would be good if other drivers can also use the - helper. However, there are various cases we need to consider i.e different - drivers seem to have different ways of enabling/disabling a backlight. - We also need to consider the backlight drivers (like gpio_backlight). The situation - is further complicated by the fact that the backlight is tied to fbdev - via fb_notifier_callback() which has complicated logic. For further details, refer - to the following discussion thread: - https://groups.google.com/forum/#!topic/outreachy-kernel/8rBe30lwtdA - -- spi helpers, probably best put into spi core/helper code. Thierry said - the spi maintainer is fast&reactive, so shouldn't be a big issue. - -- extract the mipi-dbi helper (well, the non-tinydrm specific parts at - least) into a separate helper, like we have for mipi-dsi already. Or follow - one of the ideas for having a shared dsi/dbi helper, abstracting away the - transport details more. - -- tinydrm_gem_cma_prime_import_sg_table should probably go into the cma - helpers, as a _vmapped variant (since not every driver needs the vmap). - And tinydrm_gem_cma_free_object could the be merged into - drm_gem_cma_free_object(). - -- tinydrm_fb_create we could move into drm_simple_pipe, only need to add - the fb_create hook to drm_simple_pipe_funcs, which would again simplify a - bunch of things (since it gives you a one-stop vfunc for simple drivers). - -- Quick aside: The unregister devm stuff is kinda getting the lifetimes of - a drm_device wrong. Doesn't matter, since everyone else gets it wrong - too :-) - -- also rework the drm_framebuffer_funcs->dirty hook wire-up, see above. - -Contact: Noralf Trønnes, Daniel Vetter AMD DC Display Driver --------------------- @@ -468,12 +627,51 @@ Contact: Harry Wentland, Alex Deucher -i915 ----- +Bootsplash +========== -- Our early/late pm callbacks could be removed in favour of using - device_link_add to model the dependency between i915 and snd_had. See - https://dri.freedesktop.org/docs/drm/driver-api/device_link.html +There is support in place now for writing internal DRM clients making it +possible to pick up the bootsplash work that was rejected because it was written +for fbdev. + +- [v6,8/8] drm/client: Hack: Add bootsplash example + https://patchwork.freedesktop.org/patch/306579/ + +- [RFC PATCH v2 00/13] Kernel based bootsplash + https://lkml.org/lkml/2017/12/13/764 + +Contact: Sam Ravnborg + +Level: Advanced Outside DRM =========== + +Convert fbdev drivers to DRM +---------------------------- + +There are plenty of fbdev drivers for older hardware. Some hwardware has +become obsolete, but some still provides good(-enough) framebuffers. The +drivers that are still useful should be converted to DRM and afterwards +removed from fbdev. + +Very simple fbdev drivers can best be converted by starting with a new +DRM driver. Simple KMS helpers and SHMEM should be able to handle any +existing hardware. The new driver's call-back functions are filled from +existing fbdev code. + +More complex fbdev drivers can be refactored step-by-step into a DRM +driver with the help of the DRM fbconv helpers. [1] These helpers provide +the transition layer between the DRM core infrastructure and the fbdev +driver interface. Create a new DRM driver on top of the fbconv helpers, +copy over the fbdev driver, and hook it up to the DRM code. Examples for +several fbdev drivers are available at [1] and a tutorial of this process +available at [2]. The result is a primitive DRM driver that can run X11 +and Weston. + + - [1] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv + - [2] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c + +Contact: Thomas Zimmermann <tzimmermann@suse.de> + +Level: Advanced -- Gitblit v1.6.2