All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Nirmoy Das <nirmoy.das@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH RFC 3/3] drm/i915/display: Implement fb_mmap callback function
Date: Mon, 6 Mar 2023 16:32:44 +0200	[thread overview]
Message-ID: <ZAX5jC+E/aUgUW9X@intel.com> (raw)
In-Reply-To: <20230306102850.18299-3-nirmoy.das@intel.com>

On Mon, Mar 06, 2023 at 11:28:50AM +0100, Nirmoy Das wrote:
> If stolen memory allocation fails for fbdev, the driver will
> fallback to system memory. Calculation of smem_start is wrong
> for such framebuffer objs if the platform comes with no gmadr or
> no aperture. Solve this by adding fb_mmap callback which also gives
> driver more control.
> 
> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_fbdev.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index 98ae3a3a986a..ed0f9e2af3ed 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -40,8 +40,10 @@
>  #include <drm/drm_crtc.h>
>  #include <drm/drm_fb_helper.h>
>  #include <drm/drm_fourcc.h>
> +#include <drm/drm_gem_framebuffer_helper.h>
>  
>  #include "gem/i915_gem_lmem.h"
> +#include "gem/i915_gem_mman.h"
>  
>  #include "i915_drv.h"
>  #include "intel_display_types.h"
> @@ -120,6 +122,23 @@ static int intel_fbdev_pan_display(struct fb_var_screeninfo *var,
>  	return ret;
>  }
>  
> +#define to_intel_fbdev(x) container_of(x, struct intel_fbdev, helper)
> +static int intel_fbdev_mmap(struct fb_info *info, struct vm_area_struct *vma)
> +{
> +	struct intel_fbdev *fbdev = to_intel_fbdev(info->par);
> +	struct drm_gem_object *bo = drm_gem_fb_get_obj(&fbdev->fb->base, 0);
> +	struct drm_i915_gem_object *obj = to_intel_bo(bo);
> +	struct drm_device *dev = fbdev->helper.dev;

You seem to be missing the fb vs. mmio handling here entirely.

> +
> +	vma->vm_page_prot =
> +			pgprot_writecombine(vm_get_page_prot(vma->vm_flags));

Does that do something sane on eg. !PAT?

> +
> +	if (obj->stolen)
> +		return vm_iomap_memory(vma, info->fix.smem_start,
> +				       info->fix.smem_len);

Why doesn't i915_gem_object_mmap() know how to handle stolen?

> +
> +	return i915_gem_object_mmap(obj, vma);
> +}
>  static const struct fb_ops intelfb_ops = {
>  	.owner = THIS_MODULE,
>  	DRM_FB_HELPER_DEFAULT_OPS,
> @@ -131,6 +150,7 @@ static const struct fb_ops intelfb_ops = {
>  	.fb_imageblit = drm_fb_helper_cfb_imageblit,
>  	.fb_pan_display = intel_fbdev_pan_display,
>  	.fb_blank = intel_fbdev_blank,
> +	.fb_mmap = intel_fbdev_mmap,
>  };
>  
>  static int intelfb_alloc(struct drm_fb_helper *helper,
> -- 
> 2.39.0

-- 
Ville Syrjälä
Intel

WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Nirmoy Das <nirmoy.das@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH RFC 3/3] drm/i915/display: Implement fb_mmap callback function
Date: Mon, 6 Mar 2023 16:32:44 +0200	[thread overview]
Message-ID: <ZAX5jC+E/aUgUW9X@intel.com> (raw)
In-Reply-To: <20230306102850.18299-3-nirmoy.das@intel.com>

On Mon, Mar 06, 2023 at 11:28:50AM +0100, Nirmoy Das wrote:
> If stolen memory allocation fails for fbdev, the driver will
> fallback to system memory. Calculation of smem_start is wrong
> for such framebuffer objs if the platform comes with no gmadr or
> no aperture. Solve this by adding fb_mmap callback which also gives
> driver more control.
> 
> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_fbdev.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index 98ae3a3a986a..ed0f9e2af3ed 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -40,8 +40,10 @@
>  #include <drm/drm_crtc.h>
>  #include <drm/drm_fb_helper.h>
>  #include <drm/drm_fourcc.h>
> +#include <drm/drm_gem_framebuffer_helper.h>
>  
>  #include "gem/i915_gem_lmem.h"
> +#include "gem/i915_gem_mman.h"
>  
>  #include "i915_drv.h"
>  #include "intel_display_types.h"
> @@ -120,6 +122,23 @@ static int intel_fbdev_pan_display(struct fb_var_screeninfo *var,
>  	return ret;
>  }
>  
> +#define to_intel_fbdev(x) container_of(x, struct intel_fbdev, helper)
> +static int intel_fbdev_mmap(struct fb_info *info, struct vm_area_struct *vma)
> +{
> +	struct intel_fbdev *fbdev = to_intel_fbdev(info->par);
> +	struct drm_gem_object *bo = drm_gem_fb_get_obj(&fbdev->fb->base, 0);
> +	struct drm_i915_gem_object *obj = to_intel_bo(bo);
> +	struct drm_device *dev = fbdev->helper.dev;

You seem to be missing the fb vs. mmio handling here entirely.

> +
> +	vma->vm_page_prot =
> +			pgprot_writecombine(vm_get_page_prot(vma->vm_flags));

Does that do something sane on eg. !PAT?

> +
> +	if (obj->stolen)
> +		return vm_iomap_memory(vma, info->fix.smem_start,
> +				       info->fix.smem_len);

Why doesn't i915_gem_object_mmap() know how to handle stolen?

> +
> +	return i915_gem_object_mmap(obj, vma);
> +}
>  static const struct fb_ops intelfb_ops = {
>  	.owner = THIS_MODULE,
>  	DRM_FB_HELPER_DEFAULT_OPS,
> @@ -131,6 +150,7 @@ static const struct fb_ops intelfb_ops = {
>  	.fb_imageblit = drm_fb_helper_cfb_imageblit,
>  	.fb_pan_display = intel_fbdev_pan_display,
>  	.fb_blank = intel_fbdev_blank,
> +	.fb_mmap = intel_fbdev_mmap,
>  };
>  
>  static int intelfb_alloc(struct drm_fb_helper *helper,
> -- 
> 2.39.0

-- 
Ville Syrjälä
Intel

  parent reply	other threads:[~2023-03-06 14:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-06 10:28 [Intel-gfx] [PATCH 1/3] drm/i915: Set I915_BO_ALLOC_USER for framebuffer Nirmoy Das
2023-03-06 10:28 ` Nirmoy Das
2023-03-06 10:28 ` [Intel-gfx] [PATCH 2/3] drm/i915: Add a helper func for gem obj mmap Nirmoy Das
2023-03-06 10:28   ` Nirmoy Das
2023-03-06 14:26   ` [Intel-gfx] " Ville Syrjälä
2023-03-06 14:26     ` Ville Syrjälä
2023-03-06 16:18     ` [Intel-gfx] " Das, Nirmoy
2023-03-06 16:18       ` Das, Nirmoy
2023-03-06 10:28 ` [Intel-gfx] [PATCH RFC 3/3] drm/i915/display: Implement fb_mmap callback function Nirmoy Das
2023-03-06 10:28   ` Nirmoy Das
2023-03-06 12:39   ` kernel test robot
2023-03-06 13:20   ` kernel test robot
2023-03-06 14:32   ` Ville Syrjälä [this message]
2023-03-06 14:32     ` Ville Syrjälä
2023-03-07 14:50     ` [Intel-gfx] " Das, Nirmoy
2023-03-07 14:50       ` Das, Nirmoy
2023-03-06 16:34   ` kernel test robot
2023-03-06 10:32 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/3] drm/i915: Set I915_BO_ALLOC_USER for framebuffer Patchwork
2023-03-06 14:21 ` [Intel-gfx] [PATCH 1/3] " Ville Syrjälä
2023-03-06 16:22   ` Das, Nirmoy
2023-03-06 17:30     ` Ville Syrjälä
2023-03-07  7:20       ` Das, Nirmoy
  -- strict thread matches above, loose matches on Subject: below --
2023-03-20 10:09 [Intel-gfx] [PATCH v2: 1/3] drm/i915: Add a function to mmap framebuffer obj Nirmoy Das
2023-03-20 10:09 ` [Intel-gfx] [PATCH RFC 3/3] drm/i915/display: Implement fb_mmap callback function Nirmoy Das
2023-03-20 14:00   ` Andrzej Hajda

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=ZAX5jC+E/aUgUW9X@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=nirmoy.das@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.