Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: John Harrison <john.c.harrison@intel.com>
To: "Summers, Stuart" <stuart.summers@intel.com>,
	"Intel-Xe@Lists.FreeDesktop.Org" <Intel-Xe@Lists.FreeDesktop.Org>
Subject: Re: [PATCH] drm/xe: Upgrade complaint about missing slice info
Date: Tue, 21 Jan 2025 11:10:24 -0800	[thread overview]
Message-ID: <24263415-c44d-47d5-bb92-d3fbc0aa356e@intel.com> (raw)
In-Reply-To: <02d1075214e3ba35645686c1cb479dd5c74b5571.camel@intel.com>

On 1/21/2025 09:42, Summers, Stuart wrote:
> On Fri, 2025-01-17 at 16:54 -0800, John.C.Harrison@Intel.com wrote:
>> From: John Harrison <John.C.Harrison@Intel.com>
>>
>> The steering code needs to know slice/subslice counts and this
>> information should be retrieved from the hwconfig table. However,
>> earlier platforms don't have it, hence the KMD has a fallback path.
>> Newer platforms really should have the entries and if they are
>> missing
>> that is a bug that needs to be fixed in the table.
>>
>> So update the complaint to be an error on newer platforms and remove
>> it completely for older ones that we know are bad (but are not POR
>> for
>> the Xe driver anyway). Also, re-word the message a little to make it
>> clearer what the issue is.
>>
>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>> ---
>>   drivers/gpu/drm/xe/xe_gt_mcr.c | 8 +++++++-
>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_gt_mcr.c
>> b/drivers/gpu/drm/xe/xe_gt_mcr.c
>> index a1676b787fdc..605aad3554e7 100644
>> --- a/drivers/gpu/drm/xe/xe_gt_mcr.c
>> +++ b/drivers/gpu/drm/xe/xe_gt_mcr.c
>> @@ -341,7 +341,13 @@ static unsigned int dss_per_group(struct xe_gt
>> *gt)
>>          return DIV_ROUND_UP(max_subslices, max_slices);
>>   
>>   fallback:
>> -       xe_gt_dbg(gt, "GuC hwconfig cannot provide dss/slice; using
>> typical fallback values\n");
> Agree with Rodrigo that this is still interesting for older platforms
> to show the expectation.
But it does not provide any useful information. You might as well just 
have a loop on initial driver load that prints the warning out ten times 
for any platform prior to LNL. The comment below has all the information 
that the above message tells you (and more, because it actually tells 
you this is expected rather than unexpected). There is zero use in 
spamming the user with debug messages to say something that is an 
absolute guarantee on a given platform.

>
>> +       /*
>> +        * Some older platforms don't have tables or don't have
>> complete tables.
>> +        * Newer platforms should always have the required info.
>> +        */
>> +       if (GRAPHICS_VERx100(gt_to_xe(gt)) >= 2000)
>> +               xe_gt_err(gt, "Slice/Subslice counts missing from
>> hwconfig table; using typical fallback values\n");
> I understand the intent here, but IMO it would be better for this to be
> a warning.
Whereas, if this is a platform which is supposed to have this 
information then it is absolutely an error if that information is 
missing. Something, somewhere is broken and very definitely needs to be 
fixed. Also, while the fallback should be accurate for the platforms 
below, that is not guaranteed to be the case in future. In which case, 
using a fallback may lead to incorrect register accesses. Which, again 
is very definitely an error.

Either it is a new platform and someone forgot to add that information 
to the table. Or it is a new platform that does not conform to this way 
of accessing registers and thus needs a KMD update to support it. Or it 
is an existing platform that got broken because of some regression bug. 
Either way, it is something that we need to catch in CI before the cause 
of the issue makes it out of the door and on to end user systems.

John.

>
> Thanks,
> Stuart
>
>> +
>>          if (gt_to_xe(gt)->info.platform == XE_PVC)
>>                  return 8;
>>          else if (GRAPHICS_VERx100(gt_to_xe(gt)) >= 1250)


  reply	other threads:[~2025-01-21 19:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-18  0:54 [PATCH] drm/xe: Upgrade complaint about missing slice info John.C.Harrison
2025-01-18  1:01 ` Matt Roper
2025-01-18  1:02 ` ✓ CI.Patch_applied: success for " Patchwork
2025-01-18  1:02 ` ✓ CI.checkpatch: " Patchwork
2025-01-18  1:04 ` ✓ CI.KUnit: " Patchwork
2025-01-18  1:22 ` ✓ CI.Build: " Patchwork
2025-01-18  1:24 ` ✓ CI.Hooks: " Patchwork
2025-01-18  1:26 ` ✓ CI.checksparse: " Patchwork
2025-01-18  1:52 ` ✓ Xe.CI.BAT: " Patchwork
2025-01-18 16:09 ` ✗ Xe.CI.Full: failure " Patchwork
2025-01-21 16:29 ` [PATCH] " Rodrigo Vivi
2025-01-21 17:42 ` Summers, Stuart
2025-01-21 19:10   ` John Harrison [this message]
2025-01-24 23:56     ` John Harrison
2025-01-27 18:52       ` Rodrigo Vivi
2025-01-27 17:12     ` Summers, Stuart

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=24263415-c44d-47d5-bb92-d3fbc0aa356e@intel.com \
    --to=john.c.harrison@intel.com \
    --cc=Intel-Xe@Lists.FreeDesktop.Org \
    --cc=stuart.summers@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