sphinx.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]hPortuguese (Brazilian)}hhsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget/translations/pt_BR/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.}(hjhhhNhNubah}(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.}(hj$hhhNhNubah}(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}(hj2hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhhhhubh)}(hhh]h)}(hSubsystem-wide refactoringsh]hSubsystem-wide refactorings}(hjChhhNhNubah}(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#Open-code drm_simple_encoder_init()h]h#Open-code drm_simple_encoder_init()}(hjdhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjahhhhhK!ubh)}(hThe helper drm_simple_encoder_init() was supposed to simplify encoder initialization. Instead it only added an intermediate layer between atomic modesetting and the DRM driver.h]hThe helper drm_simple_encoder_init() was supposed to simplify encoder initialization. Instead it only added an intermediate layer between atomic modesetting and the DRM driver.}(hjrhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK#hjahhubh)}(hThe task here is to remove drm_simple_encoder_init(). Search for a driver that calls drm_simple_encoder_init() and inline the helper. The driver will also need its own instance of drm_encoder_funcs.h]hThe task here is to remove drm_simple_encoder_init(). Search for a driver that calls drm_simple_encoder_init() and inline the helper. The driver will also need its own instance of drm_encoder_funcs.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK'hjahhubh)}(h8Contact: Thomas Zimmermann, respective driver maintainerh]h8Contact: Thomas Zimmermann, respective driver maintainer}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK+hjahhubh)}(h Level: Easyh]h Level: Easy}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK-hjahhubeh}(h]!open-code-drm-simple-encoder-initah ]h"]#open-code drm_simple_encoder_init()ah$]h&]uh1hhhhhhhhK!ubh)}(hhh](h)}(hBReplace struct drm_simple_display_pipe with regular atomic helpersh]hBReplace struct drm_simple_display_pipe with regular atomic helpers}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhK0ubh)}(hThe data type struct drm_simple_display_pipe and its helpers were supposed to simplify driver development. Instead they only added an intermediate layer between atomic modesetting and the DRM driver.h]hThe data type struct drm_simple_display_pipe and its helpers were supposed to simplify driver development. Instead they only added an intermediate layer between atomic modesetting and the DRM driver.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK2hjhhubh)}(hXwThere are still drivers that use drm_simple_display_pipe. The task here is to convert them to use regular atomic helpers. Search for a driver that calls drm_simple_display_pipe_init() and inline all helpers from drm_simple_kms_helper.c into the driver, such that no simple-KMS interfaces are required. Please also rename all inlined functions according to driver conventions.h]hXwThere are still drivers that use drm_simple_display_pipe. The task here is to convert them to use regular atomic helpers. Search for a driver that calls drm_simple_display_pipe_init() and inline all helpers from drm_simple_kms_helper.c into the driver, such that no simple-KMS interfaces are required. Please also rename all inlined functions according to driver conventions.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK6hjhhubh)}(h8Contact: Thomas Zimmermann, respective driver maintainerh]h8Contact: Thomas Zimmermann, respective driver maintainer}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjhhubeh}(h]Breplace-struct-drm-simple-display-pipe-with-regular-atomic-helpersah ]h"]Breplace struct drm_simple_display_pipe with regular atomic helpersah$]h&]uh1hhhhhhhhK0ubh)}(hhh](h)}(h-Remove custom dumb_map_offset implementationsh]h-Remove custom dumb_map_offset implementations}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhKAubh)}(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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKChjhhubh)}(h5Contact: Simona Vetter, respective driver maintainersh]h5Contact: Simona Vetter, respective driver maintainers}(hj"hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKHhjhhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hj0hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKJhjhhubeh}(h]-remove-custom-dumb-map-offset-implementationsah ]h"]-remove custom dumb_map_offset implementationsah$]h&]uh1hhhhhhhhKAubh)}(hhh](h)}(h2Convert existing KMS drivers to atomic modesettingh]h2Convert existing KMS drivers to atomic modesetting}(hjIhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjFhhhhhKMubh)}(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.}(hjWhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKOhjFhhubh)}(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 }(hjehhhNhNubhfootnote_reference)}(h[1]_h]h1}(hjohhhNhNubah}(h]id1ah ]h"]h$]h&]hid4docnamegpu/todouh1jmhjeresolvedKubhm and all you need is a GPU for a non-converted driver. The “Atomic mode setting design overview” series }(hjehhhNhNubjn)}(h[2]_h]h2}(hjhhhNhNubah}(h]id2ah ]h"]h$]h&]hid5jjuh1jmhjejKubh }(hjehhhNhNubjn)}(h[3]_h]h3}(hjhhhNhNubah}(h]id3ah ]h"]h$]h&]hid6jjuh1jmhjejKubh at LWN.net can also be helpful.}(hjehhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKThjFhhubh)}(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&]uh1hhhhKXhjFhhubh 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}(hjhhhNhNubah}(h]h ]h"]h$]h&]refurijuh1jhjubah}(h]h ]h"]h$]h&]uh1hhhhK\hjubeh}(h]j~ah ]h"]1ah$]h&]jyajjuh1jhhhK\hjjKubj)}(h https://lwn.net/Articles/653071/h](j)}(h2h]h2}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhjubh)}(hjh]j)}(hjh]h https://lwn.net/Articles/653071/}(hjhhhNhNubah}(h]h ]h"]h$]h&]refurijuh1jhjubah}(h]h ]h"]h$]h&]uh1hhhhK]hjubeh}(h]jah ]h"]2ah$]h&]jajjuh1jhhhK]hjjKubj)}(h!https://lwn.net/Articles/653466/ h](j)}(h3h]h3}(hj2hhhNhNubah}(h]h ]h"]h$]h&]uh1jhj.ubh)}(h https://lwn.net/Articles/653466/h]j)}(hjBh]h https://lwn.net/Articles/653466/}(hjDhhhNhNubah}(h]h ]h"]h$]h&]refurijBuh1jhj@ubah}(h]h ]h"]h$]h&]uh1hhhhK^hj.ubeh}(h]jah ]h"]3ah$]h&]jajjuh1jhhhK^hjjKubeh}(h]h ]h"]h$]h&]uh1jhhhK\hjFhhubh)}(h5Contact: Simona Vetter, respective driver maintainersh]h5Contact: Simona Vetter, respective driver maintainers}(hjehhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK`hjFhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjshhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKbhjFhhubeh}(h]2convert-existing-kms-drivers-to-atomic-modesettingah ]h"]2convert existing kms drivers to atomic modesettingah$]h&]uh1hhhhhhhhKMubh)}(hhh](h)}(h9Clean up the clipped coordination confusion around planesh]h9Clean up the clipped coordination confusion around planes}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhKeubh)}(hXWe have a helper to get this right with drm_plane_helper_check_update(), but it's not consistently used. This should be fixed, preferably in the atomic helpers (and drivers then moved over to clipped coordinates). Probably the helper should also be moved from drm_plane_helper.c to the atomic helpers, to avoid confusion - the other helpers in that file are all deprecated legacy helpers.h]hXWe have a helper to get this right with drm_plane_helper_check_update(), but it’s not consistently used. This should be fixed, preferably in the atomic helpers (and drivers then moved over to clipped coordinates). Probably the helper should also be moved from drm_plane_helper.c to the atomic helpers, to avoid confusion - the other helpers in that file are all deprecated legacy helpers.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKghjhhubh)}(h;Contact: Ville Syrjälä, Simona Vetter, driver maintainersh]h;Contact: Ville Syrjälä, Simona Vetter, driver maintainers}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKnhjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKphjhhubeh}(h]9clean-up-the-clipped-coordination-confusion-around-planesah ]h"]9clean up the clipped coordination confusion around planesah$]h&]uh1hhhhhhhhKeubh)}(hhh](h)}(h"Improve plane atomic_check helpersh]h"Improve plane atomic_check helpers}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhKsubh)}(hhAside from the clipped coordinates right above there's a few suboptimal things with the current helpers:h]hjAside from the clipped coordinates right above there’s a few suboptimal things with the current helpers:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKuhjhhubh bullet_list)}(hhh](h list_item)}(hXhdrm_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]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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKxhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubj)}(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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK~hj ubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubj)}(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.}(hj&hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj"ubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubeh}(h]h ]h"]h$]h&]bullet-uh1jhhhKxhjhhubh)}(hContact: Simona Vetterh]hContact: Simona Vetter}(hjBhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjPhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjhhubeh}(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}(hjihhhNhNubah}(h]h ]h"]h$]h&]uh1hhjfhhhhhKubh)}(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.}(hjwhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjfhhubh)}(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&]uh1hhhhKhjfhhubh)}(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&]uh1hhhhKhjfhhubh)}(h5Contact: Simona Vetter, respective driver maintainersh]h5Contact: Simona Vetter, respective driver maintainers}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjfhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjfhhubeh}(h]4convert-early-atomic-drivers-to-async-commit-helpersah ]h"]4convert early atomic drivers to async commit helpersah$]h&]uh1hhhhhhhhKubh)}(hhh](h)}(hFallout from atomic KMSh]hFallout from atomic KMS}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhKubh)}(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](hliteral)}(h``drm_atomic_helper.c``h]hdrm_atomic_helper.c}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhjubhX7 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:}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhjhhubj)}(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 }(hjhhhNhNubj)}(h``GFP_NOFAIL``h]h GFP_NOFAIL}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhjubh 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.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhjubh)}(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&]uh1hhhhKhjubeh}(h]h ]h"]h$]h&]uh1jhjhhhhhNubj)}(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 }(hj3hhhNhNubj)}(h``drm_foo_funcs``h]h drm_foo_funcs}(hj;hhhNhNubah}(h]h ]h"]h$]h&]uh1jhj3ubhw), which are used to implement the userspace ABI. And then there’s the optional hooks for the helper libraries (name }(hj3hhhNhNubj)}(h``drm_foo_helper_funcs``h]hdrm_foo_helper_funcs}(hjMhhhNhNubah}(h]h ]h"]h$]h&]uh1jhj3ubhN), which are purely for internal use. Some of these hooks should be move from }(hj3hhhNhNubj)}(h ``_funcs``h]h_funcs}(hj_hhhNhNubah}(h]h ]h"]h$]h&]uh1jhj3ubh to }(hj3hhhNhNubj)}(h``_helper_funcs``h]h _helper_funcs}(hjqhhhNhNubah}(h]h ]h"]h$]h&]uh1jhj3ubh6 since they are not part of the core ABI. There’s a }(hj3hhhNhNubj)}(h ``FIXME``h]hFIXME}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhj3ubh0 comment in the kerneldoc for each such case in }(hj3hhhNhNubj)}(h``drm_crtc.h``h]h drm_crtc.h}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhj3ubh.}(hj3hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhj/ubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubeh}(h]h ]h"]h$]h&]j@*uh1jhhhKhjhhubh)}(hContact: Simona Vetterh]hContact: Simona Vetter}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjhhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjhhubeh}(h]fallout-from-atomic-kmsah ]h"]fallout from atomic kmsah$]h&]uh1hhhhhhhhKubh)}(hhh](h)}(h-Move Buffer Object Locking to dma_resv_lock()h]h-Move Buffer Object Locking to dma_resv_lock()}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhKubh)}(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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjhhubh)}(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&]uh1hhhhKhjhhubh)}(h Level: Experth]h Level: Expert}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjhhubeh}(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 <}(hjhhhNhNubj)}(htzimmermann@suse.deh]htzimmermann@suse.de}(hjhhhNhNubah}(h]h ]h"]h$]h&]refurimailto:tzimmermann@suse.deuh1jhjubh>, Simona Vetter}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjhhubeh}(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&]uh1hhj hhhhhKubh)}(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&]uh1hhhhKhj hhubh)}(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.}(hj+hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj hhubh)}(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()).}(hj9hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj hhubh)}(h0Contact: Thomas Zimmermann h](hContact: Thomas Zimmermann <}(hjGhhhNhNubj)}(htzimmermann@suse.deh]htzimmermann@suse.de}(hjOhhhNhNubah}(h]h ]h"]h$]h&]refurimailto:tzimmermann@suse.deuh1jhjGubh>}(hjGhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hjihhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubeh}(h]>benchmark-and-optimize-blitting-and-format-conversion-functionah ]h"]>benchmark and optimize blitting and format-conversion functionah$]h&]uh1hhhhhhhhKubh)}(hhh](h)}(hAdrm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanuph]hAdrm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhM ubh)}(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:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM hjhhubj)}(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).}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubj)}(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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubj)}(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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubj)}(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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubeh}(h]h ]h"]h$]h&]j@jAuh1jhhhMhjhhubh)}(hContact: Simona Vetterh]hContact: Simona Vetter}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubeh}(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&]uh1hhhhhhhhM ubh)}(hhh](h)}(hGeneric fbdev defio supporth]hGeneric fbdev defio support}(hj.hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj+hhhhhM!ubh)}(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&]uh1hhhhM#hj+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:}(hjJhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM)hj+hhubj)}(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);}hjosbah}(h]h ]h"]h$]h&] xml:spacepreserveuh1jmhhhM0hj[ubeh}(h]h ]h"]h$]h&]uh1jhjXhhhhhNubj)}(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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM2hjubah}(h]h ]h"]h$]h&]uh1jhjXhhhhhNubj)}(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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM7hjubah}(h]h ]h"]h$]h&]uh1jhjXhhhhhNubeh}(h]h ]h"]h$]h&]j@jAuh1jhhhM-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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM:hj+hhubh)}(h&Contact: Simona Vetter, Noralf Tronnesh]h&Contact: Simona Vetter, Noralf Tronnes}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM<hj+hhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM>hj+hhubeh}(h]generic-fbdev-defio-supportah ]h"]generic fbdev defio supportah$]h&]uh1hhhhhhhhM!ubh)}(hhh](h)}(h#connector register/unregister fixesh]h#connector register/unregister fixes}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMAubj)}(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&]uh1hhhhMChj ubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubj)}(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&]uh1hhhhMGhj ubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubeh}(h]h ]h"]h$]h&]j@jAuh1jhhhMChjhhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hj7 hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMLhjhhubeh}(h]#connector-register-unregister-fixesah ]h"]#connector register/unregister fixesah$]h&]uh1hhhhhhhhMAubh)}(hhh](h)}(hRemove load/unload callbacksh]hRemove load/unload callbacks}(hjP hhhNhNubah}(h]h ]h"]h$]h&]uh1hhjM hhhhhMOubh)}(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&]uh1hhhhMQhjM hhubj)}(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.}(hjs hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMUhjo ubah}(h]h ]h"]h$]h&]uh1jhjl 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&]uh1hhhhMXhj ubah}(h]h ]h"]h$]h&]uh1jhjl hhhhhNubeh}(h]h ]h"]h$]h&]j@jAuh1jhhhMUhjM hhubh)}(hContact: Simona Vetterh]hContact: Simona Vetter}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMZhjM hhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM\hjM hhubeh}(h]remove-load-unload-callbacksah ]h"]remove load/unload callbacksah$]h&]uh1hhhhhhhhMOubh)}(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}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhM_ubh)}(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&]uh1hhhhMahj 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.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMehj hhubh)}(h8Contact: Laurent Pinchart, respective driver maintainersh]h8Contact: Laurent Pinchart, respective driver maintainers}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhhj hhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMjhj 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&]uh1hhhhhhhhM_ubh)}(hhh](h)}(h,Consolidate custom driver modeset propertiesh]h,Consolidate custom driver modeset properties}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhMmubh)}(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&]uh1hhhhMohj 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:}(hj9 hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMshj hhubh)}(h$A quick, unconfirmed, examples list.h]h$A quick, unconfirmed, examples list.}(hjG hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMvhj 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)}(hjU hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMxhj 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 (?)}(hjc hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(h4Contact: Emil Velikov, respective driver maintainersh]h4Contact: Emil Velikov, respective driver maintainers}(hjq 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&]uh1hhhhhhhhMmubh)}(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.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubj)}(hhh](j)}(hIMemory managers should use struct iosys_map for dma-buf-imported buffers.h]h)}(hj h]hIMemory managers should use struct iosys_map for dma-buf-imported buffers.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj ubah}(h]h ]h"]h$]h&]uh1jhj hhhhhNubj)}(h9TTM might benefit from using struct iosys_map internally.h]h)}(hj h]h9TTM might benefit from using struct iosys_map internally.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj ubah}(h]h ]h"]h$]h&]uh1jhj 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.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj ubah}(h]h ]h"]h$]h&]uh1jhj hhhhhNubeh}(h]h ]h"]h$]h&]j@juh1jhhhMhj 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.deuh1jhj ubh">, Christian König, Simona Vetter}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hj3 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}(hjL hhhNhNubah}(h]h ]h"]h$]h&]uh1hhjI 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.}(hjZ hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjI 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.}(hjh hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjI hhubh)}(h0Contact: Thomas Zimmermann h](hContact: Thomas Zimmermann <}(hjv hhhNhNubj)}(htzimmermann@suse.deh]htzimmermann@suse.de}(hj~ hhhNhNubah}(h]h ]h"]h$]h&]refurimailto:tzimmermann@suse.deuh1jhjv ubh>}(hjv hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjI hhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjI 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 fbdev driversh]h+Request memory regions in all fbdev drivers}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhMubh)}(hX+Old/ancient fbdev drivers do not request their memory properly. Go through these 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. Problematic areas include hardware that has exclusive ranges like VGA. VGA16fb does not request the range as it is expected. Drivers 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]hX-Old/ancient fbdev drivers do not request their memory properly. Go through these 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. Problematic areas include hardware that has exclusive ranges like VGA. VGA16fb does not request the range as it is expected. Drivers 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.}(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.deuh1jhj ubh>}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(hLevel: Starterh]hLevel: Starter}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubeh}(h]+request-memory-regions-in-all-fbdev-driversah ]h"]+request memory regions in all fbdev 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.}(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.deuh1jhj$ ubh>}(hj$ hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(hLevel: Starterh]hLevel: Starter}(hjF 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.}(hjm 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.}(hj hhhNhNubah}(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.orguh1jhj ubh>}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj\ hhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hj hhhNhNubah}(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)}(h8Transition away from using deprecated MIPI DSI functionsh]h8Transition away from using deprecated MIPI DSI functions}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhMubh)}(hXThere are many functions defined in ``drm_mipi_dsi.c`` which have been deprecated. Each deprecated function was deprecated in favor of its `multi` variant (e.g. `mipi_dsi_generic_write()` and `mipi_dsi_generic_write_multi()`). The `multi` variant of a function includes improved error handling and logic which makes it more convenient to make several calls in a row, as most MIPI drivers do.h](h$There are many functions defined in }(hj hhhNhNubj)}(h``drm_mipi_dsi.c``h]hdrm_mipi_dsi.c}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1jhj ubhU which have been deprecated. Each deprecated function was deprecated in favor of its }(hj hhhNhNubhtitle_reference)}(h`multi`h]hmulti}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1j hj ubh variant (e.g. }(hj hhhNhNubj )}(h`mipi_dsi_generic_write()`h]hmipi_dsi_generic_write()}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1j hj ubh and }(hj hhhNhNubj )}(h `mipi_dsi_generic_write_multi()`h]hmipi_dsi_generic_write_multi()}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1j hj ubh). The }(hj hhhNhNubj )}(h`multi`h]hmulti}(hj2 hhhNhNubah}(h]h ]h"]h$]h&]uh1j hj ubh variant of a function includes improved error handling and logic which makes it more convenient to make several calls in a row, as most MIPI drivers do.}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(hDrivers should be updated to use undeprecated functions. Once all usages of the deprecated MIPI DSI functions have been removed, their definitions may be removed from ``drm_mipi_dsi.c``.h](hDrivers should be updated to use undeprecated functions. Once all usages of the deprecated MIPI DSI functions have been removed, their definitions may be removed from }(hjJ hhhNhNubj)}(h``drm_mipi_dsi.c``h]hdrm_mipi_dsi.c}(hjR hhhNhNubah}(h]h ]h"]h$]h&]uh1jhjJ ubh.}(hjJ hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(h1Contact: Douglas Anderson h](hContact: Douglas Anderson <}(hjj hhhNhNubj)}(hdianders@chromium.orgh]hdianders@chromium.org}(hjr hhhNhNubah}(h]h ]h"]h$]h&]refurimailto:dianders@chromium.orguh1jhjj ubh>}(hjj hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj hhubh)}(hLevel: Starterh]hLevel: Starter}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubeh}(h]8transition-away-from-using-deprecated-mipi-dsi-functionsah ]h"]8transition away from using deprecated mipi dsi functionsah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(hRemove devm_drm_put_bridge()h]hRemove devm_drm_put_bridge()}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhMubh)}(hXDue to how the panel bridge handles the drm_bridge object lifetime, special care must be taken to dispose of the drm_bridge object when the panel_bridge is removed. This is currently managed using devm_drm_put_bridge(), but that is an unsafe, temporary workaround. To fix that, the DRM panel lifetime needs to be reworked. After the rework is done, remove devm_drm_put_bridge() and the TODO in drm_panel_bridge_remove().h]hXDue to how the panel bridge handles the drm_bridge object lifetime, special care must be taken to dispose of the drm_bridge object when the panel_bridge is removed. This is currently managed using devm_drm_put_bridge(), but that is an unsafe, temporary workaround. To fix that, the DRM panel lifetime needs to be reworked. After the rework is done, remove devm_drm_put_bridge() and the TODO in drm_panel_bridge_remove().}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubhdefinition_list)}(hhh]hdefinition_list_item)}(hWContact: Maxime Ripard , Luca Ceresoli h](hterm)}(h,Contact: Maxime Ripard ,h](hContact: Maxime Ripard <}(hj hhhNhNubj)}(hmripard@kernel.orgh]hmripard@kernel.org}(hj hhhNhNubah}(h]h ]h"]h$]h&]refurimailto:mripard@kernel.orguh1jhj ubh>,}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1j hhhMhj ubh definition)}(hhh]h)}(h)Luca Ceresoli h](hLuca Ceresoli <}(hj hhhNhNubj)}(hluca.ceresoli@bootlin.comh]hluca.ceresoli@bootlin.com}(hj hhhNhNubah}(h]h ]h"]h$]h&]refuri mailto:luca.ceresoli@bootlin.comuh1jhj ubh>}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj ubah}(h]h ]h"]h$]h&]uh1j hj ubeh}(h]h ]h"]h$]h&]uh1j hhhMhj ubah}(h]h ]h"]h$]h&]uh1j hj hhhhhNubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hj)hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj hhubeh}(h]remove-devm-drm-put-bridgeah ]h"]remove devm_drm_put_bridge()ah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(hEConvert users of of_drm_find_bridge() to of_drm_find_and_get_bridge()h]hEConvert users of of_drm_find_bridge() to of_drm_find_and_get_bridge()}(hjBhhhNhNubah}(h]h ]h"]h$]h&]uh1hhj?hhhhhMubh)}(hXTaking a struct drm_bridge pointer requires getting a reference and putting it after disposing of the pointer. Most functions returning a struct drm_bridge pointer already call drm_bridge_get() to increment the refcount and their users have been updated to call drm_bridge_put() when appropriate. of_drm_find_bridge() does not get a reference and it has been deprecated in favor of of_drm_find_and_get_bridge() which does, but some users still need to be converted.h]hXTaking a struct drm_bridge pointer requires getting a reference and putting it after disposing of the pointer. Most functions returning a struct drm_bridge pointer already call drm_bridge_get() to increment the refcount and their users have been updated to call drm_bridge_put() when appropriate. of_drm_find_bridge() does not get a reference and it has been deprecated in favor of of_drm_find_and_get_bridge() which does, but some users still need to be converted.}(hjPhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM hj?hhubj )}(hhh]j )}(hWContact: Maxime Ripard , Luca Ceresoli h](j )}(h,Contact: Maxime Ripard ,h](hContact: Maxime Ripard <}(hjehhhNhNubj)}(hmripard@kernel.orgh]hmripard@kernel.org}(hjmhhhNhNubah}(h]h ]h"]h$]h&]refurimailto:mripard@kernel.orguh1jhjeubh>,}(hjehhhNhNubeh}(h]h ]h"]h$]h&]uh1j hhhMhjaubj )}(hhh]h)}(h)Luca Ceresoli h](hLuca Ceresoli <}(hjhhhNhNubj)}(hluca.ceresoli@bootlin.comh]hluca.ceresoli@bootlin.com}(hjhhhNhNubah}(h]h ]h"]h$]h&]refuri mailto:luca.ceresoli@bootlin.comuh1jhjubh>}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1j hjaubeh}(h]h ]h"]h$]h&]uh1j hhhMhj^ubah}(h]h ]h"]h$]h&]uh1j hj?hhhhhNubh)}(hLevel: Intermediateh]hLevel: Intermediate}(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]Aconvert-users-of-of-drm-find-bridge-to-of-drm-find-and-get-bridgeah ]h"]Econvert users of of_drm_find_bridge() to of_drm_find_and_get_bridge()ah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(hMake panic handling workh]hMake panic handling work}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubh)}(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&]uh1hhhhMhjhhubj)}(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&]uh1jhj hhhhhNubj)}(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}(hj3hhhNhNubah}(h]h ]h"]h$]h&]uh1jhj+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}(hjEhhhNhNubah}(h]h ]h"]h$]h&]namethreaded printk supportrefuri https://lwn.net/Articles/800946/uh1jhj+ubh)}(h# h]h}(h]threaded-printk-supportah ]h"]threaded printk supportah$]h&]refurijVuh1h referencedKhj+ubh.}(hj+hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhM%hj'ubah}(h]h ]h"]h$]h&]uh1jhj hhhhhNubj)}(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()}(hj}hhhNhNubah}(h]h ]h"]h$]h&]uh1jhjyubh 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.}(hjyhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhM-hjuubah}(h]h ]h"]h$]h&]uh1jhj hhhhhNubj)}(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&]uh1jhjubh. 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&]uh1hhhhM2hjubah}(h]h ]h"]h$]h&]uh1jhj hhhhhNubj)}(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 handlingjULhttps://lore.kernel.org/dri-devel/20190311174218.51899-1-noralf@tronnes.org/uh1jhjubh)}(hO h]h}(h]#patch-v2-0-3-drm-add-panic-handlingah ]h"]&[patch v2 0/3] drm: add panic handlingah$]h&]refurijuh1hjdKhjubh.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhM7hjubah}(h]h ]h"]h$]h&]uh1jhj hhhhhNubj)}(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}(hj hhhNhNubah}(h]h ]h"]h$]h&]name2[RFC][PATCH] Oops messages transfer using QR codesjU[https://lore.kernel.org/lkml/1446217392-11981-1-git-send-email-alexandru.murtaza@intel.com/uh1jhjubh)}(h^ h]h}(h]/rfc-patch-oops-messages-transfer-using-qr-codesah ]h"]2[rfc][patch] oops messages transfer using qr codesah$]h&]refurijuh1hjdKhjubh, for some example code that could be reused.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhM;hjubah}(h]h ]h"]h$]h&]uh1jhj hhhhhNubeh}(h]h ]h"]h$]h&]j@juh1jhhhMhjhhubh)}(hContact: Simona Vetterh]hContact: Simona Vetter}(hj?hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMAhjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjMhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMChjhhubeh}(h]make-panic-handling-workah ]h"]make panic handling workah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(hClean up the debugfs supporth]hClean up the debugfs support}(hjfhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjchhhhhMFubh)}(h"There's a bunch of issues with it:h]h$There’s a bunch of issues with it:}(hjthhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMHhjchhubj)}(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&]uh1hhhhMJhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubj)}(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&]uh1hhhhMMhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubj)}(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&]uh1hhhhMQhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubj)}(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&]uh1hhhhMVhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubeh}(h]h ]h"]h$]h&]j@jAuh1jhhhMJhjchhubh)}(hContact: Simona Vetterh]hContact: Simona Vetter}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM^hjchhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM`hjchhubeh}(h]clean-up-the-debugfs-supportah ]h"]clean up the debugfs supportah$]h&]uh1hhhhhhhhMFubh)}(hhh](h)}(hObject lifetime fixesh]hObject lifetime fixes}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMcubh)}(hThere's two related issues hereh]h!There’s two related issues here}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMehjhhubj)}(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.}(hj5hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMghj1ubah}(h]h ]h"]h$]h&]uh1jhj.hhhhhNubj)}(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.}(hjMhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMjhjIubah}(h]h ]h"]h$]h&]uh1jhj.hhhhhNubeh}(h]h ]h"]h$]h&]j@jAuh1jhhhMghjhhubh)}(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.}(hjghhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMohjhhubh)}(hContact: Simona Vetterh]hContact: Simona Vetter}(hjuhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMshjhhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMuhjhhubeh}(h]object-lifetime-fixesah ]h"]object lifetime fixesah$]h&]uh1hhhhhhhhMcubh)}(hhh](h)}(h4Remove automatic page mapping from dma-buf importingh]h4Remove automatic page mapping from dma-buf importing}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMxubh)}(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&]uh1hhhhMzhjhhubh)}(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&]uh1hhhhMhjhhubh)}(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.deuh1jhjubh>, Simona Vetter}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubeh}(h]4remove-automatic-page-mapping-from-dma-buf-importingah ]h"]4remove automatic page mapping from dma-buf importingah$]h&]uh1hhhhhhhhMxubh)}(hhh](h)}(h"Implement a new DUMB_CREATE2 ioctlh]h"Implement a new DUMB_CREATE2 ioctl}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubh)}(hXThe current DUMB_CREATE ioctl is not well defined. Instead of a pixel and framebuffer format, it only accepts a color mode of vague semantics. Assuming a linear framebuffer, the color mode gives an idea of the supported pixel format. But userspace effectively has to guess the correct values. It really only works reliably with framebuffers in XRGB8888. Userspace has begun to workaround these limitations by computing arbitrary format's buffer sizes and calculating their sizes in terms of XRGB8888 pixels.h]hXThe current DUMB_CREATE ioctl is not well defined. Instead of a pixel and framebuffer format, it only accepts a color mode of vague semantics. Assuming a linear framebuffer, the color mode gives an idea of the supported pixel format. But userspace effectively has to guess the correct values. It really only works reliably with framebuffers in XRGB8888. Userspace has begun to workaround these limitations by computing arbitrary format’s buffer sizes and calculating their sizes in terms of XRGB8888 pixels.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hXOne possible solution is a new ioctl DUMB_CREATE2. It should accept a DRM format and a format modifier to resolve the color mode's ambiguity. As framebuffers can be multi-planar, the new ioctl has to return the buffer size, pitch and GEM handle for each individual color plane.h]hXOne possible solution is a new ioctl DUMB_CREATE2. It should accept a DRM format and a format modifier to resolve the color mode’s ambiguity. As framebuffers can be multi-planar, the new ioctl has to return the buffer size, pitch and GEM handle for each individual color plane.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hIn the first step, the new ioctl can be limited to the current features of the existing DUMB_CREATE. Individual drivers can then be extended to support multi-planar formats. Rockchip might require this and would be a good candidate.h]hIn the first step, the new ioctl can be limited to the current features of the existing DUMB_CREATE. Individual drivers can then be extended to support multi-planar formats. Rockchip might require this and would be a good candidate.}(hj+hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hXQIt might also be helpful to userspace to query information about the size of a potential buffer, if allocated. Userspace would supply geometry and format; the kernel would return minimal allocation sizes and scanline pitch. There is interest to allocate that memory from another device and provide it to the DRM driver (say via dma-buf).h]hXQIt might also be helpful to userspace to query information about the size of a potential buffer, if allocated. Userspace would supply geometry and format; the kernel would return minimal allocation sizes and scanline pitch. There is interest to allocate that memory from another device and provide it to the DRM driver (say via dma-buf).}(hj9hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hAnother requested feature is the ability to allocate a buffer by size, without format. Accelators use this for their buffer allocation and it could likely be generalized.h]hAnother requested feature is the ability to allocate a buffer by size, without format. Accelators use this for their buffer allocation and it could likely be generalized.}(hjGhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hIn addition to the kernel implementation, there must be user-space support for the new ioctl. There's code in Mesa that might be able to use the new call.h]hIn addition to the kernel implementation, there must be user-space support for the new ioctl. There’s code in Mesa that might be able to use the new call.}(hjUhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(h0Contact: Thomas Zimmermann h](hContact: Thomas Zimmermann <}(hjchhhNhNubj)}(htzimmermann@suse.deh]htzimmermann@suse.de}(hjkhhhNhNubah}(h]h ]h"]h$]h&]refurimailto:tzimmermann@suse.deuh1jhjcubh>}(hjchhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hhh]h)}(hBetter Testingh]hBetter Testing}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubah}(h]better-testingah ]h"]better testingah$]h&]uh1hhjhhhhhMubeh}(h]"implement-a-new-dumb-create2-ioctlah ]h"]"implement a new dumb_create2 ioctlah$]h&]uh1hhhhhhhhMubh)}(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 }(hjhhhNhNubj)}(hL`KUnit `_h]hKUnit}(hjhhhNhNubah}(h]h ]h"]h$]h&]nameKUnitjUAhttps://www.kernel.org/doc/html/latest/dev-tools/kunit/index.htmluh1jhjubh)}(hD h]h}(h]kunitah ]h"]kunitah$]h&]refurijuh1hjdKhjubh provides a common framework for unit tests within the Linux kernel. Having a test suite would allow to identify regressions earlier.}(hjhhhNhNubeh}(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 }(hjhhhNhNubj)}(h``drm_format_helper.c``h]hdrm_format_helper.c}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhjubh.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(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.comuh1jhjubh>}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hj7hhhNhNubah}(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}(hjPhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjMhhhhhMubh)}(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.}(hj^hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjMhhubh)}(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.}(hjlhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjMhhubh)}(h+Contact: Maxime Ripard h](hContact: Maxime Ripard <}(hjzhhhNhNubj)}(hmripard@kernel.orgh]hmripard@kernel.org}(hjhhhNhNubah}(h]h ]h"]h$]h&]refurimailto:mripard@kernel.orguh1jhjzubh>}(hjzhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjMhhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjMhhubeh}(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 ...}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjhhhNhNubah}(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}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubh)}(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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubeh}(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)}(hj-hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj*hhhhhMubh)}(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 }(hj;hhhNhNubh)}(h:ref:`VKMS `h]hinline)}(hjEh]hVKMS}(hjIhhhNhNubah}(h]h ](xrefstdstd-refeh"]h$]h&]uh1jGhjCubah}(h]h ]h"]h$]h&]refdocj refdomainjTreftyperef refexplicitrefwarn reftargetvkmsuh1hhhhMhj;ubh 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.}(hj;hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj*hhubh)}(hLevel: See detailsh]hLevel: See details}(hjqhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj*hhubeh}(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&]uh1jhjhhhhhNubj)}(hKIn all, only look at one of the three status bits set by the above helpers.h]h)}(hjh]hKIn all, only look at one of the three status bits set by the above helpers.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubj)}(h"Remove the other two status bits. h]h)}(h!Remove the other two status bits.h]h!Remove the other two status bits.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubeh}(h]h ]h"]h$]h&]enumtypearabicprefixhsuffix.uh1jhjhhhhhMubh)}(hContact: Simona Vetterh]hContact: Simona Vetter}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hj hhhNhNubah}(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}(hj=hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj:hhhhhMubh)}(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.}(hjKhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj:hhubh)}(h/See drivers/gpu/drm/amd/display/TODO for tasks.h]h/See drivers/gpu/drm/amd/display/TODO for tasks.}(hjYhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM hj:hhubh)}(h%Contact: Harry Wentland, Alex Deucherh]h%Contact: Harry Wentland, Alex Deucher}(hjghhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM hj:hhubh)}(hhh](h)}(h Bootsplashh]h Bootsplash}(hjxhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjuhhhhhMubh)}(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&]uh1hhhhMhjuhhubj)}(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/}(hjhhhNhNubah}(h]h ]h"]h$]h&]refurijuh1jhjubeh}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubj)}(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 }(hjhhhNhNubj)}(h?https://lore.kernel.org/r/20171213194755.3409-1-mstaudt@suse.deh]h?https://lore.kernel.org/r/20171213194755.3409-1-mstaudt@suse.de}(hjhhhNhNubah}(h]h ]h"]h$]h&]refurijuh1jhjubeh}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubeh}(h]h ]h"]h$]h&]j@jAuh1jhhhMhjuhhubh)}(hContact: Sam Ravnborgh]hContact: Sam Ravnborg}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjuhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjuhhubeh}(h] bootsplashah ]h"] bootsplashah$]h&]uh1hhj:hhhhhMubh)}(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}(hjwhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM4hjsubah}(h]h ]h"]h$]h&]uh1jhjXhhhhhNubeh}(h]h ]h"]h$]h&]jjjhjjuh1jhjhhhhhM2ubh)}(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&]uh1hhhhM7hjhhubh)}(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>hjhhubh)}(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&]uh1hhhhMBhjhhubh)}(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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMFhjhhubh)}(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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMLhjhhubh)}(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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMOhjhhubh)}(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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMThjhhubh)}(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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMXhjhhubh)}(hContact: Hans de Goedeh]hContact: Hans de Goede}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM_hjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMahjhhubeh}(h]h](h#Contact: Javier Martinez Canillas <}(hjhhhNhNubj)}(hjavierm@redhat.comh]hjavierm@redhat.com}(hjhhhNhNubah}(h]h ]h"]h$]h&]refurimailto:javierm@redhat.comuh1jhjubh>}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMvhj%hhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMxhj%hhubeh}(h]Cbuffer-age-or-other-damage-accumulation-algorithm-for-buffer-damageah ]h"]Cbuffer age or other damage accumulation algorithm for buffer damageah$]h&]uh1hhj:hhhhhMdubh)}(hhh](h)}(h Querying errors from drm_syncobjh]h Querying errors from drm_syncobj}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhM{ubh)}(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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM}hjhhubh)}(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.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hThis was already improved by implementing the necessary kernel interface (patches are on the dri-devel mailing list) but adding support for that in the userspace stack is still missing.h]hThis was already improved by implementing the necessary kernel interface (patches are on the dri-devel mailing list) but adding support for that in the userspace stack is still missing.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(h)Contact: Christian König, Michel Dänzerh]h)Contact: Christian König, Michel Dänzer}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hLevel: Starterh]hLevel: Starter}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubeh}(h] querying-errors-from-drm-syncobjah ]h"] querying errors from drm_syncobjah$]h&]uh1hhj:hhhhhM{ubh)}(hhh]h)}(hDRM GPU Schedulerh]hDRM GPU Scheduler}(hj,hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj)hhhhhMubah}(h]drm-gpu-schedulerah ]h"]drm gpu schedulerah$]h&]uh1hhj:hhhhhMubeh}(h]amd-dc-display-driverah ]h"]amd dc display driverah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(h;Provide a universal successor for drm_sched_resubmit_jobs()h]h;Provide a universal successor for drm_sched_resubmit_jobs()}(hjMhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjJhhhhhMubh)}(hXdrm_sched_resubmit_jobs() is deprecated. Main reason being that it leads to reinitializing dma_fences. See that function's docu for details. The better approach for valid resubmissions by amdgpu and Xe is (apparently) to figure out which job (and, through association: which entity) caused the hang. Then, the job's buffer data, together with all other jobs' buffer data currently in the same hardware ring, must be invalidated. This can for example be done by overwriting it. amdgpu currently determines which jobs are in the ring and need to be overwritten by keeping copies of the job. Xe obtains that information by directly accessing drm_sched's pending_list.h]hXdrm_sched_resubmit_jobs() is deprecated. Main reason being that it leads to reinitializing dma_fences. See that function’s docu for details. The better approach for valid resubmissions by amdgpu and Xe is (apparently) to figure out which job (and, through association: which entity) caused the hang. Then, the job’s buffer data, together with all other jobs’ buffer data currently in the same hardware ring, must be invalidated. This can for example be done by overwriting it. amdgpu currently determines which jobs are in the ring and need to be overwritten by keeping copies of the job. Xe obtains that information by directly accessing drm_sched’s pending_list.}(hj[hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjJhhubh)}(hTasks:h]hTasks:}(hjihhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjJhhubj)}(hhh](j)}(himplement scheduler functionality through which the driver can obtain the information which *broken* jobs are currently in the hardware ring.h]h)}(himplement scheduler functionality through which the driver can obtain the information which *broken* jobs are currently in the hardware ring.h](h\implement scheduler functionality through which the driver can obtain the information which }(hj~hhhNhNubhemphasis)}(h*broken*h]hbroken}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhj~ubh) jobs are currently in the hardware ring.}(hj~hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjzubah}(h]h ]h"]h$]h&]uh1jhjwhhhhhNubj)}(hhSuch infrastructure would then typically be used in drm_sched_backend_ops.timedout_job(). Document that.h]h)}(hhSuch infrastructure would then typically be used in drm_sched_backend_ops.timedout_job(). Document that.h]hhSuch infrastructure would then typically be used in drm_sched_backend_ops.timedout_job(). Document that.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jhjwhhhhhNubj)}(hPort a driver as first user.h]h)}(hjh]hPort a driver as first user.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jhjwhhhhhNubj)}(hRDocument the new alternative in the docu of deprecated drm_sched_resubmit_jobs(). h]h)}(hQDocument the new alternative in the docu of deprecated drm_sched_resubmit_jobs().h]hQDocument the new alternative in the docu of deprecated drm_sched_resubmit_jobs().}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jhjwhhhhhNubeh}(h]h ]h"]h$]h&]jjjhjjuh1jhjJhhhhhMubj )}(hhh]j )}(hYContact: Christian König Philipp Stanner h](j )}(h4Contact: Christian König h](hContact: Christian König }(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1j hhhMhjubj )}(hhh]h)}(h#Philipp Stanner h](hPhilipp Stanner <}(hjhhhNhNubj)}(hphasta@kernel.orgh]hphasta@kernel.org}(hj'hhhNhNubah}(h]h ]h"]h$]h&]refurimailto:phasta@kernel.orguh1jhjubh>}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1j hjubeh}(h]h ]h"]h$]h&]uh1j hhhMhjubah}(h]h ]h"]h$]h&]uh1j hjJhhhhhNubh)}(hLevel: Advancedh]hLevel: Advanced}(hjShhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjJhhubeh}(h]9provide-a-universal-successor-for-drm-sched-resubmit-jobsah ]h"];provide a universal successor for drm_sched_resubmit_jobs()ah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(hAdd locking for runqueuesh]hAdd locking for runqueues}(hjlhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjihhhhhMubh)}(hXThere is an old FIXME by Sima in include/drm/gpu_scheduler.h. It details that struct drm_sched_rq is read at many places without any locks, not even with a READ_ONCE. At XDC 2025 no one could really tell why that is the case, whether locks are needed and whether they could be added. (But for real, that should probably be locked!). Check whether it's possible to add locks everywhere, and do so if yes.h]hXThere is an old FIXME by Sima in include/drm/gpu_scheduler.h. It details that struct drm_sched_rq is read at many places without any locks, not even with a READ_ONCE. At XDC 2025 no one could really tell why that is the case, whether locks are needed and whether they could be added. (But for real, that should probably be locked!). Check whether it’s possible to add locks everywhere, and do so if yes.}(hjzhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjihhubh)}(h,Contact: Philipp Stanner h](hContact: Philipp Stanner <}(hjhhhNhNubj)}(hphasta@kernel.orgh]hphasta@kernel.org}(hjhhhNhNubah}(h]h ]h"]h$]h&]refurimailto:phasta@kernel.orguh1jhjubh>}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjihhubh)}(hLevel: Intermediateh]hLevel: Intermediate}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjihhubeh}(h]add-locking-for-runqueuesah ]h"]add locking for runqueuesah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(h-Replace the lockless queue with a locked listh]h-Replace the lockless queue with a locked list}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubh)}(hqdrm_sched is the only user in the entire kernel of a special lockless queue, the spsc_queue. This queue utilizes:h]hqdrm_sched is the only user in the entire kernel of a special lockless queue, the spsc_queue. This queue utilizes:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubj)}(hhh](j)}(hpreempt_disable()h]h)}(hjh]hpreempt_disable()}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubj)}(hatomic instructionsh]h)}(hjh]hatomic instructions}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubj)}(hmemory barriersh]h)}(hjh]hmemory barriers}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubj)}(hACCESS_ONCE() h]h)}(h ACCESS_ONCE()h]h ACCESS_ONCE()}(hj+hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj'ubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubeh}(h]h ]h"]h$]h&]j@jAuh1jhhhMhjhhubh)}(h)whereas a conventional spinlock utilizes:h]h)whereas a conventional spinlock utilizes:}(hjEhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubj)}(hhh](j)}(hpreempt_disable()h]h)}(hjXh]hpreempt_disable()}(hjZhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjVubah}(h]h ]h"]h$]h&]uh1jhjShhhhhNubj)}(h41 atomic instruction for taking / releasing the lockh]h)}(hjoh]h41 atomic instruction for taking / releasing the lock}(hjqhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjmubah}(h]h ]h"]h$]h&]uh1jhjShhhhhNubj)}(hmemory barriers h]h)}(hmemory barriersh]hmemory barriers}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jhjShhhhhNubeh}(h]h ]h"]h$]h&]j@jAuh1jhhhMhjhhubh)}(hMoreover, drm_sched_entity_push_job(), the only user of spsc_queue_push(), has to take a lock in some situations anyways and calls to it are often serialized with a driver lock.h]hMoreover, drm_sched_entity_push_job(), the only user of spsc_queue_push(), has to take a lock in some situations anyways and calls to it are often serialized with a driver lock.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hXIt is, thus, highly questionable whether the lockless queue grants any advantage at all. Considering that its internals are not well documented and its correctness is not formally proven, it seems desirable to replace the queue with a mere list or hlist that is protected by a spinlock.h]hXIt is, thus, highly questionable whether the lockless queue grants any advantage at all. Considering that its internals are not well documented and its correctness is not formally proven, it seems desirable to replace the queue with a mere list or hlist that is protected by a spinlock.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hTasks:h]hTasks:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubj)}(hhh](j)}(hzReplace the spsc_queue in drm/sched (and those who might access the scheduler's internal queue) with a spinlock + (h)list.h]h)}(hzReplace the spsc_queue in drm/sched (and those who might access the scheduler's internal queue) with a spinlock + (h)list.h]h|Replace the spsc_queue in drm/sched (and those who might access the scheduler’s internal queue) with a spinlock + (h)list.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubj)}(h}Ideally, check with some micro benchmarks and real world tests (preferably with amdgpu) for relevant performance regressions.h]h)}(h}Ideally, check with some micro benchmarks and real world tests (preferably with amdgpu) for relevant performance regressions.h]h}Ideally, check with some micro benchmarks and real world tests (preferably with amdgpu) for relevant performance regressions.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubj)}(h2Remove the spsc_queue from the kernel altogether. h]h)}(h1Remove the spsc_queue from the kernel altogether.h]h1Remove the spsc_queue from the kernel altogether.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubeh}(h]h ]h"]h$]h&]j@jAuh1jhhhMhjhhubh)}(hContact:h]hContact:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubj)}(hhh](j)}(h#Philipp Stanner h]h)}(hj0h](hPhilipp Stanner <}(hj2hhhNhNubj)}(hphasta@kernel.orgh]hphasta@kernel.org}(hj9hhhNhNubah}(h]h ]h"]h$]h&]refurimailto:phasta@kernel.orguh1jhj2ubh>}(hj2hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhj.ubah}(h]h ]h"]h$]h&]uh1jhj+hhhhhNubj)}(h,Christian König h]h)}(h+Christian König h](hChristian König <}(hj]hhhNhNubj)}(hchristian.koenig@amd.comh]hchristian.koenig@amd.com}(hjehhhNhNubah}(h]h ]h"]h$]h&]refurimailto:christian.koenig@amd.comuh1jhj]ubh>}(hj]hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjYubah}(h]h ]h"]h$]h&]uh1jhj+hhhhhNubeh}(h]h ]h"]h$]h&]j@jAuh1jhhhMhjhhubh)}(hLevel: Beginnerh]hLevel: Beginner}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hhh]h)}(h Outside DRMh]h Outside DRM}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubah}(h] outside-drmah ]h"] outside drmah$]h&]uh1hhjhhhhhMubeh}(h]-replace-the-lockless-queue-with-a-locked-listah ]h"]-replace the lockless queue with a locked listah$]h&]uh1hhhhhhhhMubh)}(hhh](h)}(hConvert fbdev drivers to DRMh]hConvert fbdev drivers to DRM}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubh)}(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&]uh1hhhhMhjhhubh)}(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&]uh1hhhhMhjhhubh)}(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 }(hjhhhNhNubjn)}(h[4]_h]h4}(hjhhhNhNubah}(h]id7ah ]h"]h$]h&]hid10jjuh1jmhjjKubhX9. 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 }(hjhhhNhNubjn)}(h[4]_h]h4}(hjhhhNhNubah}(h]id8ah ]h"]h$]h&]hjjjuh1jmhjjKubh(, as well as a tutorial of this process }(hjhhhNhNubjn)}(h[5]_h]h5}(hjhhhNhNubah}(h]id9ah ]h"]h$]h&]hid11jjuh1jmhjjKubhC. The result is a primitive DRM driver that can run X11 and Weston.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjhhubj)}(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.deuh1jhjubh>}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hLevel: Advancedh]hLevel: Advanced}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubeh}(h]convert-fbdev-drivers-to-drmah ]h"]convert fbdev drivers to drmah$]h&]uh1hhhhhhhhMubeh}(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]joa2]ja3]ja4](jje5]jaurefids}h]hasnameids}(jhjjj^j[jVjSjjjjjCj@jjjj~j+jj\jjjjcj`jjjjjjjojljjj jj|jyj(j%jjjJ jG j j j j j j jF jC j j j j jY jV j j j j j<j9jjjjj`j]j`j]jjj%j"j j jjjjjjjjjJjGjjjjjjj'j$jjj7j4j/j,jGjDj j j"jjjj&j#j?j<jfjcjjjjjjjjjajjj%u nametypes}(jjj^jVjjjCjjj+j\jjcjjjjojj j|j(jjJ j j j jF j j jY j j j<jjj`j`jj%j jjjjjJjjjj'jj7j/jGj j"jj&j?jfjjjjjajuh}(hhjhj[hjSj@jjajjj@jjjFjyjojjjjj~jjjjj.jjj`jjjfjjjjjlj!jjrjjjyj j%jjj+jG jj jM j j j j jC j j jI j j jV j j j\ j j j9j jj?jjj]jj]jWjjj"jj jcjjjjjjjjjGjjjjjMjjj$jjj*j4jj,jjDj:j jujjjj%j#jj<j)jcjJjjijjjjjjjjj jj jjj4j%jdu footnote_refs}(jC]joajE]jajG]jajI](jjejK]jau citation_refs} autofootnotes]autofootnote_refs]symbol_footnotes]symbol_footnote_refs] footnotes](jjj.j4jde 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.}hj|sbah}(h]h ]h"]h$]h&]uh1hhjyubah}(h]h ]h"]h$]h&]levelKtypeINFOsourcehÌlineKuh1jwuba transformerN include_log] decorationNhhub.