[PATCH 1/2] drm/todo: Remove i915 device_link task

[PATCH 1/2] drm/todo: Remove i915 device_link task

[Daniel Vetter]

Done with

commit aef9f33b7658a7489f71df5d6e6ecb47f2521e8a
Author: Imre Deak <imre.deak@intel.com>
Date:   Tue Oct 23 17:43:10 2018 +0300

    drm/i915: Ensure proper HDA suspend/resume ordering with a device link

Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 Documentation/gpu/todo.rst | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 23b3a67794ba..9ac102922712 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -438,13 +438,6 @@ See drivers/gpu/drm/amd/display/TODO for tasks.
 
 Contact: Harry Wentland, Alex Deucher
 
-i915
-----
-
-- Our early/late pm callbacks could be removed in favour of using
-  device_link_add to model the dependency between i915 and snd_had. See
-  https://dri.freedesktop.org/docs/drm/driver-api/device_link.html
-
 Bootsplash
 ==========
 
-- 
2.23.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/todo: Add levels

[Daniel Vetter]

Should help new people pick suitable tasks.

Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Sean Paul <sean@poorly.run>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 Documentation/gpu/todo.rst | 73 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 9ac102922712..73c51b5a0997 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -7,6 +7,22 @@ TODO list
 This section contains a list of smaller janitorial tasks in the kernel DRM
 graphics subsystem useful as newbie projects. Or for slow rainy days.
 
+Difficulty
+----------
+
+To make it easier task are categorized into different levels:
+
+Starter: Good tasks to get started with the DRM subsystem.
+
+Intermediate: Tasks which need some experience with working in the DRM
+subsystem, or some specific GPU/display graphics knowledge. For debugging issue
+it's good to have the relevant hardware (or a virtual driver set up) available
+for testing.
+
+Advanced: Tricky tasks that need fairly good understanding of the DRM subsystem
+and graphics topics. Generally need the relevant hardware for development and
+testing.
+
 Subsystem-wide refactorings
 ===========================
 
@@ -20,6 +36,8 @@ implementations), and then remove it.
 
 Contact: Daniel Vetter, respective driver maintainers
 
+Level: Intermediate
+
 Convert existing KMS drivers to atomic modesetting
 --------------------------------------------------
 
@@ -38,6 +56,8 @@ do by directly using the new atomic helper driver callbacks.
 
 Contact: Daniel Vetter, respective driver maintainers
 
+Level: Advanced
+
 Clean up the clipped coordination confusion around planes
 ---------------------------------------------------------
 
@@ -50,6 +70,8 @@ helpers.
 
 Contact: Ville Syrjälä, Daniel Vetter, driver maintainers
 
+Level: Advanced
+
 Convert early atomic drivers to async commit helpers
 ----------------------------------------------------
 
@@ -63,6 +85,8 @@ events for atomic commits correctly. But fixing these bugs is good anyway.
 
 Contact: Daniel Vetter, respective driver maintainers
 
+Level: Advanced
+
 Fallout from atomic KMS
 -----------------------
 
@@ -91,6 +115,8 @@ interfaces to fix these issues:
 
 Contact: Daniel Vetter
 
+Level: Intermediate
+
 Get rid of dev->struct_mutex from GEM drivers
 ---------------------------------------------
 
@@ -114,6 +140,8 @@ fine-grained per-buffer object and per-context lockings scheme. Currently only t
 
 Contact: Daniel Vetter, respective driver maintainers
 
+Level: Advanced
+
 Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent
 ----------------------------------------------------------------------------
 
@@ -129,6 +157,8 @@ are better.
 
 Contact: Sean Paul, Maintainer of the driver you plan to convert
 
+Level: Starter
+
 Convert drivers to use simple modeset suspend/resume
 ----------------------------------------------------
 
@@ -139,6 +169,8 @@ of the atomic suspend/resume code in older atomic modeset drivers.
 
 Contact: Maintainer of the driver you plan to convert
 
+Level: Intermediate
+
 Convert drivers to use drm_fb_helper_fbdev_setup/teardown()
 -----------------------------------------------------------
 
@@ -157,6 +189,8 @@ probably use drm_fb_helper_fbdev_teardown().
 
 Contact: Maintainer of the driver you plan to convert
 
+Level: Intermediate
+
 Clean up mmap forwarding
 ------------------------
 
@@ -166,6 +200,8 @@ There's drm_gem_prime_mmap() for this now, but still needs to be rolled out.
 
 Contact: Daniel Vetter
 
+Level: Intermediate
+
 Generic fbdev defio support
 ---------------------------
 
@@ -196,6 +232,8 @@ Might be good to also have some igt testcases for this.
 
 Contact: Daniel Vetter, Noralf Tronnes
 
+Level: Advanced
+
 idr_init_base()
 ---------------
 
@@ -206,6 +244,8 @@ efficient.
 
 Contact: Daniel Vetter
 
+Level: Starter
+
 struct drm_gem_object_funcs
 ---------------------------
 
@@ -216,6 +256,8 @@ We also need a 2nd version of the CMA define that doesn't require the
 vmapping to be present (different hook for prime importing). Plus this needs to
 be rolled out to all drivers using their own implementations, too.
 
+Level: Intermediate
+
 Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate
 ---------------------------------------------------------
 
@@ -231,6 +273,8 @@ As a reference, take a look at the conversions already completed in drm core.
 
 Contact: Sean Paul, respective driver maintainers
 
+Level: Starter
+
 Rename CMA helpers to DMA helpers
 ---------------------------------
 
@@ -241,6 +285,9 @@ no one knows what that means) since underneath they just use dma_alloc_coherent.
 
 Contact: Laurent Pinchart, Daniel Vetter
 
+Level: Intermediate (mostly because it is a huge tasks without good partial
+milestones, not technically itself that challenging)
+
 Convert direct mode.vrefresh accesses to use drm_mode_vrefresh()
 ----------------------------------------------------------------
 
@@ -259,6 +306,8 @@ drm_display_mode to avoid future use.
 
 Contact: Sean Paul
 
+Level: Starter
+
 Remove drm_display_mode.hsync
 -----------------------------
 
@@ -269,6 +318,8 @@ it to use drm_mode_hsync() instead.
 
 Contact: Sean Paul
 
+Level: Starter
+
 drm_fb_helper tasks
 -------------------
 
@@ -284,6 +335,8 @@ drm_fb_helper tasks
   removed: drm_fb_helper_single_add_all_connectors(),
   drm_fb_helper_add_one_connector() and drm_fb_helper_remove_one_connector().
 
+Level: Intermediate
+
 connector register/unregister fixes
 -----------------------------------
 
@@ -296,6 +349,8 @@ connector register/unregister fixes
   drm_dp_aux_init, and moving the actual registering into a late_register
   callback as recommended in the kerneldoc.
 
+Level: Intermediate
+
 Core refactorings
 =================
 
@@ -338,6 +393,8 @@ This is a really varied tasks with lots of little bits and pieces:
 
 Contact: Daniel Vetter
 
+Level: Advanced
+
 Clean up the debugfs support
 ----------------------------
 
@@ -367,6 +424,8 @@ There's a bunch of issues with it:
 
 Contact: Daniel Vetter
 
+Level: Intermediate
+
 KMS cleanups
 ------------
 
@@ -382,6 +441,8 @@ Some of these date from the very introduction of KMS in 2008 ...
   end, for which we could add drm_*_cleanup_kfree(). And then there's the (for
   historical reasons) misnamed drm_primary_helper_destroy() function.
 
+Level: Intermediate
+
 Better Testing
 ==============
 
@@ -390,6 +451,8 @@ Enable trinity for DRM
 
 And fix up the fallout. Should be really interesting ...
 
+Level: Advanced
+
 Make KMS tests in i-g-t generic
 -------------------------------
 
@@ -403,6 +466,8 @@ 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.
 
+Level: Advanced
+
 Extend virtual test driver (VKMS)
 ---------------------------------
 
@@ -412,6 +477,8 @@ fit the available time.
 
 Contact: Daniel Vetter
 
+Level: See details
+
 Backlight Refactoring
 ---------------------
 
@@ -425,6 +492,8 @@ Plan to fix this:
 
 Contact: Daniel Vetter
 
+Level: Intermediate
+
 Driver Specific
 ===============
 
@@ -453,6 +522,8 @@ for fbdev.
 
 Contact: Sam Ravnborg
 
+Level: Advanced
+
 Outside DRM
 ===========
 
@@ -482,3 +553,5 @@ and Weston.
  - [2] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c
 
 Contact: Thomas Zimmermann <tzimmermann@suse.de>
+
+Level: Advanced
-- 
2.23.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/todo: Add levels

[Sean Paul]

On Tue, Oct 22, 2019 at 05:25:30PM +0200, Daniel Vetter wrote:
> Should help new people pick suitable tasks.
> 
> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
> Cc: Manasi Navare <manasi.d.navare@intel.com>
> Cc: Sean Paul <sean@poorly.run>

Reviewed-by: Sean Paul <sean@poorly.run>

> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  Documentation/gpu/todo.rst | 73 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 73 insertions(+)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 9ac102922712..73c51b5a0997 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -7,6 +7,22 @@ TODO list
>  This section contains a list of smaller janitorial tasks in the kernel DRM
>  graphics subsystem useful as newbie projects. Or for slow rainy days.
>  
> +Difficulty
> +----------
> +
> +To make it easier task are categorized into different levels:
> +
> +Starter: Good tasks to get started with the DRM subsystem.
> +
> +Intermediate: Tasks which need some experience with working in the DRM
> +subsystem, or some specific GPU/display graphics knowledge. For debugging issue
> +it's good to have the relevant hardware (or a virtual driver set up) available
> +for testing.
> +
> +Advanced: Tricky tasks that need fairly good understanding of the DRM subsystem
> +and graphics topics. Generally need the relevant hardware for development and
> +testing.
> +
>  Subsystem-wide refactorings
>  ===========================
>  
> @@ -20,6 +36,8 @@ implementations), and then remove it.
>  
>  Contact: Daniel Vetter, respective driver maintainers
>  
> +Level: Intermediate
> +
>  Convert existing KMS drivers to atomic modesetting
>  --------------------------------------------------
>  
> @@ -38,6 +56,8 @@ do by directly using the new atomic helper driver callbacks.
>  
>  Contact: Daniel Vetter, respective driver maintainers
>  
> +Level: Advanced
> +
>  Clean up the clipped coordination confusion around planes
>  ---------------------------------------------------------
>  
> @@ -50,6 +70,8 @@ helpers.
>  
>  Contact: Ville Syrjälä, Daniel Vetter, driver maintainers
>  
> +Level: Advanced
> +
>  Convert early atomic drivers to async commit helpers
>  ----------------------------------------------------
>  
> @@ -63,6 +85,8 @@ events for atomic commits correctly. But fixing these bugs is good anyway.
>  
>  Contact: Daniel Vetter, respective driver maintainers
>  
> +Level: Advanced
> +
>  Fallout from atomic KMS
>  -----------------------
>  
> @@ -91,6 +115,8 @@ interfaces to fix these issues:
>  
>  Contact: Daniel Vetter
>  
> +Level: Intermediate
> +
>  Get rid of dev->struct_mutex from GEM drivers
>  ---------------------------------------------
>  
> @@ -114,6 +140,8 @@ fine-grained per-buffer object and per-context lockings scheme. Currently only t
>  
>  Contact: Daniel Vetter, respective driver maintainers
>  
> +Level: Advanced
> +
>  Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent
>  ----------------------------------------------------------------------------
>  
> @@ -129,6 +157,8 @@ are better.
>  
>  Contact: Sean Paul, Maintainer of the driver you plan to convert
>  
> +Level: Starter
> +
>  Convert drivers to use simple modeset suspend/resume
>  ----------------------------------------------------
>  
> @@ -139,6 +169,8 @@ of the atomic suspend/resume code in older atomic modeset drivers.
>  
>  Contact: Maintainer of the driver you plan to convert
>  
> +Level: Intermediate
> +
>  Convert drivers to use drm_fb_helper_fbdev_setup/teardown()
>  -----------------------------------------------------------
>  
> @@ -157,6 +189,8 @@ probably use drm_fb_helper_fbdev_teardown().
>  
>  Contact: Maintainer of the driver you plan to convert
>  
> +Level: Intermediate
> +
>  Clean up mmap forwarding
>  ------------------------
>  
> @@ -166,6 +200,8 @@ There's drm_gem_prime_mmap() for this now, but still needs to be rolled out.
>  
>  Contact: Daniel Vetter
>  
> +Level: Intermediate
> +
>  Generic fbdev defio support
>  ---------------------------
>  
> @@ -196,6 +232,8 @@ Might be good to also have some igt testcases for this.
>  
>  Contact: Daniel Vetter, Noralf Tronnes
>  
> +Level: Advanced
> +
>  idr_init_base()
>  ---------------
>  
> @@ -206,6 +244,8 @@ efficient.
>  
>  Contact: Daniel Vetter
>  
> +Level: Starter
> +
>  struct drm_gem_object_funcs
>  ---------------------------
>  
> @@ -216,6 +256,8 @@ We also need a 2nd version of the CMA define that doesn't require the
>  vmapping to be present (different hook for prime importing). Plus this needs to
>  be rolled out to all drivers using their own implementations, too.
>  
> +Level: Intermediate
> +
>  Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate
>  ---------------------------------------------------------
>  
> @@ -231,6 +273,8 @@ As a reference, take a look at the conversions already completed in drm core.
>  
>  Contact: Sean Paul, respective driver maintainers
>  
> +Level: Starter
> +
>  Rename CMA helpers to DMA helpers
>  ---------------------------------
>  
> @@ -241,6 +285,9 @@ no one knows what that means) since underneath they just use dma_alloc_coherent.
>  
>  Contact: Laurent Pinchart, Daniel Vetter
>  
> +Level: Intermediate (mostly because it is a huge tasks without good partial
> +milestones, not technically itself that challenging)
> +
>  Convert direct mode.vrefresh accesses to use drm_mode_vrefresh()
>  ----------------------------------------------------------------
>  
> @@ -259,6 +306,8 @@ drm_display_mode to avoid future use.
>  
>  Contact: Sean Paul
>  
> +Level: Starter
> +
>  Remove drm_display_mode.hsync
>  -----------------------------
>  
> @@ -269,6 +318,8 @@ it to use drm_mode_hsync() instead.
>  
>  Contact: Sean Paul
>  
> +Level: Starter
> +
>  drm_fb_helper tasks
>  -------------------
>  
> @@ -284,6 +335,8 @@ drm_fb_helper tasks
>    removed: drm_fb_helper_single_add_all_connectors(),
>    drm_fb_helper_add_one_connector() and drm_fb_helper_remove_one_connector().
>  
> +Level: Intermediate
> +
>  connector register/unregister fixes
>  -----------------------------------
>  
> @@ -296,6 +349,8 @@ connector register/unregister fixes
>    drm_dp_aux_init, and moving the actual registering into a late_register
>    callback as recommended in the kerneldoc.
>  
> +Level: Intermediate
> +
>  Core refactorings
>  =================
>  
> @@ -338,6 +393,8 @@ This is a really varied tasks with lots of little bits and pieces:
>  
>  Contact: Daniel Vetter
>  
> +Level: Advanced
> +
>  Clean up the debugfs support
>  ----------------------------
>  
> @@ -367,6 +424,8 @@ There's a bunch of issues with it:
>  
>  Contact: Daniel Vetter
>  
> +Level: Intermediate
> +
>  KMS cleanups
>  ------------
>  
> @@ -382,6 +441,8 @@ Some of these date from the very introduction of KMS in 2008 ...
>    end, for which we could add drm_*_cleanup_kfree(). And then there's the (for
>    historical reasons) misnamed drm_primary_helper_destroy() function.
>  
> +Level: Intermediate
> +
>  Better Testing
>  ==============
>  
> @@ -390,6 +451,8 @@ Enable trinity for DRM
>  
>  And fix up the fallout. Should be really interesting ...
>  
> +Level: Advanced
> +
>  Make KMS tests in i-g-t generic
>  -------------------------------
>  
> @@ -403,6 +466,8 @@ 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.
>  
> +Level: Advanced
> +
>  Extend virtual test driver (VKMS)
>  ---------------------------------
>  
> @@ -412,6 +477,8 @@ fit the available time.
>  
>  Contact: Daniel Vetter
>  
> +Level: See details
> +
>  Backlight Refactoring
>  ---------------------
>  
> @@ -425,6 +492,8 @@ Plan to fix this:
>  
>  Contact: Daniel Vetter
>  
> +Level: Intermediate
> +
>  Driver Specific
>  ===============
>  
> @@ -453,6 +522,8 @@ for fbdev.
>  
>  Contact: Sam Ravnborg
>  
> +Level: Advanced
> +
>  Outside DRM
>  ===========
>  
> @@ -482,3 +553,5 @@ and Weston.
>   - [2] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c
>  
>  Contact: Thomas Zimmermann <tzimmermann@suse.de>
> +
> +Level: Advanced
> -- 
> 2.23.0
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/todo: Add levels

[Thomas Zimmermann]

[-- Attachment #1.1.1: Type: text/plain, Size: 9366 bytes --]

Hi

Am 22.10.19 um 17:25 schrieb Daniel Vetter:
> Should help new people pick suitable tasks.
> 
> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
> Cc: Manasi Navare <manasi.d.navare@intel.com>
> Cc: Sean Paul <sean@poorly.run>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  Documentation/gpu/todo.rst | 73 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 73 insertions(+)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 9ac102922712..73c51b5a0997 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -7,6 +7,22 @@ TODO list
>  This section contains a list of smaller janitorial tasks in the kernel DRM
>  graphics subsystem useful as newbie projects. Or for slow rainy days.
>  
> +Difficulty
> +----------
> +
> +To make it easier task are categorized into different levels:
> +
> +Starter: Good tasks to get started with the DRM subsystem.
> +
> +Intermediate: Tasks which need some experience with working in the DRM
> +subsystem, or some specific GPU/display graphics knowledge. For debugging issue
> +it's good to have the relevant hardware (or a virtual driver set up) available
> +for testing.
> +
> +Advanced: Tricky tasks that need fairly good understanding of the DRM subsystem
> +and graphics topics. Generally need the relevant hardware for development and
> +testing.

I like this idea.

  Acked-by: Thomas Zimmermann <tzimmermann@suse.de>

But please see my comment further below.

> +
>  Subsystem-wide refactorings
>  ===========================
>  
> @@ -20,6 +36,8 @@ implementations), and then remove it.
>  
>  Contact: Daniel Vetter, respective driver maintainers
>  
> +Level: Intermediate
> +
>  Convert existing KMS drivers to atomic modesetting
>  --------------------------------------------------
>  
> @@ -38,6 +56,8 @@ do by directly using the new atomic helper driver callbacks.
>  
>  Contact: Daniel Vetter, respective driver maintainers
>  
> +Level: Advanced
> +
>  Clean up the clipped coordination confusion around planes
>  ---------------------------------------------------------
>  
> @@ -50,6 +70,8 @@ helpers.
>  
>  Contact: Ville Syrjälä, Daniel Vetter, driver maintainers
>  
> +Level: Advanced
> +
>  Convert early atomic drivers to async commit helpers
>  ----------------------------------------------------
>  
> @@ -63,6 +85,8 @@ events for atomic commits correctly. But fixing these bugs is good anyway.
>  
>  Contact: Daniel Vetter, respective driver maintainers
>  
> +Level: Advanced
> +
>  Fallout from atomic KMS
>  -----------------------
>  
> @@ -91,6 +115,8 @@ interfaces to fix these issues:
>  
>  Contact: Daniel Vetter
>  
> +Level: Intermediate
> +
>  Get rid of dev->struct_mutex from GEM drivers
>  ---------------------------------------------
>  
> @@ -114,6 +140,8 @@ fine-grained per-buffer object and per-context lockings scheme. Currently only t
>  
>  Contact: Daniel Vetter, respective driver maintainers
>  
> +Level: Advanced
> +
>  Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent
>  ----------------------------------------------------------------------------
>  
> @@ -129,6 +157,8 @@ are better.
>  
>  Contact: Sean Paul, Maintainer of the driver you plan to convert
>  
> +Level: Starter
> +
>  Convert drivers to use simple modeset suspend/resume
>  ----------------------------------------------------
>  
> @@ -139,6 +169,8 @@ of the atomic suspend/resume code in older atomic modeset drivers.
>  
>  Contact: Maintainer of the driver you plan to convert
>  
> +Level: Intermediate
> +
>  Convert drivers to use drm_fb_helper_fbdev_setup/teardown()
>  -----------------------------------------------------------
>  
> @@ -157,6 +189,8 @@ probably use drm_fb_helper_fbdev_teardown().
>  
>  Contact: Maintainer of the driver you plan to convert
>  
> +Level: Intermediate
> +
>  Clean up mmap forwarding
>  ------------------------
>  
> @@ -166,6 +200,8 @@ There's drm_gem_prime_mmap() for this now, but still needs to be rolled out.
>  
>  Contact: Daniel Vetter
>  
> +Level: Intermediate
> +
>  Generic fbdev defio support
>  ---------------------------
>  
> @@ -196,6 +232,8 @@ Might be good to also have some igt testcases for this.
>  
>  Contact: Daniel Vetter, Noralf Tronnes
>  
> +Level: Advanced
> +
>  idr_init_base()
>  ---------------
>  
> @@ -206,6 +244,8 @@ efficient.
>  
>  Contact: Daniel Vetter
>  
> +Level: Starter
> +
>  struct drm_gem_object_funcs
>  ---------------------------
>  
> @@ -216,6 +256,8 @@ We also need a 2nd version of the CMA define that doesn't require the
>  vmapping to be present (different hook for prime importing). Plus this needs to
>  be rolled out to all drivers using their own implementations, too.
>  
> +Level: Intermediate
> +
>  Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate
>  ---------------------------------------------------------
>  
> @@ -231,6 +273,8 @@ As a reference, take a look at the conversions already completed in drm core.
>  
>  Contact: Sean Paul, respective driver maintainers
>  
> +Level: Starter
> +
>  Rename CMA helpers to DMA helpers
>  ---------------------------------
>  
> @@ -241,6 +285,9 @@ no one knows what that means) since underneath they just use dma_alloc_coherent.
>  
>  Contact: Laurent Pinchart, Daniel Vetter
>  
> +Level: Intermediate (mostly because it is a huge tasks without good partial
> +milestones, not technically itself that challenging)
> +
>  Convert direct mode.vrefresh accesses to use drm_mode_vrefresh()
>  ----------------------------------------------------------------
>  
> @@ -259,6 +306,8 @@ drm_display_mode to avoid future use.
>  
>  Contact: Sean Paul
>  
> +Level: Starter
> +
>  Remove drm_display_mode.hsync
>  -----------------------------
>  
> @@ -269,6 +318,8 @@ it to use drm_mode_hsync() instead.
>  
>  Contact: Sean Paul
>  
> +Level: Starter
> +
>  drm_fb_helper tasks
>  -------------------
>  
> @@ -284,6 +335,8 @@ drm_fb_helper tasks
>    removed: drm_fb_helper_single_add_all_connectors(),
>    drm_fb_helper_add_one_connector() and drm_fb_helper_remove_one_connector().
>  
> +Level: Intermediate
> +
>  connector register/unregister fixes
>  -----------------------------------
>  
> @@ -296,6 +349,8 @@ connector register/unregister fixes
>    drm_dp_aux_init, and moving the actual registering into a late_register
>    callback as recommended in the kerneldoc.
>  
> +Level: Intermediate
> +
>  Core refactorings
>  =================
>  
> @@ -338,6 +393,8 @@ This is a really varied tasks with lots of little bits and pieces:
>  
>  Contact: Daniel Vetter
>  
> +Level: Advanced
> +
>  Clean up the debugfs support
>  ----------------------------
>  
> @@ -367,6 +424,8 @@ There's a bunch of issues with it:
>  
>  Contact: Daniel Vetter
>  
> +Level: Intermediate
> +
>  KMS cleanups
>  ------------
>  
> @@ -382,6 +441,8 @@ Some of these date from the very introduction of KMS in 2008 ...
>    end, for which we could add drm_*_cleanup_kfree(). And then there's the (for
>    historical reasons) misnamed drm_primary_helper_destroy() function.
>  
> +Level: Intermediate
> +
>  Better Testing
>  ==============
>  
> @@ -390,6 +451,8 @@ Enable trinity for DRM
>  
>  And fix up the fallout. Should be really interesting ...
>  
> +Level: Advanced
> +
>  Make KMS tests in i-g-t generic
>  -------------------------------
>  
> @@ -403,6 +466,8 @@ 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.
>  
> +Level: Advanced
> +
>  Extend virtual test driver (VKMS)
>  ---------------------------------
>  
> @@ -412,6 +477,8 @@ fit the available time.
>  
>  Contact: Daniel Vetter
>  
> +Level: See details
> +
>  Backlight Refactoring
>  ---------------------
>  
> @@ -425,6 +492,8 @@ Plan to fix this:
>  
>  Contact: Daniel Vetter
>  
> +Level: Intermediate
> +
>  Driver Specific
>  ===============
>  
> @@ -453,6 +522,8 @@ for fbdev.
>  
>  Contact: Sam Ravnborg
>  
> +Level: Advanced
> +
>  Outside DRM
>  ===========
>  
> @@ -482,3 +553,5 @@ and Weston.
>   - [2] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c
>  
>  Contact: Thomas Zimmermann <tzimmermann@suse.de>
> +
> +Level: Advanced
> 

Hmm, it fits the definition of 'Advanced' but is it an advanced task?
With all the helpers in DRM, fbconv, and lots of drivers to copy from,
it mostly comes down to refactoring. I'd have classified this as starter
to intermediate.

In my case, I did my first steps in the DRM code by hacking up a driver
for an ancient SiS chipset. [1] I found that much easier than working on
the DRM core.

Best regards
Thomas

[1] https://gitlab.freedesktop.org/tzimmermann/linux/tree/sisvga


-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/todo: Add levels

[Daniel Vetter]

On Tue, Oct 22, 2019 at 7:33 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>
> Hi
>
> Am 22.10.19 um 17:25 schrieb Daniel Vetter:
> > Should help new people pick suitable tasks.
> >
> > Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
> > Cc: Manasi Navare <manasi.d.navare@intel.com>
> > Cc: Sean Paul <sean@poorly.run>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  Documentation/gpu/todo.rst | 73 ++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 73 insertions(+)
> >
> > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > index 9ac102922712..73c51b5a0997 100644
> > --- a/Documentation/gpu/todo.rst
> > +++ b/Documentation/gpu/todo.rst
> > @@ -7,6 +7,22 @@ TODO list
> >  This section contains a list of smaller janitorial tasks in the kernel DRM
> >  graphics subsystem useful as newbie projects. Or for slow rainy days.
> >
> > +Difficulty
> > +----------
> > +
> > +To make it easier task are categorized into different levels:
> > +
> > +Starter: Good tasks to get started with the DRM subsystem.
> > +
> > +Intermediate: Tasks which need some experience with working in the DRM
> > +subsystem, or some specific GPU/display graphics knowledge. For debugging issue
> > +it's good to have the relevant hardware (or a virtual driver set up) available
> > +for testing.
> > +
> > +Advanced: Tricky tasks that need fairly good understanding of the DRM subsystem
> > +and graphics topics. Generally need the relevant hardware for development and
> > +testing.
>
> I like this idea.
>
>   Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
>
> But please see my comment further below.
>
> > +
> >  Subsystem-wide refactorings
> >  ===========================
> >
> > @@ -20,6 +36,8 @@ implementations), and then remove it.
> >
> >  Contact: Daniel Vetter, respective driver maintainers
> >
> > +Level: Intermediate
> > +
> >  Convert existing KMS drivers to atomic modesetting
> >  --------------------------------------------------
> >
> > @@ -38,6 +56,8 @@ do by directly using the new atomic helper driver callbacks.
> >
> >  Contact: Daniel Vetter, respective driver maintainers
> >
> > +Level: Advanced
> > +
> >  Clean up the clipped coordination confusion around planes
> >  ---------------------------------------------------------
> >
> > @@ -50,6 +70,8 @@ helpers.
> >
> >  Contact: Ville Syrjälä, Daniel Vetter, driver maintainers
> >
> > +Level: Advanced
> > +
> >  Convert early atomic drivers to async commit helpers
> >  ----------------------------------------------------
> >
> > @@ -63,6 +85,8 @@ events for atomic commits correctly. But fixing these bugs is good anyway.
> >
> >  Contact: Daniel Vetter, respective driver maintainers
> >
> > +Level: Advanced
> > +
> >  Fallout from atomic KMS
> >  -----------------------
> >
> > @@ -91,6 +115,8 @@ interfaces to fix these issues:
> >
> >  Contact: Daniel Vetter
> >
> > +Level: Intermediate
> > +
> >  Get rid of dev->struct_mutex from GEM drivers
> >  ---------------------------------------------
> >
> > @@ -114,6 +140,8 @@ fine-grained per-buffer object and per-context lockings scheme. Currently only t
> >
> >  Contact: Daniel Vetter, respective driver maintainers
> >
> > +Level: Advanced
> > +
> >  Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent
> >  ----------------------------------------------------------------------------
> >
> > @@ -129,6 +157,8 @@ are better.
> >
> >  Contact: Sean Paul, Maintainer of the driver you plan to convert
> >
> > +Level: Starter
> > +
> >  Convert drivers to use simple modeset suspend/resume
> >  ----------------------------------------------------
> >
> > @@ -139,6 +169,8 @@ of the atomic suspend/resume code in older atomic modeset drivers.
> >
> >  Contact: Maintainer of the driver you plan to convert
> >
> > +Level: Intermediate
> > +
> >  Convert drivers to use drm_fb_helper_fbdev_setup/teardown()
> >  -----------------------------------------------------------
> >
> > @@ -157,6 +189,8 @@ probably use drm_fb_helper_fbdev_teardown().
> >
> >  Contact: Maintainer of the driver you plan to convert
> >
> > +Level: Intermediate
> > +
> >  Clean up mmap forwarding
> >  ------------------------
> >
> > @@ -166,6 +200,8 @@ There's drm_gem_prime_mmap() for this now, but still needs to be rolled out.
> >
> >  Contact: Daniel Vetter
> >
> > +Level: Intermediate
> > +
> >  Generic fbdev defio support
> >  ---------------------------
> >
> > @@ -196,6 +232,8 @@ Might be good to also have some igt testcases for this.
> >
> >  Contact: Daniel Vetter, Noralf Tronnes
> >
> > +Level: Advanced
> > +
> >  idr_init_base()
> >  ---------------
> >
> > @@ -206,6 +244,8 @@ efficient.
> >
> >  Contact: Daniel Vetter
> >
> > +Level: Starter
> > +
> >  struct drm_gem_object_funcs
> >  ---------------------------
> >
> > @@ -216,6 +256,8 @@ We also need a 2nd version of the CMA define that doesn't require the
> >  vmapping to be present (different hook for prime importing). Plus this needs to
> >  be rolled out to all drivers using their own implementations, too.
> >
> > +Level: Intermediate
> > +
> >  Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate
> >  ---------------------------------------------------------
> >
> > @@ -231,6 +273,8 @@ As a reference, take a look at the conversions already completed in drm core.
> >
> >  Contact: Sean Paul, respective driver maintainers
> >
> > +Level: Starter
> > +
> >  Rename CMA helpers to DMA helpers
> >  ---------------------------------
> >
> > @@ -241,6 +285,9 @@ no one knows what that means) since underneath they just use dma_alloc_coherent.
> >
> >  Contact: Laurent Pinchart, Daniel Vetter
> >
> > +Level: Intermediate (mostly because it is a huge tasks without good partial
> > +milestones, not technically itself that challenging)
> > +
> >  Convert direct mode.vrefresh accesses to use drm_mode_vrefresh()
> >  ----------------------------------------------------------------
> >
> > @@ -259,6 +306,8 @@ drm_display_mode to avoid future use.
> >
> >  Contact: Sean Paul
> >
> > +Level: Starter
> > +
> >  Remove drm_display_mode.hsync
> >  -----------------------------
> >
> > @@ -269,6 +318,8 @@ it to use drm_mode_hsync() instead.
> >
> >  Contact: Sean Paul
> >
> > +Level: Starter
> > +
> >  drm_fb_helper tasks
> >  -------------------
> >
> > @@ -284,6 +335,8 @@ drm_fb_helper tasks
> >    removed: drm_fb_helper_single_add_all_connectors(),
> >    drm_fb_helper_add_one_connector() and drm_fb_helper_remove_one_connector().
> >
> > +Level: Intermediate
> > +
> >  connector register/unregister fixes
> >  -----------------------------------
> >
> > @@ -296,6 +349,8 @@ connector register/unregister fixes
> >    drm_dp_aux_init, and moving the actual registering into a late_register
> >    callback as recommended in the kerneldoc.
> >
> > +Level: Intermediate
> > +
> >  Core refactorings
> >  =================
> >
> > @@ -338,6 +393,8 @@ This is a really varied tasks with lots of little bits and pieces:
> >
> >  Contact: Daniel Vetter
> >
> > +Level: Advanced
> > +
> >  Clean up the debugfs support
> >  ----------------------------
> >
> > @@ -367,6 +424,8 @@ There's a bunch of issues with it:
> >
> >  Contact: Daniel Vetter
> >
> > +Level: Intermediate
> > +
> >  KMS cleanups
> >  ------------
> >
> > @@ -382,6 +441,8 @@ Some of these date from the very introduction of KMS in 2008 ...
> >    end, for which we could add drm_*_cleanup_kfree(). And then there's the (for
> >    historical reasons) misnamed drm_primary_helper_destroy() function.
> >
> > +Level: Intermediate
> > +
> >  Better Testing
> >  ==============
> >
> > @@ -390,6 +451,8 @@ Enable trinity for DRM
> >
> >  And fix up the fallout. Should be really interesting ...
> >
> > +Level: Advanced
> > +
> >  Make KMS tests in i-g-t generic
> >  -------------------------------
> >
> > @@ -403,6 +466,8 @@ 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.
> >
> > +Level: Advanced
> > +
> >  Extend virtual test driver (VKMS)
> >  ---------------------------------
> >
> > @@ -412,6 +477,8 @@ fit the available time.
> >
> >  Contact: Daniel Vetter
> >
> > +Level: See details
> > +
> >  Backlight Refactoring
> >  ---------------------
> >
> > @@ -425,6 +492,8 @@ Plan to fix this:
> >
> >  Contact: Daniel Vetter
> >
> > +Level: Intermediate
> > +
> >  Driver Specific
> >  ===============
> >
> > @@ -453,6 +522,8 @@ for fbdev.
> >
> >  Contact: Sam Ravnborg
> >
> > +Level: Advanced
> > +
> >  Outside DRM
> >  ===========
> >
> > @@ -482,3 +553,5 @@ and Weston.
> >   - [2] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c
> >
> >  Contact: Thomas Zimmermann <tzimmermann@suse.de>
> > +
> > +Level: Advanced
> >
>
> Hmm, it fits the definition of 'Advanced' but is it an advanced task?
> With all the helpers in DRM, fbconv, and lots of drivers to copy from,
> it mostly comes down to refactoring. I'd have classified this as starter
> to intermediate.
>
> In my case, I did my first steps in the DRM code by hacking up a driver
> for an ancient SiS chipset. [1] I found that much easier than working on
> the DRM core.

It does require quite a bit of understanding of drm concepts and
display concepts, plus you need to have hardware. It doesn't boil down
to much code, that's true.

Compared to some of the stuff I classified as intermediate, like
debugfs refactoring, where you can refactor without really having to
understand the big picture much, I felt like advanced is justified.

There's ofc the even more advanced stuff, where the first problem is
figuring out what the problem is, and then the next one is coming up
with an actual plan. You've done a lot of that, but that's way beyond
what we put into todo.rst. That's all stuff where the problem is
identified already, and the plan exists (sometimes in rough shape).

Cheers, Daniel

>
> Best regards
> Thomas
>
> [1] https://gitlab.freedesktop.org/tzimmermann/linux/tree/sisvga
>
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/todo: Remove i915 device_link task

[Sean Paul]

On Tue, Oct 22, 2019 at 05:25:29PM +0200, Daniel Vetter wrote:
> Done with
> 
> commit aef9f33b7658a7489f71df5d6e6ecb47f2521e8a
> Author: Imre Deak <imre.deak@intel.com>
> Date:   Tue Oct 23 17:43:10 2018 +0300
> 
>     drm/i915: Ensure proper HDA suspend/resume ordering with a device link
> 
> Cc: Imre Deak <imre.deak@intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Reviewed-by: Sean Paul <sean@poorly.run>

> ---
>  Documentation/gpu/todo.rst | 7 -------
>  1 file changed, 7 deletions(-)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 23b3a67794ba..9ac102922712 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -438,13 +438,6 @@ See drivers/gpu/drm/amd/display/TODO for tasks.
>  
>  Contact: Harry Wentland, Alex Deucher
>  
> -i915
> -----
> -
> -- Our early/late pm callbacks could be removed in favour of using
> -  device_link_add to model the dependency between i915 and snd_had. See
> -  https://dri.freedesktop.org/docs/drm/driver-api/device_link.html
> -
>  Bootsplash
>  ==========
>  
> -- 
> 2.23.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/todo: Remove i915 device_link task

[Daniel Vetter]

On Tue, Oct 22, 2019 at 01:03:01PM -0400, Sean Paul wrote:
> On Tue, Oct 22, 2019 at 05:25:29PM +0200, Daniel Vetter wrote:
> > Done with
> > 
> > commit aef9f33b7658a7489f71df5d6e6ecb47f2521e8a
> > Author: Imre Deak <imre.deak@intel.com>
> > Date:   Tue Oct 23 17:43:10 2018 +0300
> > 
> >     drm/i915: Ensure proper HDA suspend/resume ordering with a device link
> > 
> > Cc: Imre Deak <imre.deak@intel.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> Reviewed-by: Sean Paul <sean@poorly.run>

Both patches applied, thanks for taking a look.
-Daniel

> 
> > ---
> >  Documentation/gpu/todo.rst | 7 -------
> >  1 file changed, 7 deletions(-)
> > 
> > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > index 23b3a67794ba..9ac102922712 100644
> > --- a/Documentation/gpu/todo.rst
> > +++ b/Documentation/gpu/todo.rst
> > @@ -438,13 +438,6 @@ See drivers/gpu/drm/amd/display/TODO for tasks.
> >  
> >  Contact: Harry Wentland, Alex Deucher
> >  
> > -i915
> > -----
> > -
> > -- Our early/late pm callbacks could be removed in favour of using
> > -  device_link_add to model the dependency between i915 and snd_had. See
> > -  https://dri.freedesktop.org/docs/drm/driver-api/device_link.html
> > -
> >  Bootsplash
> >  ==========
> >  
> > -- 
> > 2.23.0
> > 
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel