All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Dave Airlie <airlied@gmail.com>, intel-gfx@lists.freedesktop.org
Cc: ville.syrjala@linux.intel.com, Dave Airlie <airlied@redhat.com>
Subject: Re: [Intel-gfx] [PATCH 6/8] drm/i915/display: refactor fbdev pin/unpin out into functions.
Date: Tue, 12 Oct 2021 20:25:17 +0300	[thread overview]
Message-ID: <87y26yxiiq.fsf@intel.com> (raw)
In-Reply-To: <20211012043502.1377715-7-airlied@gmail.com>

On Tue, 12 Oct 2021, Dave Airlie <airlied@gmail.com> wrote:
> From: Dave Airlie <airlied@redhat.com>
>
> This just cleans up the calls a bit.

I get an uneasy feeling about the changes in the error paths here. The
happy day scenario looks fine.

>
> Signed-off-by: Dave Airlie <airlied@redhat.com>
> ---
>  drivers/gpu/drm/i915/display/intel_fbdev.c | 64 +++++++++++++---------
>  1 file changed, 38 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index adc3a81be9f7..7ac9348d20c5 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -171,6 +171,35 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
>  	return 0;
>  }
>  
> +static int intel_fbdev_pin_and_fence(struct drm_i915_private *dev_priv,
> +				     struct intel_fbdev *ifbdev,
> +				     void **vaddr)
> +{
> +	const struct i915_ggtt_view view = {
> +		.type = I915_GGTT_VIEW_NORMAL,
> +	};
> +	ifbdev->vma = intel_pin_and_fence_fb_obj(&ifbdev->fb->base, false,
> +						 &view, false, &ifbdev->vma_flags);
> +
> +	if (IS_ERR(ifbdev->vma)) {
> +		return PTR_ERR(ifbdev->vma);

ifbdev->vma remains non-NULL error pointer.

> +	}
> +
> +	*vaddr = i915_vma_pin_iomap(ifbdev->vma);
> +	if (IS_ERR(*vaddr)) {
> +		drm_err(&dev_priv->drm,
> +			"Failed to remap framebuffer into virtual memory\n");
> +		return PTR_ERR(vaddr);

Old error path would do unpin here.

> +	}
> +	return 0;
> +}
> +
> +static void intel_fbdev_unpin(struct intel_fbdev *ifbdev)
> +{
> +	if (ifbdev->vma)
> +		intel_unpin_fb_vma(ifbdev->vma, ifbdev->vma_flags);
> +}
> +
>  static int intelfb_create(struct drm_fb_helper *helper,
>  			  struct drm_fb_helper_surface_size *sizes)
>  {
> @@ -181,13 +210,8 @@ static int intelfb_create(struct drm_fb_helper *helper,
>  	struct drm_i915_private *dev_priv = to_i915(dev);
>  	struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
>  	struct i915_ggtt *ggtt = &dev_priv->ggtt;
> -	const struct i915_ggtt_view view = {
> -		.type = I915_GGTT_VIEW_NORMAL,
> -	};
>  	intel_wakeref_t wakeref;
>  	struct fb_info *info;
> -	struct i915_vma *vma;
> -	unsigned long flags = 0;
>  	bool prealloc = false;
>  	void __iomem *vaddr;
>  	struct drm_i915_gem_object *obj;
> @@ -224,10 +248,8 @@ static int intelfb_create(struct drm_fb_helper *helper,
>  	 * This also validates that any existing fb inherited from the
>  	 * BIOS is suitable for own access.
>  	 */
> -	vma = intel_pin_and_fence_fb_obj(&ifbdev->fb->base, false,
> -					 &view, false, &flags);
> -	if (IS_ERR(vma)) {
> -		ret = PTR_ERR(vma);
> +	ret = intel_fbdev_pin_and_fence(dev_priv, ifbdev, &vaddr);
> +	if (ret) {
>  		goto out_unlock;
>  	}
>  
> @@ -261,19 +283,12 @@ static int intelfb_create(struct drm_fb_helper *helper,
>  
>  		/* Our framebuffer is the entirety of fbdev's system memory */
>  		info->fix.smem_start =
> -			(unsigned long)(ggtt->gmadr.start + vma->node.start);
> -		info->fix.smem_len = vma->node.size;
> +			(unsigned long)(ggtt->gmadr.start + ifbdev->vma->node.start);
> +		info->fix.smem_len = ifbdev->vma->node.size;
>  	}
>  
> -	vaddr = i915_vma_pin_iomap(vma);
> -	if (IS_ERR(vaddr)) {
> -		drm_err(&dev_priv->drm,
> -			"Failed to remap framebuffer into virtual memory\n");
> -		ret = PTR_ERR(vaddr);
> -		goto out_unpin;
> -	}
>  	info->screen_base = vaddr;
> -	info->screen_size = vma->node.size;
> +	info->screen_size = ifbdev->vma->node.size;
>  
>  	drm_fb_helper_fill_info(info, &ifbdev->helper, sizes);
>  
> @@ -281,23 +296,21 @@ static int intelfb_create(struct drm_fb_helper *helper,
>  	 * If the object is stolen however, it will be full of whatever
>  	 * garbage was left in there.
>  	 */
> -	if (!i915_gem_object_is_shmem(vma->obj) && !prealloc)
> +	if (!i915_gem_object_is_shmem(ifbdev->vma->obj) && !prealloc)
>  		memset_io(info->screen_base, 0, info->screen_size);
>  
>  	/* Use default scratch pixmap (info->pixmap.flags = FB_PIXMAP_SYSTEM) */
>  
>  	drm_dbg_kms(&dev_priv->drm, "allocated %dx%d fb: 0x%08x\n",
>  		    ifbdev->fb->base.width, ifbdev->fb->base.height,
> -		    i915_ggtt_offset(vma));
> -	ifbdev->vma = vma;
> -	ifbdev->vma_flags = flags;

Old code assigns these only on success.

I'm not insisting on making changes, but I guess I need to be told it
doesn't matter.

BR,
Jani.

> +		    i915_ggtt_offset(ifbdev->vma));
>  
>  	intel_runtime_pm_put(&dev_priv->runtime_pm, wakeref);
>  	vga_switcheroo_client_fb_set(pdev, info);
>  	return 0;
>  
>  out_unpin:
> -	intel_unpin_fb_vma(vma, flags);
> +	intel_fbdev_unpin(ifbdev);
>  out_unlock:
>  	intel_runtime_pm_put(&dev_priv->runtime_pm, wakeref);
>  	return ret;
> @@ -316,8 +329,7 @@ static void intel_fbdev_destroy(struct intel_fbdev *ifbdev)
>  
>  	drm_fb_helper_fini(&ifbdev->helper);
>  
> -	if (ifbdev->vma)
> -		intel_unpin_fb_vma(ifbdev->vma, ifbdev->vma_flags);
> +	intel_fbdev_unpin(ifbdev);
>  
>  	if (ifbdev->fb)
>  		drm_framebuffer_remove(&ifbdev->fb->base);

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2021-10-12 17:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-12  4:34 [Intel-gfx] [RFC PATCH 0/8] drm/i915/display: refactor plane config + pin out (v2) Dave Airlie
2021-10-12  4:34 ` [Intel-gfx] [PATCH 1/8] drm/i915/display: move plane prepare/cleanup to intel_atomic_plane.c Dave Airlie
2021-10-12  4:34 ` [Intel-gfx] [PATCH 2/8] drm/i915/display: let intel_plane_uses_fence be used from other places Dave Airlie
2021-10-12  4:34 ` [Intel-gfx] [PATCH 3/8] drm/i915/display: refactor out initial plane config for crtcs Dave Airlie
2021-10-12  4:34 ` [Intel-gfx] [PATCH 4/8] drm/i915/display: refactor initial plane config to a separate file Dave Airlie
2021-10-12  4:34 ` [Intel-gfx] [PATCH 5/8] drm/i915/display: move pin/unpin fb/plane code to a new file Dave Airlie
2021-10-12 10:40   ` Jani Nikula
2021-10-12  4:35 ` [Intel-gfx] [PATCH 6/8] drm/i915/display: refactor fbdev pin/unpin out into functions Dave Airlie
2021-10-12 17:25   ` Jani Nikula [this message]
2021-10-12  4:35 ` [Intel-gfx] [PATCH 7/8] drm/i915/display: move fbdev pin code into fb_pin Dave Airlie
2021-10-12  4:35 ` [Intel-gfx] [PATCH 8/8] drm/i915/display: drop unused parameter to dpt pin Dave Airlie
2021-10-12  4:51 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: refactor plane config + pin out (rev2) Patchwork
2021-10-12  4:53 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-10-12  5:20 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-10-12  7:53 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2021-10-07  3:13 [Intel-gfx] [RFC PATCH 0/8] drm/i915/display: refactor plane config + pin out Dave Airlie
2021-10-07  3:13 ` [Intel-gfx] [PATCH 6/8] drm/i915/display: refactor fbdev pin/unpin out into functions Dave Airlie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y26yxiiq.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=airlied@gmail.com \
    --cc=airlied@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.