Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Stuart Summers <stuart.summers@intel.com>
Cc: stuart.summers@intel.com, lucas.demarchi@intel.com,
	matthew.d.roper@intel.com, intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH 0/4] RFC: Add new device configuration infrastructure to
Date: Thu, 20 Apr 2023 12:32:55 +0300	[thread overview]
Message-ID: <87mt32x5iw.fsf@intel.com> (raw)
In-Reply-To: <20230419175501.155319-1-stuart.summers@intel.com>

On Wed, 19 Apr 2023, Stuart Summers <stuart.summers@intel.com> wrote:
> This is attempting to take the best parts of i915 module parameters
> (minus the actual module parameters) and add to xe to allow for better
> debuggability and configuration in order to help isolate problems
> on a per-device level instead of global module parameters.
>
> Note that I did review a few options here: configfs (not generally
> used by the drm stack), module parameters (we have some negative
> history here), sysfs (not the right approach given the focus on
> user interface here). Debugfs is used in various drm drivers to
> configure various device characteristics. The infrastructure being
> presented here has at a high level been present in the i915 driver
> for some years now, so provides a good starting point for quick
> debug additions without exposing users to some of the challenges
> faced with module parameters in the past.

Looking into configfs has been on my todo list for a long time. It's
something that often gets recommended as a replacement to module
parameters, but the documentation as well as the existing examples in
the kernel are, I think, less than stellar. Basically would require
implementing it and seeing how it actually works.

In any case, I don't think it should be dismissed with just "not
generally used by the drm stack". A decent implementation could set the
example going forward.

The main problem with debugfs is the inability to set the default values
prior to probing the device. This is where module parameters are handy,
but they aren't device specific (and, as you note, generally
discouraged).

Looking at the patches, I'm not sure I understand what the procedure for
setting the debugfs values before probing the device would be. Can you
provide an example sequence on the command-line please?


BR,
Jani.

>
> Stuart Summers (4):
>   drm/xe: Refactor early device init
>   drm/xe: Refactor debugfs into an early and late part
>   drm/xe: Add new device configuration debugfs infrastructure
>   drm/xe: Migrate module parameters to new debugfs structure
>
>  drivers/gpu/drm/xe/Makefile            |   1 +
>  drivers/gpu/drm/xe/xe_debugfs.c        |  14 +-
>  drivers/gpu/drm/xe/xe_debugfs.h        |   1 +
>  drivers/gpu/drm/xe/xe_debugfs_params.c | 235 +++++++++++++++++++++++++
>  drivers/gpu/drm/xe/xe_debugfs_params.h |  14 ++
>  drivers/gpu/drm/xe/xe_device.c         |  23 ++-
>  drivers/gpu/drm/xe/xe_device.h         |   4 +-
>  drivers/gpu/drm/xe/xe_device_types.h   |   4 +
>  drivers/gpu/drm/xe/xe_display.c        |   3 +-
>  drivers/gpu/drm/xe/xe_guc_log.c        |   2 +-
>  drivers/gpu/drm/xe/xe_mmio.c           |   4 +-
>  drivers/gpu/drm/xe/xe_module.c         |  16 --
>  drivers/gpu/drm/xe/xe_module.h         |   5 -
>  drivers/gpu/drm/xe/xe_params.c         | 118 +++++++++++++
>  drivers/gpu/drm/xe/xe_params.h         |  43 +++++
>  drivers/gpu/drm/xe/xe_pci.c            |  14 +-
>  16 files changed, 461 insertions(+), 40 deletions(-)
>  create mode 100644 drivers/gpu/drm/xe/xe_debugfs_params.c
>  create mode 100644 drivers/gpu/drm/xe/xe_debugfs_params.h
>  create mode 100644 drivers/gpu/drm/xe/xe_params.c
>  create mode 100644 drivers/gpu/drm/xe/xe_params.h

-- 
Jani Nikula, Intel Open Source Graphics Center

  parent reply	other threads:[~2023-04-20  9:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-19 17:54 [Intel-xe] [PATCH 0/4] RFC: Add new device configuration infrastructure to Stuart Summers
2023-04-19 17:54 ` [Intel-xe] [PATCH 1/4] drm/xe: Refactor early device init Stuart Summers
2023-04-19 17:54 ` [Intel-xe] [PATCH 2/4] drm/xe: Refactor debugfs into an early and late part Stuart Summers
2023-04-19 17:55 ` [Intel-xe] [PATCH 3/4] drm/xe: Add new device configuration debugfs infrastructure Stuart Summers
2023-05-05 14:55   ` Rodrigo Vivi
2023-05-05 16:21     ` Summers, Stuart
2023-04-19 17:55 ` [Intel-xe] [PATCH 4/4] drm/xe: Migrate module parameters to new debugfs structure Stuart Summers
2023-04-19 17:57 ` [Intel-xe] ✗ CI.Patch_applied: failure for RFC: Add new device configuration infrastructure to Patchwork
2023-04-20  9:32 ` Jani Nikula [this message]
2023-04-20 17:45   ` [Intel-xe] [PATCH 0/4] " Summers, Stuart
2023-04-20 18:53   ` Lucas De Marchi
2023-04-20 20:44     ` Summers, Stuart
2023-04-20 20:55       ` Lucas De Marchi
2023-04-21  4:15         ` 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=87mt32x5iw.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.d.roper@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox