9sphinx.addnodesdocument)}( rawsourcechildren]( translations LanguagesNode)}(hhh](h pending_xref)}(hhh]docutils.nodesTextChinese (Simplified)}parenthsba attributes}(ids]classes]names]dupnames]backrefs] refdomainstdreftypedoc reftarget/translations/zh_CN/gpu/todomodnameN classnameN refexplicitutagnamehhh ubh)}(hhh]hChinese (Traditional)}hh2sbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget/translations/zh_TW/gpu/todomodnameN classnameN refexplicituh1hhh ubh)}(hhh]hItalian}hhFsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget/translations/it_IT/gpu/todomodnameN classnameN refexplicituh1hhh ubh)}(hhh]hJapanese}hhZsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget/translations/ja_JP/gpu/todomodnameN classnameN refexplicituh1hhh ubh)}(hhh]hKorean}hhnsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget/translations/ko_KR/gpu/todomodnameN classnameN refexplicituh1hhh ubh)}(hhh]hSpanish}hhsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget/translations/sp_SP/gpu/todomodnameN classnameN refexplicituh1hhh ubeh}(h]h ]h"]h$]h&]current_languageEnglishuh1h hh _documenthsourceNlineNubhtarget)}(h .. _todo:h]h}(h]h ]h"]h$]h&]refidtodouh1hhKhhhhh6/var/lib/git/docbuild/linux/Documentation/gpu/todo.rstubhsection)}(hhh](htitle)}(h TODO listh]h TODO list}(hhhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhhhhhKubh paragraph)}(hThis section contains a list of smaller janitorial tasks in the kernel DRM graphics subsystem useful as newbie projects. Or for slow rainy days.h]hThis section contains a list of smaller janitorial tasks in the kernel DRM graphics subsystem useful as newbie projects. Or for slow rainy days.}(hhhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhhhhubh)}(hhh](h)}(h Difficultyh]h Difficulty}(hhhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhhhhhK ubh)}(h=To make it easier task are categorized into different levels:h]h=To make it easier task are categorized into different levels:}(hhhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK hhhhubh)}(h:Starter: Good tasks to get started with the DRM subsystem.h]h:Starter: Good tasks to get started with the DRM subsystem.}(hhhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhhhhubh)}(hIntermediate: 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.h]hIntermediate: 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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhhhhubh)}(hAdvanced: Tricky tasks that need fairly good understanding of the DRM subsystem and graphics topics. Generally need the relevant hardware for development and testing.h]hAdvanced: Tricky tasks that need fairly good understanding of the DRM subsystem and graphics topics. Generally need the relevant hardware for development and testing.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhhhhubh)}(hExpert: Only attempt these if you've successfully completed some tricky refactorings already and are an expert in the specific areah]hExpert: Only attempt these if you’ve successfully completed some tricky refactorings already and are an expert in the specific area}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhhhhubh)}(hhh]h)}(hSubsystem-wide refactoringsh]hSubsystem-wide refactorings}(hj/hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj,hhhhhKubah}(h]subsystem-wide-refactoringsah ]h"]subsystem-wide refactoringsah$]h&]uh1hhhhhhhhKubeh}(h] difficultyah ]h"] difficultyah$]h&]uh1hhhhhhhhK ubh)}(hhh](h)}(h-Remove custom dumb_map_offset implementationsh]h-Remove custom dumb_map_offset implementations}(hjPhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjMhhhhhK!ubh)}(hAll 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.h]hAll 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.}(hj^hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK#hjMhhubh)}(h5Contact: Simona Vetter, respective driver maintainersh]h5Contact: Simona Vetter, respective driver maintainers}(hjlhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK(hjMhhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hjzhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK*hjMhhubeh}(h]-remove-custom-dumb-map-offset-implementationsah ]h"]-remove custom dumb_map_offset implementationsah$]h&]uh1hhhhhhhhK!ubh)}(hhh](h)}(h2Convert existing KMS drivers to atomic modesettingh]h2Convert existing KMS drivers to atomic modesetting}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhK-ubh)}(h3.19 has the atomic modeset interfaces and helpers, so drivers can now be converted over. Modern compositors like Wayland or Surfaceflinger on Android really want an atomic modeset interface, so this is all about the bright future.h]h3.19 has the atomic modeset interfaces and helpers, so drivers can now be converted over. Modern compositors like Wayland or Surfaceflinger on Android really want an atomic modeset interface, so this is all about the bright future.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK/hjhhubh)}(hThere is a conversion guide for atomic [1]_ and all you need is a GPU for a non-converted driver. The "Atomic mode setting design overview" series [2]_ [3]_ at LWN.net can also be helpful.h](h'There is a conversion guide for atomic }(hjhhhNhNubhfootnote_reference)}(h[1]_h]h1}(hjhhhNhNubah}(h]id1ah ]h"]h$]h&]hid4docnamegpu/todouh1jhjresolvedKubhm and all you need is a GPU for a non-converted driver. The “Atomic mode setting design overview” series }(hjhhhNhNubj)}(h[2]_h]h2}(hjhhhNhNubah}(h]id2ah ]h"]h$]h&]hid5jjuh1jhjjKubh }(hjhhhNhNubj)}(h[3]_h]h3}(hjhhhNhNubah}(h]id3ah ]h"]h$]h&]hid6jjuh1jhjjKubh at LWN.net can also be helpful.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhK4hjhhubh)}(hAs part of this drivers also need to convert to universal plane (which means exposing primary & cursor as proper plane objects). But that's much easier to do by directly using the new atomic helper driver callbacks.h]hAs part of this drivers also need to convert to universal plane (which means exposing primary & cursor as proper plane objects). But that’s much easier to do by directly using the new atomic helper driver callbacks.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK8hjhhubh block_quote)}(h.. [1] https://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html .. [2] https://lwn.net/Articles/653071/ .. [3] https://lwn.net/Articles/653466/ h](hfootnote)}(hIhttps://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.htmlh](hlabel)}(h1h]h1}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhjubh)}(hjh]h reference)}(hjh]hIhttps://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html}(hj-hhhNhNubah}(h]h ]h"]h$]h&]refurijuh1j+hj(ubah}(h]h ]h"]h$]h&]uh1hhhhKhjxubeh}(h]jah ]h"]3ah$]h&]jajjuh1jhhhK>hjjKubeh}(h]h ]h"]h$]h&]uh1j hhhKatomic_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. h]h)}(hXgdrm_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.h]hXgdrm_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.}(hj@hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKXhj<ubah}(h]h ]h"]h$]h&]uh1j:hj7hhhhhNubj;)}(hQOnce that's done, helpers could stop calling ->atomic_check for disabled planes. h]h)}(hPOnce that's done, helpers could stop calling ->atomic_check for disabled planes.h]hROnce that’s done, helpers could stop calling ->atomic_check for disabled planes.}(hjXhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK^hjTubah}(h]h ]h"]h$]h&]uh1j:hj7hhhhhNubj;)}(hThen we could go through all the drivers and remove the more-or-less confused checks for plane_state->fb and plane_state->crtc. h]h)}(hThen we could go through all the drivers and remove the more-or-less confused checks for plane_state->fb and plane_state->crtc.h]hThen we could go through all the drivers and remove the more-or-less confused checks for plane_state->fb and plane_state->crtc.}(hjphhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKahjlubah}(h]h ]h"]h$]h&]uh1j:hj7hhhhhNubeh}(h]h ]h"]h$]h&]bullet-uh1j5hhhKXhjhhubh)}(hContact: Simona Vetterh]hContact: Simona Vetter}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKdhjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKfhjhhubeh}(h]"improve-plane-atomic-check-helpersah ]h"]"improve plane atomic_check helpersah$]h&]uh1hhhhhhhhKSubh)}(hhh](h)}(h4Convert early atomic drivers to async commit helpersh]h4Convert early atomic drivers to async commit helpers}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhKiubh)}(hXFor the first year the atomic modeset helpers didn't support asynchronous / nonblocking commits, and every driver had to hand-roll them. This is fixed now, but there's still a pile of existing drivers that easily could be converted over to the new infrastructure.h]hX For the first year the atomic modeset helpers didn’t support asynchronous / nonblocking commits, and every driver had to hand-roll them. This is fixed now, but there’s still a pile of existing drivers that easily could be converted over to the new infrastructure.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKkhjhhubh)}(hOne issue with the helpers is that they require that drivers handle completion events for atomic commits correctly. But fixing these bugs is good anyway.h]hOne issue with the helpers is that they require that drivers handle completion events for atomic commits correctly. But fixing these bugs is good anyway.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKphjhhubh)}(hSomewhat related is the legacy_cursor_update hack, which should be replaced with the new atomic_async_check/commit functionality in the helpers in drivers that still look at that flag.h]hSomewhat related is the legacy_cursor_update hack, which should be replaced with the new atomic_async_check/commit functionality in the helpers in drivers that still look at that flag.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKshjhhubh)}(h5Contact: Simona Vetter, respective driver maintainersh]h5Contact: Simona Vetter, respective driver maintainers}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKwhjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKyhjhhubeh}(h]4convert-early-atomic-drivers-to-async-commit-helpersah ]h"]4convert early atomic drivers to async commit helpersah$]h&]uh1hhhhhhhhKiubh)}(hhh](h)}(hRename drm_atomic_stateh]hRename drm_atomic_state}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhK|ubh)}(hX:The KMS framework uses two slightly different definitions for the ``state`` concept. For a given object (plane, CRTC, encoder, etc., so ``drm_$OBJECT_state``), the state is the entire state of that object. However, at the device level, ``drm_atomic_state`` refers to a state update for a limited number of objects.h](hBThe KMS framework uses two slightly different definitions for the }(hj hhhNhNubhliteral)}(h ``state``h]hstate}(hj*hhhNhNubah}(h]h ]h"]h$]h&]uh1j(hj ubh= concept. For a given object (plane, CRTC, encoder, etc., so }(hj hhhNhNubj))}(h``drm_$OBJECT_state``h]hdrm_$OBJECT_state}(hj<hhhNhNubah}(h]h ]h"]h$]h&]uh1j(hj ubhO), the state is the entire state of that object. However, at the device level, }(hj hhhNhNubj))}(h``drm_atomic_state``h]hdrm_atomic_state}(hjNhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hj ubh: refers to a state update for a limited number of objects.}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhK~hjhhubh)}(hThe state isn't the entire device state, but only the full state of some objects in that device. This is confusing to newcomers, and ``drm_atomic_state`` should be renamed to something clearer like ``drm_atomic_commit``.h](hThe state isn’t the entire device state, but only the full state of some objects in that device. This is confusing to newcomers, and }(hjfhhhNhNubj))}(h``drm_atomic_state``h]hdrm_atomic_state}(hjnhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjfubh- should be renamed to something clearer like }(hjfhhhNhNubj))}(h``drm_atomic_commit``h]hdrm_atomic_commit}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjfubh.}(hjfhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhjhhubh)}(hIn addition to renaming the structure itself, it would also imply renaming some related functions (``drm_atomic_state_alloc``, ``drm_atomic_state_get``, ``drm_atomic_state_put``, ``drm_atomic_state_init``, ``__drm_atomic_state_free``, etc.).h](hcIn addition to renaming the structure itself, it would also imply renaming some related functions (}(hjhhhNhNubj))}(h``drm_atomic_state_alloc``h]hdrm_atomic_state_alloc}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjubh, }(hjhhhNhNubj))}(h``drm_atomic_state_get``h]hdrm_atomic_state_get}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjubh, }(hjhhhNhNubj))}(h``drm_atomic_state_put``h]hdrm_atomic_state_put}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjubh, }hjsbj))}(h``drm_atomic_state_init``h]hdrm_atomic_state_init}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjubh, }hjsbj))}(h``__drm_atomic_state_free``h]h__drm_atomic_state_free}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjubh, etc.).}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhjhhubh)}(h+Contact: Maxime Ripard h](hContact: Maxime Ripard <}(hjhhhNhNubj,)}(hmripard@kernel.orgh]hmripard@kernel.org}(hjhhhNhNubah}(h]h ]h"]h$]h&]refurimailto:mripard@kernel.orguh1j+hjubh>}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hj"hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjhhubeh}(h]rename-drm-atomic-stateah ]h"]rename drm_atomic_stateah$]h&]uh1hhhhhhhhK|ubh)}(hhh](h)}(hFallout from atomic KMSh]hFallout from atomic KMS}(hj;hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj8hhhhhKubh)}(hXL``drm_atomic_helper.c`` provides a batch of functions which implement legacy IOCTLs on top of the new atomic driver interface. Which is really nice for gradual conversion of drivers, but unfortunately the semantic mismatches are a bit too severe. So there's some follow-up work to adjust the function interfaces to fix these issues:h](j))}(h``drm_atomic_helper.c``h]hdrm_atomic_helper.c}(hjMhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjIubhX7 provides a batch of functions which implement legacy IOCTLs on top of the new atomic driver interface. Which is really nice for gradual conversion of drivers, but unfortunately the semantic mismatches are a bit too severe. So there’s some follow-up work to adjust the function interfaces to fix these issues:}(hjIhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhj8hhubj6)}(hhh](j;)}(hXatomic needs the lock acquire context. At the moment that's passed around implicitly with some horrible hacks, and it's also allocate with ``GFP_NOFAIL`` behind the scenes. All legacy paths need to start allocating 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. This task should be finished by adding WARN_ON(!drm_drv_uses_atomic_modeset) in drm_modeset_lock_all(). h](h)}(hXfatomic needs the lock acquire context. At the moment that's passed around implicitly with some horrible hacks, and it's also allocate with ``GFP_NOFAIL`` behind the scenes. All legacy paths need to start allocating 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.h](hatomic needs the lock acquire context. At the moment that’s passed around implicitly with some horrible hacks, and it’s also allocate with }(hjlhhhNhNubj))}(h``GFP_NOFAIL``h]h GFP_NOFAIL}(hjthhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjlubh behind the scenes. All legacy paths need to start allocating 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.}(hjlhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhjhubh)}(hExcept 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().h]hExcept 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().}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjhubeh}(h]h ]h"]h$]h&]uh1j:hjehhhhhNubj;)}(hXA 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 implement the userspace ABI. And then there's the optional hooks for the helper libraries (name ``drm_foo_helper_funcs``), which are purely for internal use. Some of these hooks should be move from ``_funcs`` to ``_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``. h]h)}(hXA 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 implement the userspace ABI. And then there's the optional hooks for the helper libraries (name ``drm_foo_helper_funcs``), which are purely for internal use. Some of these hooks should be move from ``_funcs`` to ``_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``.h](hiA bunch of the vtable hooks are now in the wrong place: DRM has a split between core vfunc tables (named }(hjhhhNhNubj))}(h``drm_foo_funcs``h]h drm_foo_funcs}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjubhw), which are used to implement the userspace ABI. And then there’s the optional hooks for the helper libraries (name }(hjhhhNhNubj))}(h``drm_foo_helper_funcs``h]hdrm_foo_helper_funcs}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjubhN), which are purely for internal use. Some of these hooks should be move from }(hjhhhNhNubj))}(h ``_funcs``h]h_funcs}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjubh to }(hjhhhNhNubj))}(h``_helper_funcs``h]h _helper_funcs}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjubh6 since they are not part of the core ABI. There’s a }(hjhhhNhNubj))}(h ``FIXME``h]hFIXME}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjubh0 comment in the kerneldoc for each such case in }(hjhhhNhNubj))}(h``drm_crtc.h``h]h drm_crtc.h}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjubh.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhjubah}(h]h ]h"]h$]h&]uh1j:hjehhhhhNubeh}(h]h ]h"]h$]h&]j*uh1j5hhhKhj8hhubh)}(hContact: Simona Vetterh]hContact: Simona Vetter}(hj+hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj8hhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hj9hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj8hhubeh}(h]fallout-from-atomic-kmsah ]h"]fallout from atomic kmsah$]h&]uh1hhhhhhhhKubh)}(hhh](h)}(h-Get rid of dev->struct_mutex from GEM driversh]h-Get rid of dev->struct_mutex from GEM drivers}(hjRhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjOhhhhhKubh)}(hXR``dev->struct_mutex`` is the Big DRM Lock from legacy days and infested everything. Nowadays in modern drivers the only bit where it's mandatory is serializing GEM buffer object destruction. Which unfortunately means drivers have to keep track of that lock and either call ``unreference`` or ``unreference_locked`` depending upon context.h](j))}(h``dev->struct_mutex``h]hdev->struct_mutex}(hjdhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hj`ubh is the Big DRM Lock from legacy days and infested everything. Nowadays in modern drivers the only bit where it’s mandatory is serializing GEM buffer object destruction. Which unfortunately means drivers have to keep track of that lock and either call }(hj`hhhNhNubj))}(h``unreference``h]h unreference}(hjvhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hj`ubh or }(hj`hhhNhNubj))}(h``unreference_locked``h]hunreference_locked}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hj`ubh depending upon context.}(hj`hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhjOhhubh)}(hCore GEM doesn't have a need for ``struct_mutex`` any more since kernel 4.8, and there's a GEM object ``free`` callback for any drivers which are entirely ``struct_mutex`` free.h](h#Core GEM doesn’t have a need for }(hjhhhNhNubj))}(h``struct_mutex``h]h struct_mutex}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjubh7 any more since kernel 4.8, and there’s a GEM object }(hjhhhNhNubj))}(h``free``h]hfree}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjubh- callback for any drivers which are entirely }(hjhhhNhNubj))}(h``struct_mutex``h]h struct_mutex}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjubh free.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhjOhhubh)}(hXFor drivers that need ``struct_mutex`` it should be replaced with a driver- private lock. The tricky part is the BO free functions, since those can't 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 only the ``msm`` and `i915` drivers use ``struct_mutex``.h](hFor drivers that need }(hjhhhNhNubj))}(h``struct_mutex``h]h struct_mutex}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjubhX it should be replaced with a driver- private lock. The tricky part is the BO free functions, since those can’t 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 only the }(hjhhhNhNubj))}(h``msm``h]hmsm}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjubh and }(hjhhhNhNubhtitle_reference)}(h`i915`h]hi915}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhjubh drivers use }(hjhhhNhNubj))}(h``struct_mutex``h]h struct_mutex}(hj$hhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjubh.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhjOhhubh)}(h5Contact: Simona Vetter, respective driver maintainersh]h5Contact: Simona Vetter, respective driver maintainers}(hj<hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjOhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjJhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjOhhubeh}(h],get-rid-of-dev-struct-mutex-from-gem-driversah ]h"]-get rid of dev->struct_mutex from gem driversah$]h&]uh1hhhhhhhhKubh)}(hhh](h)}(h-Move Buffer Object Locking to dma_resv_lock()h]h-Move Buffer Object Locking to dma_resv_lock()}(hjchhhNhNubah}(h]h ]h"]h$]h&]uh1hhj`hhhhhKubh)}(hMany drivers have their own per-object locking scheme, usually using mutex_lock(). This causes all kinds of trouble for buffer sharing, since depending which driver is the exporter and importer, the locking hierarchy is reversed.h]hMany drivers have their own per-object locking scheme, usually using mutex_lock(). This causes all kinds of trouble for buffer sharing, since depending which driver is the exporter and importer, the locking hierarchy is reversed.}(hjqhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj`hhubh)}(hXFTo solve this we need one standard per-object locking mechanism, which is dma_resv_lock(). This lock needs to be called as the outermost lock, with all other driver specific per-object locks removed. The problem is that rolling out the actual change to the locking contract is a flag day, due to struct dma_buf buffer sharing.h]hXFTo solve this we need one standard per-object locking mechanism, which is dma_resv_lock(). This lock needs to be called as the outermost lock, with all other driver specific per-object locks removed. The problem is that rolling out the actual change to the locking contract is a flag day, due to struct dma_buf buffer sharing.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj`hhubh)}(h Level: Experth]h Level: Expert}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj`hhubeh}(h]+move-buffer-object-locking-to-dma-resv-lockah ]h"]-move buffer object locking to dma_resv_lock()ah$]h&]uh1hhhhhhhhKubh)}(hhh](h)}(h, Simona Vetterh](hContact: Thomas Zimmermann <}(hjVhhhNhNubj,)}(htzimmermann@suse.deh]htzimmermann@suse.de}(hj^hhhNhNubah}(h]h ]h"]h$]h&]refurimailto:tzimmermann@suse.deuh1j+hjVubh>, Simona Vetter}(hjVhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhj7hhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjxhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj7hhubeh}(h]7reimplement-functions-in-drm-fbdev-fb-ops-without-fbdevah ]h"]7reimplement functions in drm_fbdev_fb_ops without fbdevah$]h&]uh1hhhhhhhhKubh)}(hhh](h)}(h>Benchmark and optimize blitting and format-conversion functionh]h>Benchmark and optimize blitting and format-conversion function}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubh)}(hPDrawing to display memory quickly is crucial for many applications' performance.h]hRDrawing to display memory quickly is crucial for many applications’ performance.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hXOn at least x86-64, sys_imageblit() is significantly slower than cfb_imageblit(), even though both use the same blitting algorithm and the latter is written for I/O memory. It turns out that cfb_imageblit() uses movl instructions, while sys_imageblit apparently does not. This seems to be a problem with gcc's optimizer. DRM's format-conversion helpers might be subject to similar issues.h]hXOn at least x86-64, sys_imageblit() is significantly slower than cfb_imageblit(), even though both use the same blitting algorithm and the latter is written for I/O memory. It turns out that cfb_imageblit() uses movl instructions, while sys_imageblit apparently does not. This seems to be a problem with gcc’s optimizer. DRM’s format-conversion helpers might be subject to similar issues.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hX6Benchmark and optimize fbdev's sys_() helpers and DRM's format-conversion helpers. In cases that can be further optimized, maybe implement a different algorithm. For micro-optimizations, use movl/movq instructions explicitly. That might possibly require architecture-specific helpers (e.g., storel() storeq()).h]hX:Benchmark and optimize fbdev’s sys_() helpers and DRM’s format-conversion helpers. In cases that can be further optimized, maybe implement a different algorithm. For micro-optimizations, use movl/movq instructions explicitly. That might possibly require architecture-specific helpers (e.g., storel() storeq()).}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(h0Contact: Thomas Zimmermann h](hContact: Thomas Zimmermann <}(hjhhhNhNubj,)}(htzimmermann@suse.deh]htzimmermann@suse.de}(hjhhhNhNubah}(h]h ]h"]h$]h&]refurimailto:tzimmermann@suse.deuh1j+hjubh>}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubeh}(h]>benchmark-and-optimize-blitting-and-format-conversion-functionah ]h"]>benchmark and optimize blitting and format-conversion functionah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(hAdrm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanuph]hAdrm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhMubh)}(h_A lot more drivers could be switched over to the drm_gem_framebuffer helpers. Various hold-ups:h]h_A lot more drivers could be switched over to the drm_gem_framebuffer helpers. Various hold-ups:}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubj6)}(hhh](j;)}(hiNeed to switch over to the generic dirty tracking code using drm_atomic_helper_dirtyfb first (e.g. qxl). h]h)}(hhNeed to switch over to the generic dirty tracking code using drm_atomic_helper_dirtyfb first (e.g. qxl).h]hhNeed to switch over to the generic dirty tracking code using drm_atomic_helper_dirtyfb first (e.g. qxl).}(hj' hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj# ubah}(h]h ]h"]h$]h&]uh1j:hj hhhhhNubj;)}(hkNeed to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb setup code can't be deleted. h]h)}(hjNeed to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb setup code can't be deleted.h]hlNeed to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb setup code can’t be deleted.}(hj? hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM"hj; ubah}(h]h ]h"]h$]h&]uh1j:hj hhhhhNubj;)}(hoNeed to switch to drm_gem_fb_create(), as now drm_gem_fb_create() checks for valid formats for atomic drivers. h]h)}(hnNeed to switch to drm_gem_fb_create(), as now drm_gem_fb_create() checks for valid formats for atomic drivers.h]hnNeed to switch to drm_gem_fb_create(), as now drm_gem_fb_create() checks for valid formats for atomic drivers.}(hjW hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM%hjS ubah}(h]h ]h"]h$]h&]uh1j:hj hhhhhNubj;)}(hMany 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. h]h)}(hMany 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.h]hMany 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.}(hjo hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM(hjk ubah}(h]h ]h"]h$]h&]uh1j:hj hhhhhNubeh}(h]h ]h"]h$]h&]jjuh1j5hhhMhj hhubh)}(hContact: Simona Vetterh]hContact: Simona Vetter}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM,hj hhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM.hj hhubeh}(h]Adrm-framebuffer-funcs-and-drm-mode-config-funcs-fb-create-cleanupah ]h"]Adrm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanupah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(hGeneric fbdev defio supporth]hGeneric fbdev defio support}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhM1ubh)}(hXrThe 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.h]hXrThe 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.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM3hj hhubh)}(hPossible 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:h]hPossible 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:}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM9hj hhubj6)}(hhh](j;)}(hIn 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); h](h)}(h~In the drm_fbdev_fb_mmap helper, if we need defio, change the default page prots to write-protected with something like this::h]h}In the drm_fbdev_fb_mmap helper, if we need defio, change the default page prots to write-protected with something like this:}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM=hj ubh literal_block)}(h8vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot);h]h8vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot);}hj sbah}(h]h ]h"]h$]h&] xml:spacepreserveuh1j hhhM@hj ubeh}(h]h ]h"]h$]h&]uh1j:hj hhhhhNubj;)}(hXSet 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. h]h)}(hXSet 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.h]hXSet 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.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMBhj ubah}(h]h ]h"]h$]h&]uh1j:hj hhhhhNubj;)}(h|Track the dirty pages in a separate structure (bitfield with one bit per page should work) to avoid clobbering struct page. h]h)}(h{Track the dirty pages in a separate structure (bitfield with one bit per page should work) to avoid clobbering struct page.h]h{Track the dirty pages in a separate structure (bitfield with one bit per page should work) to avoid clobbering struct page.}(hj# hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMGhj ubah}(h]h ]h"]h$]h&]uh1j:hj hhhhhNubeh}(h]h ]h"]h$]h&]jjuh1j5hhhM=hj hhubh)}(h7Might be good to also have some igt testcases for this.h]h7Might be good to also have some igt testcases for this.}(hj= hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMJhj hhubh)}(h&Contact: Simona Vetter, Noralf Tronnesh]h&Contact: Simona Vetter, Noralf Tronnes}(hjK hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMLhj hhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjY hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMNhj hhubeh}(h]generic-fbdev-defio-supportah ]h"]generic fbdev defio supportah$]h&]uh1hhhhhhhhM1ubh)}(hhh](h)}(h#connector register/unregister fixesh]h#connector register/unregister fixes}(hjr hhhNhNubah}(h]h ]h"]h$]h&]uh1hhjo hhhhhMQubj6)}(hhh](j;)}(hFor 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. h]h)}(hFor 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.h]hFor 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.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMShj ubah}(h]h ]h"]h$]h&]uh1j:hj hhhhhNubj;)}(hXFor 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. h]h)}(hXFor 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.h]hXFor 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.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMWhj ubah}(h]h ]h"]h$]h&]uh1j:hj hhhhhNubeh}(h]h ]h"]h$]h&]jjuh1j5hhhMShjo hhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM\hjo hhubeh}(h]#connector-register-unregister-fixesah ]h"]#connector register/unregister fixesah$]h&]uh1hhhhhhhhMQubh)}(hhh](h)}(hRemove load/unload callbacksh]hRemove load/unload callbacks}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhM_ubh)}(hThe 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().h]hThe 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().}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMahj hhubj6)}(hhh](j;)}(hRework drivers to no longer use the load/unload callbacks, directly coding the load/unload sequence into the driver's probe function. h]h)}(hRework drivers to no longer use the load/unload callbacks, directly coding the load/unload sequence into the driver's probe function.h]hRework drivers to no longer use the load/unload callbacks, directly coding the load/unload sequence into the driver’s probe function.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMehj ubah}(h]h ]h"]h$]h&]uh1j:hj hhhhhNubj;)}(hBOnce all drivers are converted, remove the load/unload callbacks. h]h)}(hAOnce all drivers are converted, remove the load/unload callbacks.h]hAOnce all drivers are converted, remove the load/unload callbacks.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhhj ubah}(h]h ]h"]h$]h&]uh1j:hj hhhhhNubeh}(h]h ]h"]h$]h&]jjuh1j5hhhMehj hhubh)}(hContact: Simona Vetterh]hContact: Simona Vetter}(hj' hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMjhj hhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hj5 hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMlhj hhubeh}(h]remove-load-unload-callbacksah ]h"]remove load/unload callbacksah$]h&]uh1hhhhhhhhM_ubh)}(hhh](h)}(h?Replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmih]h?Replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi}(hjN hhhNhNubah}(h]h ]h"]h$]h&]uh1hhjK hhhhhMoubh)}(hOnce 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.h]hOnce 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.}(hj\ hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMqhjK hhubh)}(htAudit each individual driver calling drm_detect_hdmi_monitor() and switch to drm_display_info.is_hdmi if applicable.h]htAudit each individual driver calling drm_detect_hdmi_monitor() and switch to drm_display_info.is_hdmi if applicable.}(hjj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMuhjK hhubh)}(h8Contact: Laurent Pinchart, respective driver maintainersh]h8Contact: Laurent Pinchart, respective driver maintainers}(hjx hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMxhjK hhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMzhjK hhubeh}(h]=replace-drm-detect-hdmi-monitor-with-drm-display-info-is-hdmiah ]h"]?replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmiah$]h&]uh1hhhhhhhhMoubh)}(hhh](h)}(h,Consolidate custom driver modeset propertiesh]h,Consolidate custom driver modeset properties}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhM}ubh)}(hBefore 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.h]hBefore 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.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(hXFor this task, we aim to introduce core helpers or reuse the existing ones if available:h]hXFor this task, we aim to introduce core helpers or reuse the existing ones if available:}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(h$A quick, unconfirmed, examples list.h]h$A quick, unconfirmed, examples list.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(hX>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)h]hX>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)}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(hAlready in core: - colorspace (sti) - tv format names, enhancements (gma500, intel) - tv overscan, margins, etc. (gma500, intel) - zorder (omapdrm) - same as zpos (?)h]hAlready in core: - colorspace (sti) - tv format names, enhancements (gma500, intel) - tv overscan, margins, etc. (gma500, intel) - zorder (omapdrm) - same as zpos (?)}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(h4Contact: Emil Velikov, respective driver maintainersh]h4Contact: Emil Velikov, respective driver maintainers}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubeh}(h],consolidate-custom-driver-modeset-propertiesah ]h"],consolidate custom driver modeset propertiesah$]h&]uh1hhhhhhhhM}ubh)}(hhh](h)}(h(Use struct iosys_map throughout codebaseh]h(Use struct iosys_map throughout codebase}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhMubh)}(hPointers to shared device memory are stored in struct iosys_map. Each instance knows whether it refers to system or I/O memory. Most of the DRM-wide interface have been converted to use struct iosys_map, but implementations often still use raw pointers.h]hPointers to shared device memory are stored in struct iosys_map. Each instance knows whether it refers to system or I/O memory. Most of the DRM-wide interface have been converted to use struct iosys_map, but implementations often still use raw pointers.}(hj( hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(h9The task is to use struct iosys_map where it makes sense.h]h9The task is to use struct iosys_map where it makes sense.}(hj6 hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubj6)}(hhh](j;)}(hIMemory managers should use struct iosys_map for dma-buf-imported buffers.h]h)}(hjI h]hIMemory managers should use struct iosys_map for dma-buf-imported buffers.}(hjK hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjG ubah}(h]h ]h"]h$]h&]uh1j:hjD hhhhhNubj;)}(h9TTM might benefit from using struct iosys_map internally.h]h)}(hj` h]h9TTM might benefit from using struct iosys_map internally.}(hjb hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj^ ubah}(h]h ]h"]h$]h&]uh1j:hjD hhhhhNubj;)}(hMFramebuffer copying and blitting helpers should operate on struct iosys_map. h]h)}(hLFramebuffer copying and blitting helpers should operate on struct iosys_map.h]hLFramebuffer copying and blitting helpers should operate on struct iosys_map.}(hjy hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhju ubah}(h]h ]h"]h$]h&]uh1j:hjD hhhhhNubeh}(h]h ]h"]h$]h&]jj*uh1j5hhhMhj hhubh)}(hQContact: Thomas Zimmermann , Christian König, Simona Vetterh](hContact: Thomas Zimmermann <}(hj hhhNhNubj,)}(htzimmermann@suse.deh]htzimmermann@suse.de}(hj hhhNhNubah}(h]h ]h"]h$]h&]refurimailto:tzimmermann@suse.deuh1j+hj ubh">, Christian König, Simona Vetter}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubeh}(h](use-struct-iosys-map-throughout-codebaseah ]h"](use struct iosys_map throughout codebaseah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(hVReview all drivers for setting struct drm_mode_config.{max_width,max_height} correctlyh]hVReview all drivers for setting struct drm_mode_config.{max_width,max_height} correctly}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhMubh)}(hThe values in struct drm_mode_config.{max_width,max_height} describe the maximum supported framebuffer size. It's the virtual screen size, but many drivers treat it like limitations of the physical resolution.h]hThe values in struct drm_mode_config.{max_width,max_height} describe the maximum supported framebuffer size. It’s the virtual screen size, but many drivers treat it like limitations of the physical resolution.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(hThe maximum width depends on the hardware's maximum scanline pitch. The maximum height depends on the amount of addressable video memory. Review all drivers to initialize the fields to the correct values.h]hThe maximum width depends on the hardware’s maximum scanline pitch. The maximum height depends on the amount of addressable video memory. Review all drivers to initialize the fields to the correct values.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(h0Contact: Thomas Zimmermann h](hContact: Thomas Zimmermann <}(hj hhhNhNubj,)}(htzimmermann@suse.deh]htzimmermann@suse.de}(hj hhhNhNubah}(h]h ]h"]h$]h&]refurimailto:tzimmermann@suse.deuh1j+hj ubh>}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubeh}(h]Treview-all-drivers-for-setting-struct-drm-mode-config-max-width-max-height-correctlyah ]h"]Vreview all drivers for setting struct drm_mode_config.{max_width,max_height} correctlyah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(h%Request memory regions in all driversh]h%Request memory regions in all drivers}(hj3 hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj0 hhhhhMubh)}(hGo through all drivers and add code to request the memory regions that the driver uses. This requires adding calls to request_mem_region(), pci_request_region() or similar functions. Use helpers for managed cleanup where possible.h]hGo through all drivers and add code to request the memory regions that the driver uses. This requires adding calls to request_mem_region(), pci_request_region() or similar functions. Use helpers for managed cleanup where possible.}(hjA hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj0 hhubh)}(hDrivers are pretty bad at doing this and there used to be conflicts among DRM and fbdev drivers. Still, it's the correct thing to do.h]hDrivers are pretty bad at doing this and there used to be conflicts among DRM and fbdev drivers. Still, it’s the correct thing to do.}(hjO hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj0 hhubh)}(h0Contact: Thomas Zimmermann h](hContact: Thomas Zimmermann <}(hj] hhhNhNubj,)}(htzimmermann@suse.deh]htzimmermann@suse.de}(hje hhhNhNubah}(h]h ]h"]h$]h&]refurimailto:tzimmermann@suse.deuh1j+hj] ubh>}(hj] hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj0 hhubh)}(hLevel: Starterh]hLevel: Starter}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj0 hhubeh}(h]%request-memory-regions-in-all-driversah ]h"]%request memory regions in all driversah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(h'Remove driver dependencies on FB_DEVICEh]h'Remove driver dependencies on FB_DEVICE}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhMubh)}(hXdA number of fbdev drivers provide attributes via sysfs and therefore depend on CONFIG_FB_DEVICE to be selected. Review each driver and attempt to make any dependencies on CONFIG_FB_DEVICE optional. At the minimum, the respective code in the driver could be conditionalized via ifdef CONFIG_FB_DEVICE. Not all drivers might be able to drop CONFIG_FB_DEVICE.h]hXdA number of fbdev drivers provide attributes via sysfs and therefore depend on CONFIG_FB_DEVICE to be selected. Review each driver and attempt to make any dependencies on CONFIG_FB_DEVICE optional. At the minimum, the respective code in the driver could be conditionalized via ifdef CONFIG_FB_DEVICE. Not all drivers might be able to drop CONFIG_FB_DEVICE.W}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(h0Contact: Thomas Zimmermann h](hContact: Thomas Zimmermann <}(hj hhhNhNubj,)}(htzimmermann@suse.deh]htzimmermann@suse.de}(hj hhhNhNubah}(h]h ]h"]h$]h&]refurimailto:tzimmermann@suse.deuh1j+hj ubh>}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(hLevel: Starterh]hLevel: Starter}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubeh}(h]'remove-driver-dependencies-on-fb-deviceah ]h"]'remove driver dependencies on fb_deviceah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(hIRemove disable/unprepare in remove/shutdown in panel-simple and panel-edph]hIRemove disable/unprepare in remove/shutdown in panel-simple and panel-edp}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhMubh)}(hXAs of commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we have a check in the drm_panel core to make sure nobody double-calls prepare/enable/disable/unprepare. Eventually that should probably be turned into a WARN_ON() or somehow made louder.h]hXAs of commit d2aacaf07395 (“drm/panel: Check for already prepared/enabled in drm_panel”), we have a check in the drm_panel core to make sure nobody double-calls prepare/enable/disable/unprepare. Eventually that should probably be turned into a WARN_ON() or somehow made louder.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(hXAt the moment, we expect that we may still encounter the warnings in the drm_panel core when using panel-simple and panel-edp. Since those panel drivers are used with a lot of different DRM modeset drivers they still make an extra effort to disable/unprepare the panel themsevles at shutdown time. Specifically we could still encounter those warnings if the panel driver gets shutdown() _before_ the DRM modeset driver and the DRM modeset driver properly calls drm_atomic_helper_shutdown() in its own shutdown() callback. Warnings could be avoided in such a case by using something like device links to ensure that the panel gets shutdown() after the DRM modeset driver.h]hXAt the moment, we expect that we may still encounter the warnings in the drm_panel core when using panel-simple and panel-edp. Since those panel drivers are used with a lot of different DRM modeset drivers they still make an extra effort to disable/unprepare the panel themsevles at shutdown time. Specifically we could still encounter those warnings if the panel driver gets shutdown() _before_ the DRM modeset driver and the DRM modeset driver properly calls drm_atomic_helper_shutdown() in its own shutdown() callback. Warnings could be avoided in such a case by using something like device links to ensure that the panel gets shutdown() after the DRM modeset driver.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(hOnce all DRM modeset drivers are known to shutdown properly, the extra calls to disable/unprepare in remove/shutdown in panel-simple and panel-edp should be removed and this TODO item marked complete.h]hOnce all DRM modeset drivers are known to shutdown properly, the extra calls to disable/unprepare in remove/shutdown in panel-simple and panel-edp should be removed and this TODO item marked complete.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(h1Contact: Douglas Anderson h](hContact: Douglas Anderson <}(hj'hhhNhNubj,)}(hdianders@chromium.orgh]hdianders@chromium.org}(hj/hhhNhNubah}(h]h ]h"]h$]h&]refurimailto:dianders@chromium.orguh1j+hj'ubh>}(hj'hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hjIhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubeh}(h]Iremove-disable-unprepare-in-remove-shutdown-in-panel-simple-and-panel-edpah ]h"]Iremove disable/unprepare in remove/shutdown in panel-simple and panel-edpah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(h1Transition away from using mipi_dsi_*_write_seq()h]h1Transition away from using mipi_dsi_*_write_seq()}(hjbhhhNhNubah}(h]h ]h"]h$]h&]uh1hhj_hhhhhMubh)}(hXThe macros mipi_dsi_generic_write_seq() and mipi_dsi_dcs_write_seq() are non-intuitive because, if there are errors, they return out of the *caller's* function. We should move all callers to use mipi_dsi_generic_write_seq_multi() and mipi_dsi_dcs_write_seq_multi() macros instead.h](hThe macros mipi_dsi_generic_write_seq() and mipi_dsi_dcs_write_seq() are non-intuitive because, if there are errors, they return out of the }(hjphhhNhNubhemphasis)}(h *caller's*h]h caller’s}(hjzhhhNhNubah}(h]h ]h"]h$]h&]uh1jxhjpubh function. We should move all callers to use mipi_dsi_generic_write_seq_multi() and mipi_dsi_dcs_write_seq_multi() macros instead.}(hjphhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj_hhubh)}(hXmOnce all callers are transitioned, the macros and the functions that they call, mipi_dsi_generic_write_chatty() and mipi_dsi_dcs_write_buffer_chatty(), can probably be removed. Alternatively, if people feel like the _multi() variants are overkill for some use cases, we could keep the mipi_dsi_*_write_seq() variants but change them not to return out of the caller.h]hXmOnce all callers are transitioned, the macros and the functions that they call, mipi_dsi_generic_write_chatty() and mipi_dsi_dcs_write_buffer_chatty(), can probably be removed. Alternatively, if people feel like the _multi() variants are overkill for some use cases, we could keep the mipi_dsi_*_write_seq() variants but change them not to return out of the caller.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj_hhubh)}(h1Contact: Douglas Anderson h](hContact: Douglas Anderson <}(hjhhhNhNubj,)}(hdianders@chromium.orgh]hdianders@chromium.org}(hjhhhNhNubah}(h]h ]h"]h$]h&]refurimailto:dianders@chromium.orguh1j+hjubh>}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj_hhubh)}(hLevel: Starterh]hLevel: Starter}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj_hhubh)}(hhh]h)}(hCore refactoringsh]hCore refactorings}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubah}(h]core-refactoringsah ]h"]core refactoringsah$]h&]uh1hhj_hhhhhMubeh}(h]-transition-away-from-using-mipi-dsi-write-seqah ]h"]1transition away from using mipi_dsi_*_write_seq()ah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(hMake panic handling workh]hMake panic handling work}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhM ubh)}(hBThis is a really varied tasks with lots of little bits and pieces:h]hBThis is a really varied tasks with lots of little bits and pieces:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM hjhhubj6)}(hhh](j;)}(hXThe panic path can't be tested currently, leading to constant breaking. The main issue here is that panics can be triggered from hardirq contexts and hence all panic related callback can run in hardirq context. It would be awesome if we could test at least the fbdev helper code and driver code by e.g. trigger calls through drm debugfs files. hardirq context could be achieved by using an IPI to the local processor. h]h)}(hXThe panic path can't be tested currently, leading to constant breaking. The main issue here is that panics can be triggered from hardirq contexts and hence all panic related callback can run in hardirq context. It would be awesome if we could test at least the fbdev helper code and driver code by e.g. trigger calls through drm debugfs files. hardirq context could be achieved by using an IPI to the local processor.h]hXThe panic path can’t be tested currently, leading to constant breaking. The main issue here is that panics can be triggered from hardirq contexts and hence all panic related callback can run in hardirq context. It would be awesome if we could test at least the fbdev helper code and driver code by e.g. trigger calls through drm debugfs files. hardirq context could be achieved by using an IPI to the local processor.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1j:hjhhhhhNubj;)}(hXThere's a massive confusion of different panic handlers. DRM fbdev emulation helpers had their own (long removed), but on top of that the fbcon code itself also has one. We need to make sure that they stop fighting over each other. This is worked around by checking ``oops_in_progress`` at various entry points into the DRM fbdev emulation helpers. A much cleaner approach here would be to switch fbcon to the `threaded printk support `_. h]h)}(hXThere's a massive confusion of different panic handlers. DRM fbdev emulation helpers had their own (long removed), but on top of that the fbcon code itself also has one. We need to make sure that they stop fighting over each other. This is worked around by checking ``oops_in_progress`` at various entry points into the DRM fbdev emulation helpers. A much cleaner approach here would be to switch fbcon to the `threaded printk support `_.h](hX There’s a massive confusion of different panic handlers. DRM fbdev emulation helpers had their own (long removed), but on top of that the fbcon code itself also has one. We need to make sure that they stop fighting over each other. This is worked around by checking }(hj/hhhNhNubj))}(h``oops_in_progress``h]hoops_in_progress}(hj7hhhNhNubah}(h]h ]h"]h$]h&]uh1j(hj/ubh| at various entry points into the DRM fbdev emulation helpers. A much cleaner approach here would be to switch fbcon to the }(hj/hhhNhNubj,)}(h=`threaded printk support `_h]hthreaded printk support}(hjIhhhNhNubah}(h]h ]h"]h$]h&]namethreaded printk supportrefuri https://lwn.net/Articles/800946/uh1j+hj/ubh)}(h# h]h}(h]threaded-printk-supportah ]h"]threaded printk supportah$]h&]refurijZuh1h referencedKhj/ubh.}(hj/hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj+ubah}(h]h ]h"]h$]h&]uh1j:hjhhhhhNubj;)}(h``drm_can_sleep()`` is a mess. It hides real bugs in normal operations and isn't a full solution for panic paths. We need to make sure that it only returns true if there's a panic going on for real, and fix up all the fallout. h]h)}(h``drm_can_sleep()`` is a mess. It hides real bugs in normal operations and isn't a full solution for panic paths. We need to make sure that it only returns true if there's a panic going on for real, and fix up all the fallout.h](j))}(h``drm_can_sleep()``h]hdrm_can_sleep()}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hj}ubh is a mess. It hides real bugs in normal operations and isn’t a full solution for panic paths. We need to make sure that it only returns true if there’s a panic going on for real, and fix up all the fallout.}(hj}hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjyubah}(h]h ]h"]h$]h&]uh1j:hjhhhhhNubj;)}(hXThe panic handler must never sleep, which also means it can't ever ``mutex_lock()``. Also it can't grab any other lock unconditionally, not even spinlocks (because NMI and hardirq can panic too). We need to either make sure to not call such paths, or trylock everything. Really tricky. h]h)}(hXThe panic handler must never sleep, which also means it can't ever ``mutex_lock()``. Also it can't grab any other lock unconditionally, not even spinlocks (because NMI and hardirq can panic too). We need to either make sure to not call such paths, or trylock everything. Really tricky.h](hEThe panic handler must never sleep, which also means it can’t ever }(hjhhhNhNubj))}(h``mutex_lock()``h]h mutex_lock()}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hjubh. Also it can’t grab any other lock unconditionally, not even spinlocks (because NMI and hardirq can panic too). We need to either make sure to not call such paths, or trylock everything. Really tricky.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhM"hjubah}(h]h ]h"]h$]h&]uh1j:hjhhhhhNubj;)}(hA clean solution would be an entirely separate panic output support in KMS, bypassing the current fbcon support. See `[PATCH v2 0/3] drm: Add panic handling `_. h]h)}(hA clean solution would be an entirely separate panic output support in KMS, bypassing the current fbcon support. See `[PATCH v2 0/3] drm: Add panic handling `_.h](huA clean solution would be an entirely separate panic output support in KMS, bypassing the current fbcon support. See }(hjhhhNhNubj,)}(hx`[PATCH v2 0/3] drm: Add panic handling `_h]h&[PATCH v2 0/3] drm: Add panic handling}(hjhhhNhNubah}(h]h ]h"]h$]h&]name&[PATCH v2 0/3] drm: Add panic handlingjYLhttps://lore.kernel.org/dri-devel/20190311174218.51899-1-noralf@tronnes.org/uh1j+hjubh)}(hO h]h}(h]#patch-v2-0-3-drm-add-panic-handlingah ]h"]&[patch v2 0/3] drm: add panic handlingah$]h&]refurijuh1hjhKhjubh.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhM'hjubah}(h]h ]h"]h$]h&]uh1j:hjhhhhhNubj;)}(hX<Encoding the actual oops and preceding dmesg in a QR might help with the dread "important stuff scrolled away" problem. See `[RFC][PATCH] Oops messages transfer using QR codes `_ for some example code that could be reused. h]h)}(hX;Encoding the actual oops and preceding dmesg in a QR might help with the dread "important stuff scrolled away" problem. See `[RFC][PATCH] Oops messages transfer using QR codes `_ for some example code that could be reused.h](hEncoding the actual oops and preceding dmesg in a QR might help with the dread “important stuff scrolled away” problem. See }(hjhhhNhNubj,)}(h`[RFC][PATCH] Oops messages transfer using QR codes `_h]h2[RFC][PATCH] Oops messages transfer using QR codes}(hjhhhNhNubah}(h]h ]h"]h$]h&]name2[RFC][PATCH] Oops messages transfer using QR codesjY[https://lore.kernel.org/lkml/1446217392-11981-1-git-send-email-alexandru.murtaza@intel.com/uh1j+hjubh)}(h^ h]h}(h]/rfc-patch-oops-messages-transfer-using-qr-codesah ]h"]2[rfc][patch] oops messages transfer using qr codesah$]h&]refurijuh1hjhKhjubh, for some example code that could be reused.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhM+hjubah}(h]h ]h"]h$]h&]uh1j:hjhhhhhNubeh}(h]h ]h"]h$]h&]jj*uh1j5hhhMhjhhubh)}(hContact: Simona Vetterh]hContact: Simona Vetter}(hjChhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM1hjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjQhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM3hjhhubeh}(h]make-panic-handling-workah ]h"]make panic handling workah$]h&]uh1hhhhhhhhM ubh)}(hhh](h)}(hClean up the debugfs supporth]hClean up the debugfs support}(hjjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjghhhhhM6ubh)}(h"There's a bunch of issues with it:h]h$There’s a bunch of issues with it:}(hjxhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM8hjghhubj6)}(hhh](j;)}(htConvert drivers to support the drm_debugfs_add_files() function instead of the drm_debugfs_create_files() function. h]h)}(hsConvert drivers to support the drm_debugfs_add_files() function instead of the drm_debugfs_create_files() function.h]hsConvert drivers to support the drm_debugfs_add_files() function instead of the drm_debugfs_create_files() function.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM:hjubah}(h]h ]h"]h$]h&]uh1j:hjhhhhhNubj;)}(hImprove late-register debugfs by rolling out the same debugfs pre-register infrastructure for connector and crtc too. That way, the drivers won't need to split their setup code into init and register anymore. h]h)}(hImprove late-register debugfs by rolling out the same debugfs pre-register infrastructure for connector and crtc too. That way, the drivers won't need to split their setup code into init and register anymore.h]hImprove late-register debugfs by rolling out the same debugfs pre-register infrastructure for connector and crtc too. That way, the drivers won’t need to split their setup code into init and register anymore.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM=hjubah}(h]h ]h"]h$]h&]uh1j:hjhhhhhNubj;)}(hX6We probably want to have some support for debugfs files on crtc/connectors and maybe other kms objects directly in core. There's even drm_print support in the funcs for these objects to dump kms state, so it's all there. And then the ->show() functions should obviously give you a pointer to the right object. h]h)}(hX5We probably want to have some support for debugfs files on crtc/connectors and maybe other kms objects directly in core. There's even drm_print support in the funcs for these objects to dump kms state, so it's all there. And then the ->show() functions should obviously give you a pointer to the right object.h]hX9We probably want to have some support for debugfs files on crtc/connectors and maybe other kms objects directly in core. There’s even drm_print support in the funcs for these objects to dump kms state, so it’s all there. And then the ->show() functions should obviously give you a pointer to the right object.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMAhjubah}(h]h ]h"]h$]h&]uh1j:hjhhhhhNubj;)}(hXThe drm_driver->debugfs_init hooks we have is just an artifact of the old midlayered load sequence. DRM debugfs should work more like sysfs, where you can create properties/files for an object anytime you want, and the core takes care of publishing/unpuplishing all the files at register/unregister time. Drivers shouldn't need to worry about these technicalities, and fixing this (together with the drm_minor->drm_device move) would allow us to remove debugfs_init. h]h)}(hXThe drm_driver->debugfs_init hooks we have is just an artifact of the old midlayered load sequence. DRM debugfs should work more like sysfs, where you can create properties/files for an object anytime you want, and the core takes care of publishing/unpuplishing all the files at register/unregister time. Drivers shouldn't need to worry about these technicalities, and fixing this (together with the drm_minor->drm_device move) would allow us to remove debugfs_init.h]hXThe drm_driver->debugfs_init hooks we have is just an artifact of the old midlayered load sequence. DRM debugfs should work more like sysfs, where you can create properties/files for an object anytime you want, and the core takes care of publishing/unpuplishing all the files at register/unregister time. Drivers shouldn’t need to worry about these technicalities, and fixing this (together with the drm_minor->drm_device move) would allow us to remove debugfs_init.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMFhjubah}(h]h ]h"]h$]h&]uh1j:hjhhhhhNubeh}(h]h ]h"]h$]h&]jjuh1j5hhhM:hjghhubh)}(hContact: Simona Vetterh]hContact: Simona Vetter}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMNhjghhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMPhjghhubeh}(h]clean-up-the-debugfs-supportah ]h"]clean up the debugfs supportah$]h&]uh1hhhhhhhhM6ubh)}(hhh](h)}(hObject lifetime fixesh]hObject lifetime fixes}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMSubh)}(hThere's two related issues hereh]h!There’s two related issues here}(hj$hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMUhjhhubj6)}(hhh](j;)}(hVCleanup up the various ->destroy callbacks, which often are all the same simple code. h]h)}(hUCleanup up the various ->destroy callbacks, which often are all the same simple code.h]hUCleanup up the various ->destroy callbacks, which often are all the same simple code.}(hj9hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMWhj5ubah}(h]h ]h"]h$]h&]uh1j:hj2hhhhhNubj;)}(hLots of drivers erroneously allocate DRM modeset objects using devm_kzalloc, which results in use-after free issues on driver unload. This can be serious trouble even for drivers for hardware integrated on the SoC due to EPROBE_DEFERRED backoff. h]h)}(hLots of drivers erroneously allocate DRM modeset objects using devm_kzalloc, which results in use-after free issues on driver unload. This can be serious trouble even for drivers for hardware integrated on the SoC due to EPROBE_DEFERRED backoff.h]hLots of drivers erroneously allocate DRM modeset objects using devm_kzalloc, which results in use-after free issues on driver unload. This can be serious trouble even for drivers for hardware integrated on the SoC due to EPROBE_DEFERRED backoff.}(hjQhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMZhjMubah}(h]h ]h"]h$]h&]uh1j:hj2hhhhhNubeh}(h]h ]h"]h$]h&]jjuh1j5hhhMWhjhhubh)}(hBoth these problems can be solved by switching over to drmm_kzalloc(), and the various convenience wrappers provided, e.g. drmm_crtc_alloc_with_planes(), drmm_universal_plane_alloc(), ... and so on.h]hBoth these problems can be solved by switching over to drmm_kzalloc(), and the various convenience wrappers provided, e.g. drmm_crtc_alloc_with_planes(), drmm_universal_plane_alloc(), ... and so on.}(hjkhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM_hjhhubh)}(hContact: Simona Vetterh]hContact: Simona Vetter}(hjyhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMchjhhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMehjhhubeh}(h]object-lifetime-fixesah ]h"]object lifetime fixesah$]h&]uh1hhhhhhhhMSubh)}(hhh](h)}(h4Remove automatic page mapping from dma-buf importingh]h4Remove automatic page mapping from dma-buf importing}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMhubh)}(hXWhen 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.h]hXWhen 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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMjhjhhubh)}(hX{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.h]hX{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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMqhjhhubh)}(h?Contact: Thomas Zimmermann , Simona Vetterh](hContact: Thomas Zimmermann <}(hjhhhNhNubj,)}(htzimmermann@suse.deh]htzimmermann@suse.de}(hjhhhNhNubah}(h]h ]h"]h$]h&]refurimailto:tzimmermann@suse.deuh1j+hjubh>, Simona Vetter}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMwhjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMyhjhhubh)}(hhh]h)}(hBetter Testingh]hBetter Testing}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhM}ubah}(h]better-testingah ]h"]better testingah$]h&]uh1hhjhhhhhM}ubeh}(h]4remove-automatic-page-mapping-from-dma-buf-importingah ]h"]4remove automatic page mapping from dma-buf importingah$]h&]uh1hhhhhhhhMhubh)}(hhh](h)}(h>Add unit tests using the Kernel Unit Testing (KUnit) frameworkh]h>Add unit tests using the Kernel Unit Testing (KUnit) framework}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubh)}(hThe `KUnit `_ provides a common framework for unit tests within the Linux kernel. Having a test suite would allow to identify regressions earlier.h](hThe }(hj,hhhNhNubj,)}(hL`KUnit `_h]hKUnit}(hj4hhhNhNubah}(h]h ]h"]h$]h&]nameKUnitjYAhttps://www.kernel.org/doc/html/latest/dev-tools/kunit/index.htmluh1j+hj,ubh)}(hD h]h}(h]kunitah ]h"]kunitah$]h&]refurijDuh1hjhKhj,ubh provides a common framework for unit tests within the Linux kernel. Having a test suite would allow to identify regressions earlier.}(hj,hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hgA good candidate for the first unit tests are the format-conversion helpers in ``drm_format_helper.c``.h](hOA good candidate for the first unit tests are the format-conversion helpers in }(hj\hhhNhNubj))}(h``drm_format_helper.c``h]hdrm_format_helper.c}(hjdhhhNhNubah}(h]h ]h"]h$]h&]uh1j(hj\ubh.}(hj\hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(h6Contact: Javier Martinez Canillas h](h#Contact: Javier Martinez Canillas <}(hj|hhhNhNubj,)}(hjavierm@redhat.comh]hjavierm@redhat.com}(hjhhhNhNubah}(h]h ]h"]h$]h&]refurimailto:javierm@redhat.comuh1j+hj|ubh>}(hj|hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubeh}(h]add unit tests using the kernel unit testing (kunit) frameworkah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(h-Clean up and document former selftests suitesh]h-Clean up and document former selftests suites}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubh)}(hSome KUnit test suites (drm_buddy, drm_cmdline_parser, drm_damage_helper, drm_format, drm_framebuffer, drm_dp_mst_helper, drm_mm, drm_plane_helper and drm_rect) are former selftests suites that have been converted over when KUnit was first introduced.h]hSome KUnit test suites (drm_buddy, drm_cmdline_parser, drm_damage_helper, drm_format, drm_framebuffer, drm_dp_mst_helper, drm_mm, drm_plane_helper and drm_rect) are former selftests suites that have been converted over when KUnit was first introduced.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hX These suites were fairly undocumented, and with different goals than what unit tests can be. Trying to identify what each test in these suites actually test for, whether that makes sense for a unit test, and either remove it if it doesn't or document it if it does would be of great help.h]hX"These suites were fairly undocumented, and with different goals than what unit tests can be. Trying to identify what each test in these suites actually test for, whether that makes sense for a unit test, and either remove it if it doesn’t or document it if it does would be of great help.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(h+Contact: Maxime Ripard h](hContact: Maxime Ripard <}(hjhhhNhNubj,)}(hmripard@kernel.orgh]hmripard@kernel.org}(hjhhhNhNubah}(h]h ]h"]h$]h&]refurimailto:mripard@kernel.orguh1j+hjubh>}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubeh}(h]-clean-up-and-document-former-selftests-suitesah ]h"]-clean up and document former selftests suitesah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(hEnable trinity for DRMh]hEnable trinity for DRM}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubh)}(h8And fix up the fallout. Should be really interesting ...h]h8And fix up the fallout. Should be really interesting ...}(hj*hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hj8hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubeh}(h]enable-trinity-for-drmah ]h"]enable trinity for drmah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(hMake KMS tests in i-g-t generich]hMake KMS tests in i-g-t generic}(hjQhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjNhhhhhMubh)}(hXThe i915 driver team maintains an extensive testsuite for the i915 DRM driver, including tons of testcases for corner-cases in the modesetting API. It would be awesome if those tests (at least the ones not relying on Intel-specific GEM features) could be made to run on any KMS driver.h]hXThe i915 driver team maintains an extensive testsuite for the i915 DRM driver, including tons of testcases for corner-cases in the modesetting API. It would be awesome if those tests (at least the ones not relying on Intel-specific GEM features) could be made to run on any KMS driver.}(hj_hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjNhhubh)}(hXBasic work to run i-g-t tests on non-i915 is done, what's now missing is mass- converting things over. For modeset tests we also first need a bit of infrastructure to use dumb buffers for untiled buffers, to be able to run all the non-i915 specific modeset tests.h]hX Basic work to run i-g-t tests on non-i915 is done, what’s now missing is mass- converting things over. For modeset tests we also first need a bit of infrastructure to use dumb buffers for untiled buffers, to be able to run all the non-i915 specific modeset tests.}(hjmhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjNhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hj{hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjNhhubeh}(h]make-kms-tests-in-i-g-t-genericah ]h"]make kms tests in i-g-t genericah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(h!Extend virtual test driver (VKMS)h]h!Extend virtual test driver (VKMS)}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubh)}(hSee the documentation of :ref:`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.h](hSee the documentation of }(hjhhhNhNubh)}(h:ref:`VKMS `h]hinline)}(hjh]hVKMS}(hjhhhNhNubah}(h]h ](xrefstdstd-refeh"]h$]h&]uh1jhjubah}(h]h ]h"]h$]h&]refdocj refdomainjreftyperef refexplicitrefwarn reftargetvkmsuh1hhhhMhjubh 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.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hLevel: See detailsh]hLevel: See details}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubeh}(h]extend-virtual-test-driver-vkmsah ]h"]!extend virtual test driver (vkms)ah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(hBacklight Refactoringh]hBacklight Refactoring}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubh)}(h`Backlight drivers have a triple enable/disable state, which is a bit overkill. Plan to fix this:h]h`Backlight drivers have a triple enable/disable state, which is a bit overkill. Plan to fix this:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubhenumerated_list)}(hhh](j;)}(haRoll out backlight_enable() and backlight_disable() helpers everywhere. This has started already.h]h)}(haRoll out backlight_enable() and backlight_disable() helpers everywhere. This has started already.h]haRoll out backlight_enable() and backlight_disable() helpers everywhere. This has started already.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1j:hjhhhhhNubj;)}(hKIn all, only look at one of the three status bits set by the above helpers.h]h)}(hj,h]hKIn all, only look at one of the three status bits set by the above helpers.}(hj.hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj*ubah}(h]h ]h"]h$]h&]uh1j:hjhhhhhNubj;)}(h"Remove the other two status bits. h]h)}(h!Remove the other two status bits.h]h!Remove the other two status bits.}(hjEhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjAubah}(h]h ]h"]h$]h&]uh1j:hjhhhhhNubeh}(h]h ]h"]h$]h&]enumtypearabicprefixhsuffix.uh1j hjhhhhhMubh)}(hContact: Simona Vetterh]hContact: Simona Vetter}(hjdhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hjrhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hhh]h)}(hDriver Specifich]hDriver Specific}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubah}(h]driver-specificah ]h"]driver specificah$]h&]uh1hhjhhhhhMubeh}(h]backlight-refactoringah ]h"]backlight refactoringah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(hAMD DC Display Driverh]hAMD DC Display Driver}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubh)}(hAMD DC is the display driver for AMD devices starting with Vega. There has been a bunch of progress cleaning it up but there's still plenty of work to be done.h]hAMD DC is the display driver for AMD devices starting with Vega. There has been a bunch of progress cleaning it up but there’s still plenty of work to be done.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(h/See drivers/gpu/drm/amd/display/TODO for tasks.h]h/See drivers/gpu/drm/amd/display/TODO for tasks.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(h%Contact: Harry Wentland, Alex Deucherh]h%Contact: Harry Wentland, Alex Deucher}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hhh](h)}(h Bootsplashh]h Bootsplash}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubh)}(hThere 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.h]hThere 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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubj6)}(hhh](j;)}(hb[v6,8/8] drm/client: Hack: Add bootsplash example https://patchwork.freedesktop.org/patch/306579/ h]h)}(ha[v6,8/8] drm/client: Hack: Add bootsplash example https://patchwork.freedesktop.org/patch/306579/h](h2[v6,8/8] drm/client: Hack: Add bootsplash example }(hjhhhNhNubj,)}(h/https://patchwork.freedesktop.org/patch/306579/h]h/https://patchwork.freedesktop.org/patch/306579/}(hj hhhNhNubah}(h]h ]h"]h$]h&]refurij uh1j+hjubeh}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1j:hjhhhhhNubj;)}(hm[RFC PATCH v2 00/13] Kernel based bootsplash https://lore.kernel.org/r/20171213194755.3409-1-mstaudt@suse.de h]h)}(hl[RFC PATCH v2 00/13] Kernel based bootsplash https://lore.kernel.org/r/20171213194755.3409-1-mstaudt@suse.deh](h-[RFC PATCH v2 00/13] Kernel based bootsplash }(hj)hhhNhNubj,)}(h?https://lore.kernel.org/r/20171213194755.3409-1-mstaudt@suse.deh]h?https://lore.kernel.org/r/20171213194755.3409-1-mstaudt@suse.de}(hj1hhhNhNubah}(h]h ]h"]h$]h&]refurij3uh1j+hj)ubeh}(h]h ]h"]h$]h&]uh1hhhhMhj%ubah}(h]h ]h"]h$]h&]uh1j:hjhhhhhNubeh}(h]h ]h"]h$]h&]jjuh1j5hhhMhjhhubh)}(hContact: Sam Ravnborgh]hContact: Sam Ravnborg}(hjRhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hj`hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubeh}(h] bootsplashah ]h"] bootsplashah$]h&]uh1hhjhhhhhMubh)}(hhh](h)}(h backlight device mapping h]h)}(hvideo: this does support controlling multiple backlights, but some work will need to be done to get the output <-> backlight device mappingh]hvideo: this does support controlling multiple backlights, but some work will need to be done to get the output <-> backlight device mapping}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1j:hjhhhhhNubeh}(h]h ]h"]h$]h&]j_j`jahjbjcuh1j hjvhhhhhMubh)}(hXThe above assumes both panels will require the same backlight interface type. Things will break on systems with multiple panels where the 2 panels need a different type of control. E.g. one panel needs ACPI video backlight control, where as the other is using native backlight control. Currently in this case only one of the 2 required backlight devices will get registered, based on the acpi_video_get_backlight_type() return value.h]hXThe above assumes both panels will require the same backlight interface type. Things will break on systems with multiple panels where the 2 panels need a different type of control. E.g. one panel needs ACPI video backlight control, where as the other is using native backlight control. Currently in this case only one of the 2 required backlight devices will get registered, based on the acpi_video_get_backlight_type() return value.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjvhhubh)}(hIf this (theoretical) case ever shows up, then supporting this will need some work. A possible solution here would be to pass a device and connector-name to acpi_video_get_backlight_type() so that it can deal with this.h]hIf this (theoretical) case ever shows up, then supporting this will need some work. A possible solution here would be to pass a device and connector-name to acpi_video_get_backlight_type() so that it can deal with this.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM hjvhhubh)}(hNote in a way we already have a case where userspace sees 2 panels, in dual GPU laptop setups with a mux. On those systems we may see either 2 native backlight devices; or 2 native backlight devices.h]hNote in a way we already have a case where userspace sees 2 panels, in dual GPU laptop setups with a mux. On those systems we may see either 2 native backlight devices; or 2 native backlight devices.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM hjvhhubh)}(hX;Userspace already has code to deal with this by detecting if the related panel is active (iow which way the mux between the GPU and the panels points) and then uses that backlight device. Userspace here very much assumes a single panel though. It picks only 1 of the 2 backlight devices and then only uses that one.h]hX;Userspace already has code to deal with this by detecting if the related panel is active (iow which way the mux between the GPU and the panels points) and then uses that backlight device. Userspace here very much assumes a single panel though. It picks only 1 of the 2 backlight devices and then only uses that one.}(hj"hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjvhhubh)}(h_Note that all userspace code (that I know off) is currently hardcoded to assume a single panel.h]h_Note that all userspace code (that I know off) is currently hardcoded to assume a single panel.}(hj0hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjvhhubh)}(hBefore the recent changes to not register multiple (e.g. video + native) /sys/class/backlight devices for a single panel (on a single GPU laptop), userspace would see multiple backlight devices all controlling the same backlight.h]hBefore the recent changes to not register multiple (e.g. video + native) /sys/class/backlight devices for a single panel (on a single GPU laptop), userspace would see multiple backlight devices all controlling the same backlight.}(hj>hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjvhhubh)}(hTo deal with this userspace had to always picks one preferred device under /sys/class/backlight and will ignore the others. So to support brightness control on multiple panels userspace will need to be updated too.h]hTo deal with this userspace had to always picks one preferred device under /sys/class/backlight and will ignore the others. So to support brightness control on multiple panels userspace will need to be updated too.}(hjLhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjvhhubh)}(hXThere are plans to allow brightness control through the KMS API by adding a "display brightness" property to drm_connector objects for panels. This solves a number of issues with the /sys/class/backlight API, including not being able to map a sysfs backlight device to a specific connector. Any userspace changes to add support for brightness control on devices with multiple panels really should build on top of this new KMS property.h]hXThere are plans to allow brightness control through the KMS API by adding a “display brightness” property to drm_connector objects for panels. This solves a number of issues with the /sys/class/backlight API, including not being able to map a sysfs backlight device to a specific connector. Any userspace changes to add support for brightness control on devices with multiple panels really should build on top of this new KMS property.}(hjZhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM#hjvhhubh)}(hContact: Hans de Goedeh]hContact: Hans de Goede}(hjhhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM*hjvhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjvhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM,hjvhhubeh}(h]hjubh.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhM>hjhhubh)}(h6Contact: Javier Martinez Canillas h](h#Contact: Javier Martinez Canillas <}(hjhhhNhNubj,)}(hjavierm@redhat.comh]hjavierm@redhat.com}(hjhhhNhNubah}(h]h ]h"]h$]h&]refurimailto:javierm@redhat.comuh1j+hjubh>}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMAhjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMChjhhubeh}(h]Cbuffer-age-or-other-damage-accumulation-algorithm-for-buffer-damageah ]h"]Cbuffer age or other damage accumulation algorithm for buffer damageah$]h&]uh1hhjhhhhhM/ubh)}(hhh](h)}(h Querying errors from drm_syncobjh]h Querying errors from drm_syncobj}(hj4hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj1hhhhhMFubh)}(heThe drm_syncobj container can be used by driver independent code to signal complection of submission.h]heThe drm_syncobj container can be used by driver independent code to signal complection of submission.}(hjBhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMHhj1hhubh)}(htOne minor feature still missing is a generic DRM IOCTL to query the error status of binary and timeline drm_syncobj.h]htOne minor feature still missing is a generic DRM IOCTL to query the error status of binary and timeline drm_syncobj.}(hjPhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMKhj1hhubh)}(hThis should probably be improved by implementing the necessary kernel interface and adding support for that in the userspace stack.h]hThis should probably be improved by implementing the necessary kernel interface and adding support for that in the userspace stack.}(hj^hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMNhj1hhubh)}(hContact: Christian Königh]hContact: Christian König}(hjlhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMQhj1hhubh)}(hLevel: Starterh]hLevel: Starter}(hjzhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMShj1hhubeh}(h] querying-errors-from-drm-syncobjah ]h"] querying errors from drm_syncobjah$]h&]uh1hhjhhhhhMFubh)}(hhh]h)}(h Outside DRMh]h Outside DRM}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMVubah}(h] outside-drmah ]h"] outside drmah$]h&]uh1hhjhhhhhMVubeh}(h]amd-dc-display-driverah ]h"]amd dc display driverah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(hConvert fbdev drivers to DRMh]hConvert fbdev drivers to DRM}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMYubh)}(hThere are plenty of fbdev drivers for older hardware. Some hardware 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.h]hThere are plenty of fbdev drivers for older hardware. Some hardware 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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM[hjhhubh)}(hVery 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.h]hVery 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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM`hjhhubh)}(hX"More complex fbdev drivers can be refactored step-by-step into a DRM driver with the help of the DRM fbconv helpers [4]_. 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 in Thomas Zimmermann's fbconv tree [4]_, as well as a tutorial of this process [5]_. The result is a primitive DRM driver that can run X11 and Weston.h](htMore complex fbdev drivers can be refactored step-by-step into a DRM driver with the help of the DRM fbconv helpers }(hjhhhNhNubj)}(h[4]_h]h4}(hjhhhNhNubah}(h]id7ah ]h"]h$]h&]hid10jjuh1jhjjKubhX9. 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 in Thomas Zimmermann’s fbconv tree }(hjhhhNhNubj)}(h[4]_h]h4}(hjhhhNhNubah}(h]id8ah ]h"]h$]h&]hjjjuh1jhjjKubh(, as well as a tutorial of this process }(hjhhhNhNubj)}(h[5]_h]h5}(hj hhhNhNubah}(h]id9ah ]h"]h$]h&]hid11jjuh1jhjjKubhC. The result is a primitive DRM driver that can run X11 and Weston.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMehjhhubj )}(h.. [4] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv .. [5] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c h](j)}(hh](hContact: Thomas Zimmermann <}(hjhhhNhNubj,)}(htzimmermann@suse.deh]htzimmermann@suse.de}(hjhhhNhNubah}(h]h ]h"]h$]h&]refurimailto:tzimmermann@suse.deuh1j+hjubh>}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMqhjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMshjhhubeh}(h]convert-fbdev-drivers-to-drmah ]h"]convert fbdev drivers to drmah$]h&]uh1hhhhhhhhMYubeh}(h]( todo-listheh ]h"]( todo listtodoeh$]h&]uh1hhhhhhhhKexpect_referenced_by_name}jhsexpect_referenced_by_id}hhsubeh}(h]h ]h"]h$]h&]sourcehuh1hcurrent_sourceN current_lineNsettingsdocutils.frontendValues)}(hN generatorN datestampN source_linkN source_urlN toc_backlinksentryfootnote_backlinksK sectnum_xformKstrip_commentsNstrip_elements_with_classesN strip_classesN report_levelK halt_levelKexit_status_levelKdebugNwarning_streamN tracebackinput_encoding utf-8-siginput_encoding_error_handlerstrictoutput_encodingutf-8output_encoding_error_handlerjerror_encodingutf-8error_encoding_error_handlerbackslashreplace language_codeenrecord_dependenciesNconfigN id_prefixhauto_id_prefixid dump_settingsNdump_internalsNdump_transformsNdump_pseudo_xmlNexpose_internalsNstrict_visitorN_disable_configN_sourceh _destinationN _config_files]7/var/lib/git/docbuild/linux/Documentation/docutils.confafile_insertion_enabled raw_enabledKline_length_limitM'pep_referencesN pep_base_urlhttps://peps.python.org/pep_file_url_templatepep-%04drfc_referencesN rfc_base_url&https://datatracker.ietf.org/doc/html/ tab_widthKtrim_footnote_reference_spacesyntax_highlightlong smart_quotessmartquotes_locales]character_level_inline_markupdoctitle_xform docinfo_xformKsectsubtitle_xform image_loadinglinkembed_stylesheetcloak_email_addressessection_self_linkenvNubreporterNindirect_targets]substitution_defs}substitution_names}refnames}(1]ja2]ja3]ja4](jje5]j aurefids}h]hasnameids}(jhjjjJjGjBj?jjjjjEjjujjjjjjjj j j5j2jLjIj]jZjjjjj4j1jjjjj j jl ji j j jH jE j j j j j j j- j* j j j j j\jYjjjjjdjajdjajjj)j&jj jjjjjj jjjNjKjjjKjHjjjjjjjjjjjsjpjjj.j+jjjjjjjXjjju nametypes}(jjjJjBjjjEjujjjj j5jLj]jjj4jjj jl j jH j j j j- j j j\jjjdjdjj)jjjjjjNjjKjjjjjjsjj.jjjjXjuh}(hhjhjGhj?j,jjMjjjjjjjjjjjjHjjxjjjjj jj2jjIj8jZjOjj`jjj1jjj7jjj j ji j j jo jE j j jK j j j j j* j j j0 j j jYj jj_jjjajjaj[jjj&j j jgjjjjj jjjjKjEjjjHjjjNjjjjjjjjjpjjjvj+jjj1jjjjjjjjjj jj+jj[u footnote_refs}(j:]jaj<]jaj>]jaj@](jjejB]j au citation_refs} autofootnotes]autofootnote_refs]symbol_footnotes]symbol_footnote_refs] footnotes](jjHjxj+j[e citations]autofootnote_startKsymbol_footnote_startK id_counter collectionsCounter}jK sRparse_messages]transform_messages]hsystem_message)}(hhh]h)}(hhh]h*Hyperlink target "todo" is not referenced.}hjssbah}(h]h ]h"]h$]h&]uh1hhjpubah}(h]h ]h"]h$]h&]levelKtypeINFOsourcehlineKuh1jnuba transformerN include_log] decorationNhhub.