diff mbox series

[v3,13/16] drm/i915/fbdev: Fix smem_start for LMEMBAR stolen objects

Message ID 20240116075636.6121-14-ville.syrjala@linux.intel.com (mailing list archive)
State New, archived
Headers show
Series drm/i915: (stolen) memory region related fixes | expand

Commit Message

Ville Syrjälä Jan. 16, 2024, 7:56 a.m. UTC
From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The "io" address of an object is its dma address minus the
region.start. Subtract the latter to make smem_start correct.
The current code happens to work for genuine LMEM objects
as LMEM region.start==0, but for LMEMBAR stolen objects
region.start!=0.

TODO: perhaps just set smem_start=0 always as our .fb_mmap()
implementation no longer depends on it? Need to double check
it's not needed for anything else...

Cc: Paz Zcharya <pazz@chromium.org>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/display/intel_fbdev_fb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Paz Zcharya Jan. 30, 2024, 11:25 p.m. UTC | #1
On Tue, Jan 16, 2024 at 09:56:33AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> The "io" address of an object is its dma address minus the
> region.start. Subtract the latter to make smem_start correct.
> The current code happens to work for genuine LMEM objects
> as LMEM region.start==0, but for LMEMBAR stolen objects
> region.start!=0.
> 
> TODO: perhaps just set smem_start=0 always as our .fb_mmap()
> implementation no longer depends on it? Need to double check
> it's not needed for anything else...
> 
> Cc: Paz Zcharya <pazz@chromium.org>
> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Hi Ville,

Thank you so much for this incredible series.
It solves the issue regarding MTL initial plane readout
that Andrzej Hajda and I worked on in
https://patchwork.freedesktop.org/patch/570811/?series=127130&rev=2
In addition, it solved the issue with the new GOP.

I tested it on two different devices with Meteor Lake and it worked perfectly:
no i915 errors, no flickers or observable issues.

Tested-by: Paz Zcharya <pazz@chromium.org>

> ---
>  drivers/gpu/drm/i915/display/intel_fbdev_fb.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev_fb.c b/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
> index 1ac05d90b2e8..0665f943f65f 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
> @@ -79,7 +79,8 @@ int intel_fbdev_fb_fill_info(struct drm_i915_private *i915, struct fb_info *info
>  		/* Use fbdev's framebuffer from lmem for discrete */
>  		info->fix.smem_start =
>  			(unsigned long)(mem->io.start +
> -					i915_gem_object_get_dma_address(obj, 0));
> +					i915_gem_object_get_dma_address(obj, 0) -
> +					mem->region.start);
>  		info->fix.smem_len = obj->base.size;
>  	} else {
>  		struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
> -- 
> 2.41.0
>
diff mbox series

Patch

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev_fb.c b/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
index 1ac05d90b2e8..0665f943f65f 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
@@ -79,7 +79,8 @@  int intel_fbdev_fb_fill_info(struct drm_i915_private *i915, struct fb_info *info
 		/* Use fbdev's framebuffer from lmem for discrete */
 		info->fix.smem_start =
 			(unsigned long)(mem->io.start +
-					i915_gem_object_get_dma_address(obj, 0));
+					i915_gem_object_get_dma_address(obj, 0) -
+					mem->region.start);
 		info->fix.smem_len = obj->base.size;
 	} else {
 		struct i915_ggtt *ggtt = to_gt(i915)->ggtt;