By moving the GSI adjustment fields into 'struct xe_mmio' we can replace
the GT's MMIO substructure with another instance of xe_mmio. At the
moment this means MMIO operations wind up pulling information from two
different places (the tile's xe_mmio for the iomap and the GT's xe_mmio
for the adjustment), but we'll address that in future patches.
The type headers change a bit with this change, meaning that various
files should be including xe_device_types.h instead of (or in addition
to) xe_gt_types.h.
v2:
- Fix pre-existing kerneldoc typo while moving the fields (Lucas)
v3:
- Add missing '@' in kerneldoc. (Rodrigo)
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240910234719.3335472-49-matthew.d.roper@intel.com
Since commit 178c0a33c4 ("drm/print: Add generic drm dev printk
function") the output from drm_WARN() includes previously missing
the [drm] tag, so now xe_assert() is printing it twice:
[ ] xe 0000:00:02.0: [drm] [drm] Assertion `false` failed!
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240902190726.1748-1-michal.wajdeczko@intel.com
Depending on the context, it's preferred to have a const pointer to make
sure nothing is modified underneath. The assert macros only ever read
data from xe/tile/gt for printing, so they can be made const by default.
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://lore.kernel.org/r/20230922174320.2372617-1-lucas.demarchi@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
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.00 step B0
media: Xe_M 12.00 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
v2: use lowercase names
v3: apply xe coding style
v4: fix non-debug build and improve kernel-doc
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Oded Gabbay <ogabbay@kernel.org>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
