From: Matthew Auld <matthew.auld@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>, intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [RFC 3/5] drm/xe: move pat_table into device info
Date: Wed, 30 Aug 2023 10:43:07 +0100 [thread overview]
Message-ID: <5c4f15cf-9387-e906-2a6d-2cd9d69db162@intel.com> (raw)
In-Reply-To: <2atx3jvuevvb3a4duzqkym3n3rglbcbxjfn4smamcmuz3wazhq@kpwcva26aenl>
On 29/08/2023 22:49, Lucas De Marchi wrote:
> On Tue, Aug 29, 2023 at 05:28:44PM +0100, Matthew Auld wrote:
>> We need to able to know the max pat_index range for a given platform, as
>> well being able to lookup the pat_index for a given platform in upcoming
>> vm_bind uapi, where userspace can directly provide the pat_index. Move
>> the platform definition of the pat_table into the device info with the
>> idea of encoding more information about each pat_index in a future
>> patch.
>>
>> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>> Cc: Pallavi Mishra <pallavi.mishra@intel.com>
>> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>> Cc: Matt Roper <matthew.d.roper@intel.com>
>> ---
>> drivers/gpu/drm/xe/xe_device_types.h | 3 +++
>> drivers/gpu/drm/xe/xe_pat.c | 39 ++++++++++++++++++----------
>> drivers/gpu/drm/xe/xe_pat.h | 3 ++-
>> drivers/gpu/drm/xe/xe_pci.c | 6 +++++
>> 4 files changed, 36 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_device_types.h
>> b/drivers/gpu/drm/xe/xe_device_types.h
>> index 5037b8c180b8..06235da647bb 100644
>> --- a/drivers/gpu/drm/xe/xe_device_types.h
>> +++ b/drivers/gpu/drm/xe/xe_device_types.h
>> @@ -238,6 +238,9 @@ struct xe_device {
>> /** @enable_display: display enabled */
>> u8 enable_display:1;
>>
>> + const u32 *pat_table;
>> + int pat_table_n_entries;
>
> as it's expected to have this "owned" by xe_pat, I'd
> use a new substruct "pat" rather than abusing the info.
>
> struct {
> const u32 *table;
> unsigned int n_entries;
> } pat;
>
> Then we can add more fields as we need them (example for annotating the
> idx we want to use for kernel ops)
Ok. That sounds better.
>
>> +
>> #if IS_ENABLED(CONFIG_DRM_XE_DISPLAY)
>> const struct intel_display_device_info *display;
>> struct intel_display_runtime_info display_runtime;
>> diff --git a/drivers/gpu/drm/xe/xe_pat.c b/drivers/gpu/drm/xe/xe_pat.c
>> index a468655db956..f19f5d8dcd94 100644
>> --- a/drivers/gpu/drm/xe/xe_pat.c
>> +++ b/drivers/gpu/drm/xe/xe_pat.c
>> @@ -106,24 +106,17 @@ static void program_pat_mcr(struct xe_gt *gt,
>> const u32 table[], int n_entries)
>> }
>> }
>>
>> -void xe_pat_init(struct xe_gt *gt)
>> +int xe_pat_fill_info(struct xe_device *xe)
>
> xe_pat_init_early() to follow what is done in other places as being a
> "sw initialization only" that only depends on some other fields being
> filled
Ok, will fix.
>
>
>> {
>> - struct xe_device *xe = gt_to_xe(gt);
>> -
>> if (xe->info.platform == XE_METEORLAKE) {
>> - /*
>> - * SAMedia register offsets are adjusted by the write methods
>> - * and they target registers that are not MCR, while for normal
>> - * GT they are MCR
>> - */
>> - if (xe_gt_is_media_type(gt))
>> - program_pat(gt, mtl_pat_table, ARRAY_SIZE(mtl_pat_table));
>> - else
>> - program_pat_mcr(gt, mtl_pat_table,
>> ARRAY_SIZE(mtl_pat_table));
>> + xe->info.pat_table = mtl_pat_table;
>> + xe->info.pat_table_n_entries = ARRAY_SIZE(mtl_pat_table);
>> } else if (xe->info.platform == XE_PVC || xe->info.platform ==
>> XE_DG2) {
>> - program_pat_mcr(gt, pvc_pat_table, ARRAY_SIZE(pvc_pat_table));
>> + xe->info.pat_table = pvc_pat_table;
>> + xe->info.pat_table_n_entries = ARRAY_SIZE(pvc_pat_table);
>> } else if (GRAPHICS_VERx100(xe) <= 1210) {
>> - program_pat(gt, tgl_pat_table, ARRAY_SIZE(tgl_pat_table));
>> + xe->info.pat_table = tgl_pat_table;
>> + xe->info.pat_table_n_entries = ARRAY_SIZE(tgl_pat_table);
>> } else {
>> /*
>> * Going forward we expect to need new PAT settings for most
>> @@ -135,7 +128,25 @@ void xe_pat_init(struct xe_gt *gt)
>> */
>> drm_err(&xe->drm, "Missing PAT table for platform with
>> graphics version %d.%2d!\n",
>> GRAPHICS_VER(xe), GRAPHICS_VERx100(xe) % 100);
>> + return -ENODEV;
>
> that would be an odd error. -ENOTSUPP maybe?
I just take it to mean that something about the device is missing/broken
(I'm pretty sure we have used it like that before). ENOTSUPP would also
work. Will change.
>
>
>> }
>> +
>> + return 0;
>> +}
>> +
>> +void xe_pat_init(struct xe_gt *gt)
>> +{
>> + struct xe_device *xe = gt_to_xe(gt);
>> +
>> + /*
>> + * SAMedia register offsets are adjusted by the write methods
>> + * and they target registers that are not MCR, while for normal
>> + * GT they are MCR.
>> + */
>> + if (xe_gt_is_media_type(gt) || GRAPHICS_VERx100(xe) < 1255)
>> + program_pat(gt, xe->info.pat_table,
>> xe->info.pat_table_n_entries);
>> + else
>> + program_pat_mcr(gt, xe->info.pat_table,
>> xe->info.pat_table_n_entries);
>> }
>>
>> void xe_pte_pat_init(struct xe_device *xe)
>> diff --git a/drivers/gpu/drm/xe/xe_pat.h b/drivers/gpu/drm/xe/xe_pat.h
>> index 54022f591621..9ab059758ad1 100644
>> --- a/drivers/gpu/drm/xe/xe_pat.h
>> +++ b/drivers/gpu/drm/xe/xe_pat.h
>> @@ -26,8 +26,9 @@
>> #define XELPG_PAT_WB_CACHE_1_WAY 3
>>
>> struct xe_gt;
>> -extern struct xe_device *xe;
>> +struct xe_device;
>
> leftover from a previous patch? what was the base you used? I can't see
> this on drm-xe-next.
>
> Lucas De Marchi
>
>>
>> +int xe_pat_fill_info(struct xe_device *xe);
>> void xe_pat_init(struct xe_gt *gt);
>> void xe_pte_pat_init(struct xe_device *xe);
>> unsigned int xe_pat_get_index(struct xe_device *xe, enum
>> xe_cache_level cache);
>> diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
>> index 791107dec045..24f2021aae22 100644
>> --- a/drivers/gpu/drm/xe/xe_pci.c
>> +++ b/drivers/gpu/drm/xe/xe_pci.c
>> @@ -22,6 +22,7 @@
>> #include "xe_gt.h"
>> #include "xe_macros.h"
>> #include "xe_module.h"
>> +#include "xe_pat.h"
>> #include "xe_pci_types.h"
>> #include "xe_pm.h"
>> #include "xe_step.h"
>> @@ -553,6 +554,7 @@ static int xe_info_init(struct xe_device *xe,
>> struct xe_tile *tile;
>> struct xe_gt *gt;
>> u8 id;
>> + int err;
>>
>> xe->info.platform = desc->platform;
>> xe->info.subplatform = subplatform_desc ?
>> @@ -601,6 +603,10 @@ static int xe_info_init(struct xe_device *xe,
>> xe->info.enable_display = IS_ENABLED(CONFIG_DRM_XE_DISPLAY) &&
>> enable_display &&
>> desc->has_display;
>> +
>> + err = xe_pat_fill_info(xe);
>> + if (err)
>> + return err;
>> /*
>> * All platforms have at least one primary GT. Any platform with
>> media
>> * version 13 or higher has an additional dedicated media GT. And
>> --
>> 2.41.0
>>
next prev parent reply other threads:[~2023-08-30 9:43 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-29 16:28 [Intel-xe] [RFC 0/5] PAT and cache coherency support Matthew Auld
2023-08-29 16:28 ` [Intel-xe] [RFC 1/5] drm/xe/uapi: Add support for cache and coherency mode Matthew Auld
2023-08-29 18:09 ` Matt Roper
2023-08-30 11:13 ` Matthew Auld
2023-09-04 20:00 ` Souza, Jose
2023-09-05 9:04 ` Matthew Auld
2023-09-05 15:30 ` Souza, Jose
2023-08-29 16:28 ` [Intel-xe] [RFC 2/5] drm/xe: fix has_llc on rkl Matthew Auld
2023-08-29 18:46 ` Matt Roper
2023-08-30 1:20 ` Mishra, Pallavi
2023-08-29 16:28 ` [Intel-xe] [RFC 3/5] drm/xe: move pat_table into device info Matthew Auld
2023-08-29 19:14 ` Matt Roper
2023-08-29 21:49 ` Lucas De Marchi
2023-08-29 22:20 ` Matt Roper
2023-08-30 9:34 ` Matthew Auld
2023-08-30 9:43 ` Matthew Auld [this message]
2023-08-30 5:14 ` Mishra, Pallavi
2023-09-05 20:50 ` Souza, Jose
2023-08-29 16:28 ` [Intel-xe] [RFC 4/5] drm/xe/pat: annotate pat_index with coherency mode Matthew Auld
2023-08-29 21:08 ` Matt Roper
2023-08-30 9:32 ` Matthew Auld
2023-08-30 19:40 ` Matt Roper
2023-08-29 22:02 ` Lucas De Marchi
2023-08-29 16:28 ` [Intel-xe] [RFC 5/5] drm/xe/uapi: support pat_index selection with vm_bind Matthew Auld
2023-08-29 21:36 ` Matt Roper
2023-08-30 6:38 ` Thomas Hellström
2023-08-30 19:28 ` Matt Roper
2023-08-30 11:28 ` Matthew Auld
2023-08-30 15:27 ` Zhang, Carl
2023-08-30 16:02 ` Matthew Auld
2023-08-31 8:24 ` Zhang, Carl
2023-08-31 10:44 ` Matthew Auld
2023-09-01 9:34 ` Zhang, Carl
2023-09-04 9:23 ` Matthew Auld
2023-09-05 9:12 ` Zhang, Carl
2023-09-05 9:46 ` Matthew Auld
2023-09-05 13:50 ` Zhang, Carl
2023-09-05 14:07 ` Matthew Auld
2023-09-04 20:21 ` Souza, Jose
2023-09-05 9:08 ` Matthew Auld
2023-09-07 18:56 ` Souza, Jose
2023-09-08 6:51 ` Matthew Auld
2023-09-13 15:35 ` Souza, Jose
2023-09-13 15:50 ` Matthew Auld
2023-08-29 16:40 ` [Intel-xe] ✗ CI.Patch_applied: failure for PAT and cache coherency support Patchwork
2023-09-04 20:25 ` [Intel-xe] [RFC 0/5] " Souza, Jose
2023-09-05 9:16 ` Matthew Auld
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=5c4f15cf-9387-e906-2a6d-2cd9d69db162@intel.com \
--to=matthew.auld@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=matthew.d.roper@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