From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Badal Nilawar <badal.nilawar@intel.com>, intel-xe@lists.freedesktop.org
Cc: matthew.auld@intel.com, rodrigo.vivi@intel.com
Subject: Re: [Intel-xe] [PATCH 2/2] drm/xe/dgfx: Release mmap mappings on rpm suspend
Date: Fri, 8 Dec 2023 12:15:04 +0100 [thread overview]
Message-ID: <22cdd8b1-90ef-ddce-5731-75cfc0987a3c@linux.intel.com> (raw)
In-Reply-To: <20231206133421.3295163-3-badal.nilawar@intel.com>
On 12/6/23 14:34, Badal Nilawar wrote:
> Release all mmap mappings for all vram objects which are associated
> with userfault such that, while pcie function in D3hot, any access
> to memory mappings will raise a userfault.
>
> Upon userfault, in order to access memory mappings, if graphics
> function is in D3 then runtime resume of dgpu will be triggered to
> transition to D0.
>
> Previous commit has blocked the rpm but let's make sure that rpm
> does not get blocked for headed cards(client's parts).
> Above pagefault approach will be useful for headed cards to save the
> power when display is off and there are active mmap mappings.
>
> v2:
> - Add lock dep assertion before updating vram_userfault_count (Rodrigo)
> - Avoid iomem check before bo migration check as bo can migrate
> to system memory (Matthew Auld)
> v3:
> - Apply pagefault approach for headed cards.
>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> Signed-off-by: Badal Nilawar <badal.nilawar@intel.com>
> ---
> drivers/gpu/drm/xe/xe_bo.c | 62 ++++++++++++++++++++++++++--
> drivers/gpu/drm/xe/xe_bo.h | 2 +
> drivers/gpu/drm/xe/xe_bo_types.h | 5 +++
> drivers/gpu/drm/xe/xe_device_types.h | 20 +++++++++
> drivers/gpu/drm/xe/xe_pm.c | 7 ++++
> 5 files changed, 93 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index 5741948a2a51..419bc5c55aa7 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c
> @@ -797,6 +797,18 @@ static int xe_bo_move(struct ttm_buffer_object *ttm_bo, bool evict,
> dma_fence_put(fence);
> }
>
> + /*
> + * TTM has already nuked the mmap for us (see ttm_bo_unmap_virtual),
> + * so if we moved from VRAM make sure to unlink this from the userfault
> + * tracking.
> + */
> + if (mem_type_is_vram(old_mem_type)) {
> + spin_lock(&xe->mem_access.vram_userfault_lock);
> + if (INTEL_DISPLAY_ENABLED(xe) && !list_empty(&bo->vram_userfault_link))
> + list_del_init(&bo->vram_userfault_link);
> + spin_unlock(&xe->mem_access.vram_userfault_lock);
> + }
> +
Please move this block into move_notify() instead, if at all possible.
That function is intended to release whatever various bindings we have
set up to the backing memory in the old location.
Thanks,
Thomas
next prev parent reply other threads:[~2023-12-08 11:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-06 13:34 [Intel-xe] [PATCH 0/2] Handle mmap with D3 Badal Nilawar
2023-12-06 13:34 ` [Intel-xe] [PATCH 1/2] drm/xe/dgfx: Block rpm for active mmap mappings Badal Nilawar
2023-12-07 11:26 ` Matthew Auld
2023-12-07 13:06 ` Matthew Auld
2023-12-08 7:29 ` Nilawar, Badal
2023-12-08 9:11 ` Matthew Auld
2023-12-08 7:17 ` Nilawar, Badal
2023-12-08 9:27 ` Matthew Auld
2023-12-06 13:34 ` [Intel-xe] [PATCH 2/2] drm/xe/dgfx: Release mmap mappings on rpm suspend Badal Nilawar
2023-12-07 11:37 ` Matthew Auld
2023-12-07 17:00 ` Gupta, Anshuman
2023-12-08 11:15 ` Thomas Hellström [this message]
2023-12-06 16:28 ` [Intel-xe] ✓ CI.Patch_applied: success for Handle mmap with D3 Patchwork
2023-12-06 16:28 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-12-06 16:28 ` [Intel-xe] ✗ CI.KUnit: failure " 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=22cdd8b1-90ef-ddce-5731-75cfc0987a3c@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=badal.nilawar@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=rodrigo.vivi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox