All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: John Harrison <john.c.harrison@intel.com>
Cc: "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: Mon, 27 Jan 2025 13:52:27 -0500	[thread overview]
Message-ID: <Z5fV6zQUhk5bdjG7@intel.com> (raw)
In-Reply-To: <cb6a29e0-7baf-4872-8ae9-5374998a5a6d@intel.com>

On Fri, Jan 24, 2025 at 03:56:54PM -0800, John Harrison wrote:
> Ping @Stuart & @Rodrigo? You still have concerns or can this be merged?

no further concerns from my side

Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

> 
> John.
> 
> 
> On 1/21/2025 11:10, John Harrison wrote:
> > 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-27 18:52 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
2025-01-24 23:56     ` John Harrison
2025-01-27 18:52       ` Rodrigo Vivi [this message]
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=Z5fV6zQUhk5bdjG7@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=Intel-Xe@lists.freedesktop.org \
    --cc=john.c.harrison@intel.com \
    --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 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.