Message ID | 1450380351-28397-6-git-send-email-joonas.lahtinen@linux.intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Thu, Dec 17, 2015 at 09:25:50PM +0200, Joonas Lahtinen wrote: > Add helpers to reduce the amount of noise. Use the i915.debug parameter > introduced in the previous patch to decide on whether to display all > debug messages or just ones that are meaningful to end user. > > Take for example the CI environment, we want to see all possible warning > messages even though the system continues to operate. Opposite to that is > environment in daily use, repeating errors should be displayed once to > indicate the need for a bug report, but if the machine continues to work, > we should not spam the user continuously. One thing, if we have a helper that we think will be generally useful (outside of our module), we have taken the liberty in the past in giving it a non-specific name, e.g. WARN_RECUR(); That would mean we would use WARN_RECUR(cond, i915.debug, "foo has barred\n")) instead. The theory being is that if it is useful we can then lift it to the core. -Chris
On to, 2015-12-17 at 21:10 +0000, Chris Wilson wrote: > On Thu, Dec 17, 2015 at 09:25:50PM +0200, Joonas Lahtinen wrote: > > Add helpers to reduce the amount of noise. Use the i915.debug > > parameter > > introduced in the previous patch to decide on whether to display > > all > > debug messages or just ones that are meaningful to end user. > > > > Take for example the CI environment, we want to see all possible > > warning > > messages even though the system continues to operate. Opposite to > > that is > > environment in daily use, repeating errors should be displayed once > > to > > indicate the need for a bug report, but if the machine continues to > > work, > > we should not spam the user continuously. > > One thing, if we have a helper that we think will be generally useful > (outside of our module), we have taken the liberty in the past in > giving > it a non-specific name, e.g. WARN_RECUR(); > > That would mean we would use WARN_RECUR(cond, i915.debug, "foo has > barred\n")) > instead. > > The theory being is that if it is useful we can then lift it to the > core. This makes sense. Regards, Joonas > -Chris >
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 37fce5a..07240af 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -110,6 +110,32 @@ unlikely(__ret_warn_on); \ }) +#define I915_DEBUG(condition, format...) ({ \ + int __ret_debug_on = !!(condition); \ + if (unlikely(__ret_debug_on)) \ + WARN(unlikely(i915.debug), format); \ + unlikely(__ret_debug_on); \ +}) + +#define I915_DEBUG_ON(condition) ({ \ + static const char __debug_on_txt[] = \ + "I915_DEBUG_ON(" __stringify(condition) ")\n"; \ + int __ret_debug_on = !!(condition); \ + if (unlikely( __ret_debug_on)) \ + WARN(unlikely(i915.debug), __debug_on_txt); \ + unlikely(__ret_debug_on); \ +}) + +#define I915_WARN_RECUR(condition, format...) ({ \ + static bool __section(.data.unlikely) __warned; \ + int __ret_warn_on = !!(condition); \ + if (unlikely(__ret_warn_on)) { \ + if (WARN(unlikely(!__warned || i915.debug), format)) \ + __warned = true; \ + } \ + unlikely(__ret_debug_on); \ +}) + static inline const char *yesno(bool v) { return v ? "yes" : "no";
Add helpers to reduce the amount of noise. Use the i915.debug parameter introduced in the previous patch to decide on whether to display all debug messages or just ones that are meaningful to end user. Take for example the CI environment, we want to see all possible warning messages even though the system continues to operate. Opposite to that is environment in daily use, repeating errors should be displayed once to indicate the need for a bug report, but if the machine continues to work, we should not spam the user continuously. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> --- drivers/gpu/drm/i915/i915_drv.h | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+)