Re: [PATCH v2] drm/i915/display: replace boilerplate code with helper macros

[Ville Syrjälä]

On Sat, Jun 26, 2021 at 03:32:27AM -0400, Hamza Mahfooz wrote:
> As per commit 22be87401289 ("drm: TODO: Add DRM_MODESET_LOCK_ALL*
> conversion to todo.rst"),
> drm_modeset_lock_all()/drm_modeset_unlock_all() and boilerplate code
> surrounding instances of drm_modeset_lock_all_ctx() with a local acquire
> context should be replaced with the relevant helper macros.
> 
> Signed-off-by: Hamza Mahfooz <someguy@xxxxxxxxxxxxxxxxxxx>
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 20 +++++++-------------
>  1 file changed, 7 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index 64e9107d70f7..e8cb2881d2b4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -40,6 +40,7 @@
>  #include <drm/drm_dp_helper.h>
>  #include <drm/drm_edid.h>
>  #include <drm/drm_fourcc.h>
> +#include "drm/drm_modeset_lock.h"
>  #include <drm/drm_plane_helper.h>
>  #include <drm/drm_probe_helper.h>
>  #include <drm/drm_rect.h>
> @@ -11836,6 +11837,7 @@ int intel_modeset_init_nogem(struct drm_i915_private *i915)
>  	struct drm_device *dev = &i915->drm;
>  	enum pipe pipe;
>  	struct intel_crtc *crtc;
> +	struct drm_modeset_acquire_ctx ctx;
>  	int ret;
>  
>  	intel_init_pm(i915);
> @@ -11884,9 +11886,9 @@ int intel_modeset_init_nogem(struct drm_i915_private *i915)
>  	intel_vga_disable(i915);
>  	intel_setup_outputs(i915);
>  
> -	drm_modeset_lock_all(dev);
> +	DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
>  	intel_modeset_setup_hw_state(dev, dev->mode_config.acquire_ctx);
> -	drm_modeset_unlock_all(dev);
> +	DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);

That looks wrong. You're using a private ctx here, but still
passing dev->mode_config.acquire_ctx to the lower level stuff.

Also DRM_MODESET_LOCK_ALL_{BEGIN,END}() do not seem to be
equivalent to drm_modeset_{lock,unlock}_all() when it comes to 
mode_config.mutex. So would need a proper review whether we
actually need that lock or not.

-- 
Ville Syrjälä
Intel