[Intel-xe] [PATCH] drm/xe: Introduce xe_ASSERT macros

[Jani Nikula]

On Tue, 08 Aug 2023, Lucas De Marchi <lucas.demarchi at intel.com> wrote:
> On Mon, Aug 07, 2023 at 07:34:46PM +0200, Michal Wajdeczko wrote:
>>As we are moving away from the controversial XE_BUG_ON macro,
>>relying just on WARN_ON or drm_err does not cover the cases
>>where we want to annotate functions with additional detailed
>>debug checks to assert that all prerequisites are satisfied,
>>without paying footprint or performance penalty on non-debug
>>builds, where all misuses introduced during code integration
>>were already fixed.
>>
>>Introduce family of xe_ASSERT macros that try to follow classic
>>assert() utility and can be compiled out on non-debug builds.
>>
>>Macros are based on drm_WARN, but unlikely to origin, disallow
>>use in expressions since we will compile that code out.
>>
>>As we are operating on the xe pointers, we can print additional
>>information about the device, like tile or GT identifier, that
>>is not available from generic WARN report:
>>
>>[ ] xe 0000:00:02.0: [drm] Assertion `true == false` failed!
>>    platform: 1 subplatform: 1
>>    graphics: Xe_LP 12.0 step B0
>>    media: Xe_M 12.0 step B0
>>    display: enabled step D0
>>    tile: 0 VRAM 0 B
>>    GT: 0 type 1
>>
>>[ ] xe 0000:b3:00.0: [drm] Assertion `true == false` failed!
>>    platform: 7 subplatform: 3
>>    graphics: Xe_HPG 12.55 step A1
>>    media: Xe_HPM 12.55 step A1
>>    display: disabled step **
>>    tile: 0 VRAM 14.0 GiB
>>    GT: 0 type 1
>>
>>[ ] WARNING: CPU: 0 PID: 2687 at drivers/gpu/drm/xe/xe_device.c:281 xe_device_probe+0x374/0x520 [xe]
>>[ ] RIP: 0010:xe_device_probe+0x374/0x520 [xe]
>>[ ] Call Trace:
>>[ ]  ? __warn+0x7b/0x160
>>[ ]  ? xe_device_probe+0x374/0x520 [xe]
>>[ ]  ? report_bug+0x1c3/0x1d0
>>[ ]  ? handle_bug+0x42/0x70
>>[ ]  ? exc_invalid_op+0x14/0x70
>>[ ]  ? asm_exc_invalid_op+0x16/0x20
>>[ ]  ? xe_device_probe+0x374/0x520 [xe]
>>[ ]  ? xe_device_probe+0x374/0x520 [xe]
>>[ ]  xe_pci_probe+0x6e3/0x950 [xe]
>>[ ]  ? lockdep_hardirqs_on+0xc7/0x140
>>[ ]  pci_device_probe+0x9e/0x160
>>[ ]  really_probe+0x19d/0x400
>>
>>Signed-off-by: Michal Wajdeczko <michal.wajdeczko at intel.com>
>>Cc: Oded Gabbay <ogabbay at kernel.org>
>>Cc: Jani Nikula <jani.nikula at intel.com>
>>Cc: Rodrigo Vivi <rodrigo.vivi at intel.com>
>>Cc: Matthew Brost <matthew.brost at intel.com>
>>---
>> drivers/gpu/drm/xe/xe_assert.h | 160 +++++++++++++++++++++++++++++++++
>> 1 file changed, 160 insertions(+)
>> create mode 100644 drivers/gpu/drm/xe/xe_assert.h
>>
>>diff --git a/drivers/gpu/drm/xe/xe_assert.h b/drivers/gpu/drm/xe/xe_assert.h
>>new file mode 100644
>>index 000000000000..7ea295b7091c
>>--- /dev/null
>>+++ b/drivers/gpu/drm/xe/xe_assert.h
>>@@ -0,0 +1,160 @@
>>+/* SPDX-License-Identifier: MIT */
>>+/*
>>+ * Copyright © 2023 Intel Corporation
>>+ */
>>+
>>+#ifndef __XE_ASSERT_H__
>>+#define __XE_ASSERT_H__
>>+
>>+#include <linux/string_helpers.h>
>>+#include <drm/drm_print.h>
>>+#include "xe_device_types.h"
>>+#include "xe_step.h"
>>+
>>+/**
>>+ * DOC: Xe ASSERTs
>>+ *
>>+ * While Xe driver aims to be simpler than legacy i915 driver it is still
>>+ * complex enough that some changes introduced while adding new functionality
>>+ * could break the existing code.
>>+ *
>>+ * Adding &drm_WARN or &drm_err to catch unwanted programming usage could lead
>>+ * to undesired increased driver footprint and may impact production driver
>>+ * performance as this additional code will be always present.
>>+ *
>>+ * To allow annotate functions with additional detailed debug checks to assert
>>+ * that all prerequisites are satisfied, without worrying about footprint or
>>+ * performance penalty on production builds where all potential misuses
>>+ * introduced during code integration were already fixed, we introduce family
>>+ * of ASSERT macros that try to follow classic assert() utility and can be
>>+ * compiled out on non-debug builds:
>>+ *
>>+ *  * &xe_ASSERT
>
> pass by comment, not really checking anything else here... Why are we
> mixing upper/lower case? It's perfectly fine to use XE_ as the namespace
> like is done for other macros.

I think it comes from drm_WARN, but yeah, could be XE_ASSERT.

>
> Lucas De Marchi

-- 
Jani Nikula, Intel Open Source Graphics Center