From: Matthew Auld <matthew.auld@intel.com>
To: intel-xe@lists.freedesktop.org
Subject: [Intel-xe] [PATCH 1/6] drm/xe: add xe_ttm_stolen_cpu_access_needs_ggtt()
Date: Wed, 1 Mar 2023 14:48:10 +0000 [thread overview]
Message-ID: <20230301144815.248239-2-matthew.auld@intel.com> (raw)
In-Reply-To: <20230301144815.248239-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.
Suggested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
---
drivers/gpu/drm/xe/xe_bo.c | 2 +-
drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c | 14 ++++++++++++++
drivers/gpu/drm/xe/xe_ttm_stolen_mgr.h | 1 +
3 files changed, 16 insertions(+), 1 deletion(-)
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..4bf373a03d64 100644
--- a/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c
+++ b/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c
@@ -66,6 +66,20 @@ bool xe_ttm_stolen_cpu_inaccessible(struct xe_device *xe)
return !mgr->io_base || GRAPHICS_VERx100(xe) < 1270;
}
+/**
+ * xe_ttm_stolen_needs_ggtt - If we can't directly CPU access stolen, can we
+ * then fallback to mapping through the GGTT.
+ * @xe: xe device
+ *
+ * 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_access_needs_ggtt(struct xe_device *xe)
+{
+ return xe_ttm_stolen_cpu_inaccessible(xe) && !IS_DGFX(xe);
+}
+
static s64 detect_bar2_dgfx(struct xe_device *xe, struct xe_ttm_stolen_mgr *mgr)
{
struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
diff --git a/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.h b/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.h
index 2fda97b97a05..e210dada636e 100644
--- a/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.h
+++ b/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.h
@@ -15,6 +15,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
next prev parent reply other threads:[~2023-03-01 14:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-01 14:48 [Intel-xe] [PATCH 0/6] Some small-bar prep patches Matthew Auld
2023-03-01 14:48 ` Matthew Auld [this message]
2023-03-07 9:53 ` [Intel-xe] [PATCH 1/6] drm/xe: add xe_ttm_stolen_cpu_access_needs_ggtt() Gwan-gyeong Mun
2023-03-07 11:12 ` Matthew Auld
2023-03-01 14:48 ` [Intel-xe] [PATCH 2/6] drm/xe/mmio: s/lmem/vram/ Matthew Auld
2023-03-07 10:03 ` Gwan-gyeong Mun
2023-03-07 11:27 ` Matthew Auld
2023-03-07 16:26 ` Lucas De Marchi
2023-03-01 14:48 ` [Intel-xe] [PATCH 3/6] drm/xe/vram: start tracking the io_size Matthew Auld
2023-03-07 11:55 ` Gwan-gyeong Mun
2023-03-07 12:23 ` Matthew Auld
2023-03-01 14:48 ` [Intel-xe] [PATCH 4/6] drm/xe/buddy: remove the virtualized start Matthew Auld
2023-03-01 14:48 ` [Intel-xe] [PATCH 5/6] drm/xe/buddy: add visible tracking Matthew Auld
2023-03-01 14:48 ` [Intel-xe] [PATCH 6/6] drm/xe/buddy: add compatible and intersects hooks Matthew Auld
2023-03-01 14:55 ` [Intel-xe] ✓ CI.Patch_applied: success for Some small-bar prep patches Patchwork
2023-03-01 14:56 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-03-01 15:00 ` [Intel-xe] ✓ CI.Build: " 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=20230301144815.248239-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).