All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Auld <matthew.auld@intel.com>
To: intel-xe@lists.freedesktop.org
Subject: [Intel-xe] [PATCH v3 1/6] drm/xe: add xe_ttm_stolen_cpu_access_needs_ggtt()
Date: Wed,  8 Mar 2023 12:30:07 +0000	[thread overview]
Message-ID: <20230308123012.247091-2-matthew.auld@intel.com> (raw)
In-Reply-To: <20230308123012.247091-1-matthew.auld@intel.com>

xe_ttm_stolen_cpu_inaccessible() was originally meant to just cover the
case where stolen is not directly CPU accessible on some older
integrated platforms, and as such a GGTT mapping was also required for
CPU access (as per the check in xe_bo_create_pin_map_at()).

However with small-bar systems on dgfx we have one more case where
stolen is also inaccessible, however here we don't have any fallback
GGTT mode for CPU access. Fix the check in xe_bo_create_pin_map_at() to
make this distinction clear. In such a case the later vmap() will fail
anyway.

v2: fix kernel-doc warning
v3: Simplify further and remove cpu_inaccessible()

Suggested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
---
 drivers/gpu/drm/xe/xe_bo.c             |  2 +-
 drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c | 39 ++++++++------------------
 drivers/gpu/drm/xe/xe_ttm_stolen_mgr.h |  2 +-
 3 files changed, 14 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
index 2bfd3f6f2e9a..876f77669104 100644
--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -1151,7 +1151,7 @@ struct xe_bo *xe_bo_create_pin_map_at(struct xe_device *xe, struct xe_gt *gt,
 	u64 end = offset == ~0ull ? offset : start + size;
 
 	if (flags & XE_BO_CREATE_STOLEN_BIT &&
-	    xe_ttm_stolen_cpu_inaccessible(xe))
+	    xe_ttm_stolen_cpu_access_needs_ggtt(xe))
 		flags |= XE_BO_CREATE_GGTT_BIT;
 
 	bo = xe_bo_create_locked_range(xe, gt, vm, size, start, end, type, flags);
diff --git a/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c b/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c
index 2e8d07ad42ae..0ad0f1820f4b 100644
--- a/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c
+++ b/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c
@@ -38,32 +38,17 @@ to_stolen_mgr(struct ttm_resource_manager *man)
 }
 
 /**
- * xe_ttm_stolen_cpu_inaccessible - Can we directly CPU access stolen memory for
- * this device.
+ * xe_ttm_stolen_cpu_access_needs_ggtt - If we can't directly CPU access stolen,
+ * can we then fallback to mapping through the GGTT.
  * @xe: xe device
  *
- * On some integrated platforms we can't directly access stolen via the CPU
- * (like some normal system memory).  Also on small-bar systems for discrete,
- * since stolen is always as the end of normal VRAM, and the BAR likely doesn't
- * stretch that far. However CPU access of stolen is generally rare, and at
- * least on discrete should not be needed.
- *
- * If this is indeed inaccessible then we fallback to using the GGTT mappable
- * aperture for CPU access. On discrete platforms we have no such thing, so when
- * later attempting to CPU map the memory an error is instead thrown.
+ * Some older integrated platforms don't support reliable CPU access for stolen,
+ * however on such hardware we can always use the mappable part of the GGTT for
+ * CPU access. Check if that's the case for this device.
  */
-bool xe_ttm_stolen_cpu_inaccessible(struct xe_device *xe)
+bool xe_ttm_stolen_cpu_access_needs_ggtt(struct xe_device *xe)
 {
-	struct ttm_resource_manager *ttm_mgr =
-		ttm_manager_type(&xe->ttm, XE_PL_STOLEN);
-	struct xe_ttm_stolen_mgr *mgr;
-
-	if (!ttm_mgr)
-		return true;
-
-	mgr = to_stolen_mgr(ttm_mgr);
-
-	return !mgr->io_base || GRAPHICS_VERx100(xe) < 1270;
+	return GRAPHICS_VERx100(xe) < 1270 && !IS_DGFX(xe);
 }
 
 static s64 detect_bar2_dgfx(struct xe_device *xe, struct xe_ttm_stolen_mgr *mgr)
@@ -172,7 +157,7 @@ void xe_ttm_stolen_mgr_init(struct xe_device *xe)
 	drm_dbg_kms(&xe->drm, "Initialized stolen memory support with %llu bytes\n",
 		    stolen_size);
 
-	if (!xe_ttm_stolen_cpu_inaccessible(xe))
+	if (mgr->io_base && !xe_ttm_stolen_cpu_access_needs_ggtt(xe))
 		mgr->mapping = devm_ioremap_wc(&pdev->dev, mgr->io_base, stolen_size);
 }
 
@@ -185,7 +170,7 @@ u64 xe_ttm_stolen_io_offset(struct xe_bo *bo, u32 offset)
 
 	XE_BUG_ON(!mgr->io_base);
 
-	if (!IS_DGFX(xe) && xe_ttm_stolen_cpu_inaccessible(xe))
+	if (xe_ttm_stolen_cpu_access_needs_ggtt(xe))
 		return mgr->io_base + xe_bo_ggtt_addr(bo) + offset;
 
 	xe_res_first(bo->ttm.resource, offset, 4096, &cur);
@@ -251,10 +236,10 @@ int xe_ttm_stolen_io_mem_reserve(struct xe_device *xe, struct ttm_resource *mem)
 	if (!mgr || !mgr->io_base)
 		return -EIO;
 
-	if (!xe_ttm_stolen_cpu_inaccessible(xe))
-		return __xe_ttm_stolen_io_mem_reserve_bar2(xe, mgr, mem);
-	else
+	if (xe_ttm_stolen_cpu_access_needs_ggtt(xe))
 		return __xe_ttm_stolen_io_mem_reserve_stolen(xe, mgr, mem);
+	else
+		return __xe_ttm_stolen_io_mem_reserve_bar2(xe, mgr, mem);
 }
 
 u64 xe_ttm_stolen_gpu_offset(struct xe_device *xe)
diff --git a/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.h b/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.h
index 2fda97b97a05..1777245ff810 100644
--- a/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.h
+++ b/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.h
@@ -14,7 +14,7 @@ struct xe_device;
 
 void xe_ttm_stolen_mgr_init(struct xe_device *xe);
 int xe_ttm_stolen_io_mem_reserve(struct xe_device *xe, struct ttm_resource *mem);
-bool xe_ttm_stolen_cpu_inaccessible(struct xe_device *xe);
+bool xe_ttm_stolen_cpu_access_needs_ggtt(struct xe_device *xe);
 u64 xe_ttm_stolen_io_offset(struct xe_bo *bo, u32 offset);
 u64 xe_ttm_stolen_gpu_offset(struct xe_device *xe);
 
-- 
2.39.2


  reply	other threads:[~2023-03-08 12:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-08 12:30 [Intel-xe] [PATCH v3 0/6] Some small-bar prep patches Matthew Auld
2023-03-08 12:30 ` Matthew Auld [this message]
2023-03-08 12:30 ` [Intel-xe] [PATCH v3 2/6] drm/xe: s/lmem/vram/ Matthew Auld
2023-03-08 13:37   ` Rodrigo Vivi
2023-03-08 12:30 ` [Intel-xe] [PATCH v3 3/6] drm/xe/vram: start tracking the io_size Matthew Auld
2023-03-08 12:30 ` [Intel-xe] [PATCH v3 4/6] drm/xe/buddy: remove the virtualized start Matthew Auld
2023-03-08 12:30 ` [Intel-xe] [PATCH v3 5/6] drm/xe/buddy: add visible tracking Matthew Auld
2023-03-08 13:40   ` Rodrigo Vivi
2023-03-08 12:30 ` [Intel-xe] [PATCH v3 6/6] drm/xe/buddy: add compatible and intersects hooks Matthew Auld
2023-03-13 16:05 ` [Intel-xe] ✗ CI.Patch_applied: failure for Some small-bar prep patches (rev3) 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=20230308123012.247091-2-matthew.auld@intel.com \
    --to=matthew.auld@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    /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.