From: Jani Nikula <jani.nikula@intel.com>
To: Arun R Murthy <arun.r.murthy@intel.com>,
intel-gfx@lists.freedesktop.org, ville.syrjala@intel.com
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Remove the modparam verbose_state_checks
Date: Thu, 12 Oct 2023 13:46:18 +0300 [thread overview]
Message-ID: <87wmvs15l1.fsf@intel.com> (raw)
In-Reply-To: <20231012100834.1333221-1-arun.r.murthy@intel.com>
On Thu, 12 Oct 2023, Arun R Murthy <arun.r.murthy@intel.com> wrote:
> By default warn_on are enabled, hence removing this module parameter.
I'm uneasy about this change, though.
Do we really want to force people to see WARNs (and oops if
panic_on_warn=1) on state checker? On the other hand, that's the way to
get bug reports and fix the stuff...
I wonder if distros actually use the module parameter.
An alternative might be to add a debug config option.
> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_display.h | 2 +-
> drivers/gpu/drm/i915/i915_params.c | 4 ----
> drivers/gpu/drm/i915/i915_params.h | 1 -
> 3 files changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h b/drivers/gpu/drm/i915/display/intel_display.h
> index 0e5dffe8f018..8e2453e010a7 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -552,7 +552,7 @@ bool assert_port_valid(struct drm_i915_private *i915, enum port port);
> struct drm_device *drm = &(__i915)->drm; \
> int __ret_warn_on = !!(condition); \
> if (unlikely(__ret_warn_on)) \
> - if (!drm_WARN(drm, i915_modparams.verbose_state_checks, format)) \
> + if (!drm_WARN(drm, true, format)) \
> drm_err(drm, format); \
Everything in the whole macro is about that one condition on the verbose
state checks, and with that taken away, it all simplifies to something
along the lines of:
#define I915_STATE_WARN(__i915, condition, ...) \
drm_WARN(&(__i915)->drm, condition, ## __VA_ARGS__)
I didn't build check that I got the va arg stuff right, but it's
something like that *if* we want to remove the condition altogether.
The comment also becomes stale and needs to be fixed.
BR,
Jani.
> unlikely(__ret_warn_on); \
> })
> diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c
> index 036c4c3ed6ed..23453d9be175 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -162,10 +162,6 @@ i915_param_named(mmio_debug, int, 0400,
> "Enable the MMIO debug code for the first N failures (default: off). "
> "This may negatively affect performance.");
>
> -/* Special case writable file */
> -i915_param_named(verbose_state_checks, bool, 0600,
> - "Enable verbose logs (ie. WARN_ON()) in case of unexpected hw state conditions.");
> -
> i915_param_named_unsafe(nuclear_pageflip, bool, 0400,
> "Force enable atomic functionality on platforms that don't have full support yet.");
>
> diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h
> index d5194b039aab..af675618ab07 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -83,7 +83,6 @@ struct drm_printer;
> param(bool, force_reset_modeset_test, false, 0600) \
> param(bool, error_capture, true, IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR) ? 0600 : 0) \
> param(bool, disable_display, false, 0400) \
> - param(bool, verbose_state_checks, true, 0) \
> param(bool, nuclear_pageflip, false, 0400) \
> param(bool, enable_dp_mst, true, 0600) \
> param(bool, enable_gvt, false, IS_ENABLED(CONFIG_DRM_I915_GVT) ? 0400 : 0)
--
Jani Nikula, Intel
next prev parent reply other threads:[~2023-10-12 10:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-12 10:08 [Intel-gfx] [PATCH] drm/i915: Remove the modparam verbose_state_checks Arun R Murthy
2023-10-12 10:46 ` Jani Nikula [this message]
2023-10-12 14:02 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for " Patchwork
2023-10-12 14:14 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-10-13 12:33 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
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=87wmvs15l1.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=arun.r.murthy@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@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.