All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: "Umesh Nerlige Ramappa" <umesh.nerlige.ramappa@intel.com>,
	"José Roberto de Souza" <jose.souza@intel.com>,
	intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/xe/oa/uapi: Make bit masks unsigned
Date: Mon, 29 Jul 2024 14:54:58 -0700	[thread overview]
Message-ID: <87cymv279p.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <s7tjuildazggjsuza53ixn3ts7t6rw2rwy2et4neijbnkx6ve7@nb4pyxmhhquj>

On Mon, 29 Jul 2024 06:21:20 -0700, Lucas De Marchi wrote:
>

Hi Lucas,

> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
>
> That fixes the build, but question to Ashutosh: it's odd to tie the
> format to a bspec. What happens on next platform if the HW changes?
> Hopefully it doesn't change in an incompatible way, but looking at this
> code it seems we could still keep the uapi by untying the HW from the
> uapi in the documentation.

IMO, in this case, it is not possible to decouple the formats from Bspec
because that is where they are specified (in Bspec 52198/60942).

In i915 the OA formats were specified by an enum (enum drm_i915_oa_format),
but I would argue that enum is meaningful only when we refer back to Bspec.
Also the i915 enum had to constantly updated when HW added new formats.

For Xe, we changed the way the formats are specified in a way which we
believe will make the uapi more robust and uapi header update much less
frequent (hopefully we will never have to update the header and if at all
we have to, we should be able to do it in a backwards compatible way since
we have sufficient number of free bits). HW has followed this scheme for
specifying the formats for years and only recently for Xe2 has added a
couple of bits and introduced new PEC formats which I think it is not going
to change now for some time.

But as I said the formats have to refer back to Bspec since that is where
there are specified and there are too many of them. Any description or enum
is ambiguous unless it refers back to Bspec. So I don't see how not to
refer to Bspec in the documentation. If anyone has any ideas about not
referring to Bspec I am willing to consider it but I think the best way
forward is to leave the documentation as is:

	/*
	 * OA_FORMAT's are specified the same way as in PRM/Bspec 52198/60942,
	 * in terms of the following quantities: a. enum @drm_xe_oa_format_type
	 * b. Counter select c. Counter size and d. BC report. Also refer to the
	 * oa_formats array in drivers/gpu/drm/xe/xe_oa.c.
	 */
#define DRM_XE_OA_FORMAT_MASK_FMT_TYPE		(0xff << 0)
#define DRM_XE_OA_FORMAT_MASK_COUNTER_SEL	(0xff << 8)
#define DRM_XE_OA_FORMAT_MASK_COUNTER_SIZE	(0xff << 16)
#define DRM_XE_OA_FORMAT_MASK_BC_REPORT		(0xff << 24)

Thanks.
--
Ashutosh

  reply	other threads:[~2024-07-29 22:03 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-29  9:26 [PATCH] drm/xe/oa/uapi: Make bit masks unsigned Geert Uytterhoeven
2024-07-29  9:43 ` ✓ CI.Patch_applied: success for " Patchwork
2024-07-29  9:43 ` ✗ CI.checkpatch: warning " Patchwork
2024-07-29  9:44 ` ✓ CI.KUnit: success " Patchwork
2024-07-29  9:56 ` ✓ CI.Build: " Patchwork
2024-07-29  9:58 ` ✓ CI.Hooks: " Patchwork
2024-07-29 10:00 ` ✓ CI.checksparse: " Patchwork
2024-07-29 10:21 ` ✓ CI.BAT: " Patchwork
2024-07-29 11:51 ` ✗ CI.FULL: failure " Patchwork
2024-07-29 13:21 ` [PATCH] " Lucas De Marchi
2024-07-29 21:54   ` Dixit, Ashutosh [this message]
2024-07-30 20:58     ` Lucas De Marchi

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=87cymv279p.wl-ashutosh.dixit@intel.com \
    --to=ashutosh.dixit@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jose.souza@intel.com \
    --cc=lucas.demarchi@intel.com \
    --cc=umesh.nerlige.ramappa@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.