From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Matthew Auld <matthew.auld@intel.com>
Cc: intel-gfx@lists.freedesktop.org,
Nirmoy Das <nirmoy.das@intel.com>,
Jianshui Yu <jianshui.yu@intel.com>
Subject: Re: [Intel-gfx] [PATCH v4 4/5] drm/i915/display: consider DG2_RC_CCS_CC when migrating buffers
Date: Tue, 4 Oct 2022 14:28:35 +0300 [thread overview]
Message-ID: <YzwY47axVOqKGgav@intel.com> (raw)
In-Reply-To: <20221004103311.194409-4-matthew.auld@intel.com>
On Tue, Oct 04, 2022 at 11:33:10AM +0100, Matthew Auld wrote:
> For these types of display buffers, we need to able to CPU access some
> part of the backing memory in prepare_plane_clear_colors(). As a result
> we need to ensure we always place in the mappable part of lmem, which
> becomes necessary on small-bar systems.
>
> v2(Nirmoy & Ville):
> - Add some commentary for why we need to CPU access the buffer.
> - Split out the other changes, so we just consider the display change
> here.
> v3:
> - Handle this in the dpt path.
>
> Fixes: eb1c535f0d69 ("drm/i915: turn on small BAR support")
> Reported-by: Jianshui Yu <jianshui.yu@intel.com>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Nirmoy Das <nirmoy.das@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_fb_pin.c | 24 +++++++++++++++++++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c b/drivers/gpu/drm/i915/display/intel_fb_pin.c
> index 32206bd359da..8197343300ee 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
> @@ -50,7 +50,18 @@ intel_pin_fb_obj_dpt(struct drm_framebuffer *fb,
> continue;
>
> if (HAS_LMEM(dev_priv)) {
> - ret = i915_gem_object_migrate(obj, &ww, INTEL_REGION_LMEM_0);
> + unsigned int flags = obj->flags;
> +
> + /*
> + * For this type of buffer we need to able to read from the CPU
> + * the clear color value found in the buffer, hence we need to
> + * ensure it is always in the mappable part of lmem, if this is
> + * a small-bar device.
> + */
> + if (intel_fb_rc_ccs_cc_plane(fb) >= 0)
> + flags &= ~I915_BO_ALLOC_GPU_ONLY;
> + ret = __i915_gem_object_migrate(obj, &ww, INTEL_REGION_LMEM_0,
> + flags);
> if (ret)
> continue;
> }
> @@ -156,8 +167,17 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
> ret = i915_gem_object_lock(obj, &ww);
> if (!ret && phys_cursor)
> ret = i915_gem_object_attach_phys(obj, alignment);
> - else if (!ret && HAS_LMEM(dev_priv))
> + else if (!ret && HAS_LMEM(dev_priv)) {
> + /*
> + * For this type of ccs buffer we need to able to read from the
> + * CPU the clear color value found in the buffer, which might
> + * require moving to the mappable part of lmem first, but here
> + * we should be using dpt for this.
> + */
> + WARN_ON_ONCE(intel_fb_rc_ccs_cc_plane(fb) >= 0);
DPT isn't availalable on DG1.
> +
> ret = i915_gem_object_migrate(obj, &ww, INTEL_REGION_LMEM_0);
> + }
> if (!ret)
> ret = i915_gem_object_pin_pages(obj);
> if (ret)
> --
> 2.37.3
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2022-10-04 11:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-04 10:33 [Intel-gfx] [PATCH v4 1/5] drm/i915: remove the TODO in pin_and_fence_fb_obj Matthew Auld
2022-10-04 10:33 ` [Intel-gfx] [PATCH v4 2/5] drm/i915/display: handle migration for dpt Matthew Auld
2022-10-04 11:22 ` Ville Syrjälä
2022-10-04 11:54 ` Matthew Auld
2022-10-04 12:25 ` Ville Syrjälä
2022-10-04 10:33 ` [Intel-gfx] [PATCH v4 3/5] drm/i915: allow control over the flags when migrating Matthew Auld
2022-10-04 10:33 ` [Intel-gfx] [PATCH v4 4/5] drm/i915/display: consider DG2_RC_CCS_CC when migrating buffers Matthew Auld
2022-10-04 11:28 ` Ville Syrjälä [this message]
2022-10-04 11:51 ` Matthew Auld
2022-10-04 12:17 ` Ville Syrjälä
2022-10-04 10:33 ` [Intel-gfx] [PATCH v4 5/5] drm/i915: check memory is mappable in read_from_page Matthew Auld
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=YzwY47axVOqKGgav@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jianshui.yu@intel.com \
--cc=matthew.auld@intel.com \
--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.