From: Jani Nikula <jani.nikula@linux.intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
intel-gfx@lists.freedesktop.org
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v2 4/6] drm/i915: Use i915_vma_offset() in intel_dpt_offset()
Date: Thu, 10 Apr 2025 11:52:24 +0300 [thread overview]
Message-ID: <87v7rcv1o7.fsf@intel.com> (raw)
In-Reply-To: <20250402172240.9275-5-ville.syrjala@linux.intel.com>
On Wed, 02 Apr 2025, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Replace the open coded vma mm node stuff in intel_dpt_offset()
> with i915_vma_offset(). This will also include the VT-d guard
> in the result. Granted that should always be 0 for DPT, but
> it seems prudent to include that in our DPT vma offset check
> anyway.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
> drivers/gpu/drm/i915/display/intel_fb_pin.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c b/drivers/gpu/drm/i915/display/intel_dpt.c
> index 43bd97e4f589..2bf4ad6a0fdf 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> @@ -321,5 +321,5 @@ void intel_dpt_destroy(struct i915_address_space *vm)
>
> u64 intel_dpt_offset(struct i915_vma *dpt_vma)
> {
> - return dpt_vma->node.start;
> + return i915_vma_offset(dpt_vma);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c b/drivers/gpu/drm/i915/display/intel_fb_pin.c
> index a5b9d87b2255..d40e3d96b14a 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
> @@ -300,8 +300,8 @@ int intel_plane_pin_fb(struct intel_plane_state *plane_state,
> WARN_ON(plane_state->ggtt_vma == plane_state->dpt_vma);
>
> /*
> - * The DPT object contains only one vma, so
> - * the VMA's offset within the DPT is always 0.
> + * The DPT object contains only one vma, and there is no VT-d
> + * guard, so the VMA's offset within the DPT is always 0.
> */
> drm_WARN_ON(display->drm, intel_dpt_offset(plane_state->dpt_vma));
> }
--
Jani Nikula, Intel
next prev parent reply other threads:[~2025-04-10 8:52 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-02 17:22 [PATCH v2 0/6] drm/i915: Precompute plane SURF address/etc Ville Syrjala
2025-04-02 17:22 ` [PATCH v2 1/6] drm/i915: Precompute plane SURF address Ville Syrjala
2025-04-10 8:45 ` Jani Nikula
2025-04-02 17:22 ` [PATCH v2 2/6] drm/i915: Nuke intel_plane_ggtt_offset() Ville Syrjala
2025-04-03 8:29 ` Jani Nikula
2025-04-04 15:21 ` Ville Syrjälä
2025-04-10 8:47 ` Jani Nikula
2025-04-02 17:22 ` [PATCH v2 3/6] drm/i915: Move the intel_dpt_offset() check into intel_plane_pin_fb() Ville Syrjala
2025-04-10 8:51 ` Jani Nikula
2025-04-02 17:22 ` [PATCH v2 4/6] drm/i915: Use i915_vma_offset() in intel_dpt_offset() Ville Syrjala
2025-04-10 8:52 ` Jani Nikula [this message]
2025-04-02 17:22 ` [PATCH v2 5/6] drm/i915: Remove unused dpt_total_entries() Ville Syrjala
2025-04-10 8:52 ` Jani Nikula
2025-04-02 17:22 ` [PATCH v2 6/6] drm/i915: Don't pass crtc_state to foo_plane_ctl() & co Ville Syrjala
2025-04-10 8:53 ` Jani Nikula
2025-04-02 17:28 ` ✓ CI.Patch_applied: success for drm/i915: Precompute plane SURF address/etc. (rev2) Patchwork
2025-04-02 17:29 ` ✓ CI.checkpatch: " Patchwork
2025-04-02 17:30 ` ✓ CI.KUnit: " Patchwork
2025-04-02 17:47 ` ✓ CI.Build: " Patchwork
2025-04-02 17:50 ` ✓ CI.Hooks: " Patchwork
2025-04-02 17:51 ` ✗ CI.checksparse: warning " Patchwork
2025-04-02 18:36 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-04-02 19:00 ` ✗ Fi.CI.SPARSE: warning " Patchwork
2025-04-02 19:17 ` ✓ i915.CI.BAT: success " Patchwork
2025-04-02 21:01 ` ✗ Xe.CI.Full: failure " Patchwork
2025-04-02 21:14 ` ✗ i915.CI.Full: " Patchwork
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=87v7rcv1o7.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@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.