From: "Summers, Stuart" <stuart.summers@intel.com>
To: "Summers, Stuart" <stuart.summers@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"Lin, Shuicheng" <shuicheng.lin@intel.com>,
"Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
"Roper, Matthew D" <matthew.d.roper@intel.com>,
"Brost, Matthew" <matthew.brost@intel.com>,
"Wajdeczko, Michal" <michal.wajdeczko@intel.com>,
"Nerlige Ramappa, Umesh" <umesh.nerlige.ramappa@intel.com>,
"Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>
Subject: Re: [PATCH 00/10] Add new debug infrastructure for configfs
Date: Fri, 21 Aug 2026 19:27:40 +0000 [thread overview]
Message-ID: <0ba4ffc43ff72d710db8d3bd834879e76232cf2b.camel@intel.com> (raw)
In-Reply-To: <20260820210639.107524-12-stuart.summers@intel.com>
I have the test changes for this up on the IGT mailing list:
https://patchwork.freedesktop.org/series/172602/
Thanks,
Stuart
On Thu, 2026-08-20 at 21:06 +0000, Stuart Summers wrote:
> Add a new configfs debug group. The intent of this structure is
> to allow us to separate ABI facing configfs entries from those
> which are purely for debug purposes. And it allows us more
> flexibility
> in how we define those parameters used for debug.
>
> Add a new infrastructure to this debug configfs group that lets us
> easily define the parameters in a quick list. This is primarily
> useful for simple, single-type parameters such as enable/disable
> features or simple values passed. For more complex parameters,
> we will still need to define these separately.
>
> Pull the GuC target related changes from [1] to fit within
> this new structure and add a new definition for guc_log_level
> on top of the existing module parameter (to ensure we aren't
> impacting existing users of the module parameter).
>
> Note that the debug parameters here are all to be used "at your
> own risk". Without having in depth knowledge of how these impact
> the software and hardware, there could be unforeseen consequences
> of setting them. As such, they are all wrapped in a
> CONFIG_DRM_XE_DEBUG configfs option.
>
> In terms of the patches here, I'm sorting the existing parameters
> by name/type. I know we have a few other module parameters that
> could migrate here, but I didn't want to overload this series
> too much, so the focus for now is on the existing configfs entries
> and demonstrating the new structures with the GuC log level and
> target parameters.
>
> I used GitHub Copilot with Claude pretty extensively through the
> process here and attributed as such. Happy to answer any questions
> around this. Took a bit of time getting back to this series around
> other work, and in that time I was playing around with a few
> different
> models, hence some of the patches are showing multiple of them. I
> tried to attribute each as I was implementing the changes.
>
> I also decided to drop John Harrison from the NPK patch. It has
> been modified quite a bit from the original, but more importantly
> John is no longer with Intel and that email address isn't available
> any more. If it makes a difference here, John and I had both
> separately
> implemented this same change at different occasions for debug. The
> one I used to start that initial series was cherry-picked from his
> latest variant.
>
> v2:
> - In this second revision I did confirm that the guc_log_level
> module parameter is taking precedence over the configfs parameter
> and ensured the other parameters seem to be autogenerating and
> working as expected.
> - I tried to address all the review feedback from the first
> revision, [2].
> - I also did another pass on the sorting since there were a few
> discrepancies I noticed in the first revision. I kept Gustavo's
> R-B on that one, but would like an ack before merging at least
> to confirm the patch is sane.
> - And finally I moved the getter functions into the X-macro
> generators so we can autogenerate more of the similar functions
> between the different parameters in that debug param list.
> v3:
> - Address a couple of comments from Sashiko around GuC log level
> input checking and proper guard implementation.
> v4:
> - More review feedback from Sashiko addressed...
> v5:
> - Move the goto to a return (more Sashiko feedback) in the GuC
> log level setter before moving to the X-macro solution.
> v6:
> - Make the autogenerated X-macro function names more specific to
> avoid naming collisions (Sashiko again).
>
> Stuart Summers (10):
> drm/xe: Guard configfs attribute reads in getters
> drm/xe: Sort xe_config_device fields
> drm/xe: Split out configfs data structures
> drm/xe: Add a new debug focused configfs group
> drm/xe: Move debug configfs entries to xe_configfs_debug.c
> drm/xe/guc: Add configfs support for guc_log_level
> drm/xe/guc: Add support for NPK as a GuC log target
> drm/xe: Add infrastructure for debug configfs parameters
> drm/xe: Migrate existing debug configfs entries to params
> infrastructure
> drm/xe: Taint kernel when debug configfs parameters are set
>
> drivers/gpu/drm/xe/Makefile | 2 +
> drivers/gpu/drm/xe/abi/guc_log_abi.h | 8 +
> drivers/gpu/drm/xe/xe_configfs.c | 1017 +--------------
> --
> drivers/gpu/drm/xe/xe_configfs.h | 90 +-
> drivers/gpu/drm/xe/xe_configfs_debug.c | 872 ++++++++++++++
> drivers/gpu/drm/xe/xe_configfs_debug.h | 48 +
> drivers/gpu/drm/xe/xe_configfs_debug_params.c | 158 +++
> drivers/gpu/drm/xe/xe_configfs_debug_params.h | 194 ++++
> drivers/gpu/drm/xe/xe_configfs_types.h | 59 +
> drivers/gpu/drm/xe/xe_defaults.h | 5 +
> drivers/gpu/drm/xe/xe_guc.c | 14 +-
> drivers/gpu/drm/xe/xe_guc_ads.c | 1 +
> drivers/gpu/drm/xe/xe_guc_log.c | 3 +-
> drivers/gpu/drm/xe/xe_hw_engine.c | 1 +
> drivers/gpu/drm/xe/xe_lrc.c | 1 +
> drivers/gpu/drm/xe/xe_pci.c | 1 +
> drivers/gpu/drm/xe/xe_psmi.c | 3 +-
> drivers/gpu/drm/xe/xe_rtp.c | 3 +-
> drivers/gpu/drm/xe/xe_survivability_mode.c | 1 +
> 19 files changed, 1495 insertions(+), 986 deletions(-)
> create mode 100644 drivers/gpu/drm/xe/xe_configfs_debug.c
> create mode 100644 drivers/gpu/drm/xe/xe_configfs_debug.h
> create mode 100644 drivers/gpu/drm/xe/xe_configfs_debug_params.c
> create mode 100644 drivers/gpu/drm/xe/xe_configfs_debug_params.h
> create mode 100644 drivers/gpu/drm/xe/xe_configfs_types.h
>
next prev parent reply other threads:[~2026-08-21 19:28 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 21:06 [PATCH 00/10] Add new debug infrastructure for configfs Stuart Summers
2026-08-20 21:06 ` [PATCH 01/10] drm/xe: Guard configfs attribute reads in getters Stuart Summers
2026-08-20 21:24 ` sashiko-bot
2026-08-21 20:42 ` Matt Roper
2026-08-20 21:06 ` [PATCH 02/10] drm/xe: Sort xe_config_device fields Stuart Summers
2026-08-20 21:24 ` sashiko-bot
2026-08-21 21:06 ` Matt Roper
2026-08-20 21:06 ` [PATCH 03/10] drm/xe: Split out configfs data structures Stuart Summers
2026-08-21 21:16 ` Matt Roper
2026-08-20 21:06 ` [PATCH 04/10] drm/xe: Add a new debug focused configfs group Stuart Summers
2026-08-21 22:08 ` Matt Roper
2026-08-20 21:06 ` [PATCH 05/10] drm/xe: Move debug configfs entries to xe_configfs_debug.c Stuart Summers
2026-08-20 21:28 ` sashiko-bot
2026-08-21 22:18 ` Matt Roper
2026-08-20 21:06 ` [PATCH 06/10] drm/xe/guc: Add configfs support for guc_log_level Stuart Summers
2026-08-20 21:06 ` [PATCH 07/10] drm/xe/guc: Add support for NPK as a GuC log target Stuart Summers
2026-08-20 21:06 ` [PATCH 08/10] drm/xe: Add infrastructure for debug configfs parameters Stuart Summers
2026-08-20 21:06 ` [PATCH 09/10] drm/xe: Migrate existing debug configfs entries to params infrastructure Stuart Summers
2026-08-20 21:06 ` [PATCH 10/10] drm/xe: Taint kernel when debug configfs parameters are set Stuart Summers
2026-08-20 21:24 ` sashiko-bot
2026-08-20 22:12 ` ✗ CI.checkpatch: warning for Add new debug infrastructure for configfs (rev7) Patchwork
2026-08-20 22:13 ` ✓ CI.KUnit: success " Patchwork
2026-08-20 22:52 ` ✓ Xe.CI.BAT: " Patchwork
2026-08-21 1:28 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-08-21 19:27 ` Summers, Stuart [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-08-20 20:07 [PATCH 00/10] Add new debug infrastructure for configfs Stuart Summers
2026-08-07 19:45 Stuart Summers
2026-08-05 23:20 Stuart Summers
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=0ba4ffc43ff72d710db8d3bd834879e76232cf2b.camel@intel.com \
--to=stuart.summers@intel.com \
--cc=daniele.ceraolospurio@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=matthew.d.roper@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=shuicheng.lin@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox