From: Matthew Auld <matthew.auld@intel.com>
To: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>,
intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH 1/6] drm/xe: add xe_ttm_stolen_cpu_access_needs_ggtt()
Date: Tue, 7 Mar 2023 11:12:35 +0000 [thread overview]
Message-ID: <cfc9a08d-c7c8-c43d-d0a3-cfa73fbf4df5@intel.com> (raw)
In-Reply-To: <29c89d5f-0d58-2972-4434-31d130d638d3@intel.com>
On 07/03/2023 09:53, Gwan-gyeong Mun wrote:
> Looks good to me.
> By the way, the commit message explained only the case of smallbar, is
> there a way to access stolen memory in the case of dgpu resizable-bar?
It's just a case of whether the stolen portion fits entirely within the
BAR size, or not. If it doesn't then we disable CPU access for stolen
VRAM. Normally with resizable-bar enabled in the BIOS the BAR we are
given is automatically configured to use the full-bar size. The
resize-bar logic in the driver I think is normally never triggered
(outside ofc driver testing with the special modparam). And when
triggered most of the time it just fails anyway, since resizable-bar is
likely disabled or not supported, at least from what I've seen.
>
> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Thanks.
>
> On 3/1/23 4:48 PM, Matthew Auld wrote:
>> 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);
next prev parent reply other threads:[~2023-03-07 11:12 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 ` [Intel-xe] [PATCH 1/6] drm/xe: add xe_ttm_stolen_cpu_access_needs_ggtt() Matthew Auld
2023-03-07 9:53 ` Gwan-gyeong Mun
2023-03-07 11:12 ` Matthew Auld [this message]
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=cfc9a08d-c7c8-c43d-d0a3-cfa73fbf4df5@intel.com \
--to=matthew.auld@intel.com \
--cc=gwan-gyeong.mun@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