kernel/linux.git/drivers/gpu/drm/i915/Kconfig.debug, branch v6.19.11

drm/i915: Fix selecting CONFIG_DRM_KUNIT_TEST in debug builds

2025-07-25T08:41:55+00:00

Selecting an option which depends on other options only works if the dependencies are guaranteed to be selected (as these dependencies will not be automatically selected). CONFIG_DRM_KUNIT_TEST depends on DRM, MMU and KUNIT the first two of which are guaranteed to be selected for i915, but the last one is not. Hence, selecting CONFIG_DRM_KUNIT_TEST in i915 debug builds may result in CONFIG_DRM_KUNIT_TEST being selected without the CONFIG_KUNIT dependency being selected. This causes at least the following compile error: drivers/gpu/drm/tests/drm_bridge_test.c: In function ‘drm_test_bridge_alloc_init’: drivers/gpu/drm/tests/drm_bridge_test.c:449:21: error: implicit declaration of function ‘kunit_device_register’; did you mean ‘root_device_register’? [-Werror=implicit-function-declaration] 449 | priv->dev = kunit_device_register(test, "drm-bridge-dev"); Fix the above by selecting CONFIG_DRM_KUNIT_TEST only if CONFIG_KUNIT is also selected. Fixes: 17133255a322 ("drm/i915: replace DRM_DEBUG_SELFTEST with DRM_KUNIT_TEST") Cc: Ruben Wauters Cc: Rodrigo Vivi Reviewed-by: Rodrigo Vivi Signed-off-by: Imre Deak Link: https://lore.kernel.org/r/20250724090237.92040-1-imre.deak@intel.com

drm/i915: replace DRM_DEBUG_SELFTEST with DRM_KUNIT_TEST

2025-07-21T14:46:27+00:00

DRM_DEBUG_SELFTEST was removed in commit fc8d29e298cf (drm: selftest: convert drm_mm selftest to KUnit) and all functions under it were converted to KUnit, under the DRM_KUNIT_TEST option This conversion however did not occur in the Kconfig.debug file in the i915 directory. This patch replaces the select for DRM_DEBUG_SELFTEST, an option that no longer exists, with the correct select, DRM_KUNIT_TEST. Signed-off-by: Ruben Wauters Link: https://lore.kernel.org/r/20250701115511.5445-1-rubenru09@aol.com Signed-off-by: Rodrigo Vivi

drm/i915: Support replaying GPU hangs with captured context image

2024-05-16T07:37:05+00:00

When debugging GPU hangs Mesa developers are finding it useful to replay the captured error state against the simulator. But due various simulator limitations which prevent replicating all hangs, one step further is being able to replay against a real GPU. This is almost doable today with the missing part being able to upload the captured context image into the driver state prior to executing the uploaded hanging batch and all the buffers. To enable this last part we add a new context parameter called I915_CONTEXT_PARAM_CONTEXT_IMAGE. It follows the existing SSEU configuration pattern of being able to select which context to apply against, paired with the actual image and its size. Since this is adding a new concept of debug only uapi, we hide it behind a new kconfig option and also require activation with a module parameter. Together with a warning banner printed at driver load, all those combined should be sufficient to guard against inadvertently enabling the feature. In terms of implementation we allow the legacy context set param to be used since that removes the need to record the per context data in the proto context, while still allowing flexibility of specifying context images for any context. Mesa MR using the uapi can be seen at: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27594 v2: * Fix whitespace alignment as per checkpatch. * Added warning on userspace misuse. * Rebase for extracting ce->default_state shadowing. v3: * Rebase for I915_CONTEXT_PARAM_LOW_LATENCY. Signed-off-by: Tvrtko Ursulin Cc: Lionel Landwerlin Cc: Carlos Santa Cc: Rodrigo Vivi Reviewed-by: Rodrigo Vivi Tested-by: Carlos Santa Signed-off-by: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20240514145939.87427-2-tursulin@igalia.com

drm/display: Make DisplayPort AUX Chardev Kconfig name consistent

2024-03-28T10:26:46+00:00

While most display helpers Kconfig symbols have the DRM_DISPLAY prefix, the DisplayPort-AUX chardev interface uses DRM_DP_AUX_CHARDEV. Since the number of users is limited and it's a selected symbol, we can easily rename it to make it consistent. Reviewed-by: Jani Nikula Reviewed-by: Lucas De Marchi Link: https://lore.kernel.org/r/20240327-kms-kconfig-helpers-v3-3-eafee11b84b3@kernel.org Signed-off-by: Maxime Ripard

drm/display: Make DisplayPort tunnel debug Kconfig name consistent

2024-03-28T10:26:46+00:00

While most display helpers Kconfig symbols have the DRM_DISPLAY prefix, the DisplayPort Tunnel debugging uses DRM_DISPLAY_DEBUG_DP_TUNNEL_STATE. Since the number of users is limited and it's a selected symbol, we can easily rename it to make it consistent. Reviewed-by: Jani Nikula Reviewed-by: Lucas De Marchi Link: https://lore.kernel.org/r/20240327-kms-kconfig-helpers-v3-2-eafee11b84b3@kernel.org Signed-off-by: Maxime Ripard

drm/i915/dp: Add support for DP tunnel BW allocation

2024-02-27T15:34:44+00:00

Add support to enable the DP tunnel BW allocation mode. Follow-up patches will call the required helpers added here to prepare for a modeset on a link with DP tunnels, the last change in the patchset actually enabling BWA. With BWA enabled, the driver will expose the full mode list a display supports, regardless of any BW limitation on a shared (Thunderbolt) link. Such BW limits will be checked against only during a modeset, when the driver has the full knowledge of each display's BW requirement. If the link BW changes in a way that a connector's modelist may also change, userspace will get a hotplug notification for all the connectors sharing the same link (so it can adjust the mode used for a display). The BW limitation can change at any point, asynchronously to modesets on a given connector, so a modeset can fail even though the atomic check for it passed. In such scenarios userspace will get a bad link notification and in response is supposed to retry the modeset. v2: - Fix old vs. new connector state in intel_dp_tunnel_atomic_check_state(). (Ville) - Fix propagating the error from intel_dp_tunnel_atomic_compute_stream_bw(). (Ville) - Move tunnel==NULL checks from driver to DRM core helpers. (Ville) - Simplify return flow from intel_dp_tunnel_detect(). (Ville) - s/dp_tunnel_state/inherited_dp_tunnels (Ville) - Simplify struct intel_dp_tunnel_inherited_state. (Ville) - Unconstify object pointers (vs. states) where possible. (Ville) - Init crtc_state while declaring it in check_group_state(). (Ville) - Join obj->base.id, obj->name arg lines in debug prints to reduce LOC. (Ville) - Add/rework intel_dp_tunnel_atomic_alloc_bw() to prepare for moving the BW allocation from encoder hooks up to intel_atomic_commit_tail() later in the patchset. - Disable BW alloc mode during system suspend. - Allocate the required BW for all tunnels during system resume. - Add intel_dp_tunnel_atomic_clear_stream_bw() instead of the open-coded sequence in a follow-up patch. - Add function documentation to all exported functions. - Add CONFIG_USB4 dependency to CONFIG_DRM_I915_DP_TUNNEL. v3: - Rebase on intel_dp_get_active_pipes() change in previous patch. Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä Reviewed-by: Uma Shankar Signed-off-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20240226185246.1276018-4-imre.deak@intel.com

drm/i915: Track gt pm wakerefs

2023-11-20T11:36:56+00:00

Track every intel_gt_pm_get() until its corresponding release in intel_gt_pm_put() by returning a cookie to the caller for acquire that must be passed by on released. When there is an imbalance, we can see who either tried to free a stale wakeref, or who forgot to free theirs. v2: track recently added calls in gen8_ggtt_bind_get_ce and destroyed_worker_func Signed-off-by: Andrzej Hajda Reviewed-by: Andi Shyti Link: https://patchwork.freedesktop.org/patch/msgid/20231030-ref_tracker_i915-v1-2-006fe6b96421@intel.com

drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library

2023-11-20T11:36:54+00:00

Beside reusing existing code, the main advantage of ref_tracker is tracking per instance of wakeref. It allows also to catch double put. On the other side we lose information about the first acquire and the last release, but the advantages outweigh it. Signed-off-by: Andrzej Hajda Reviewed-by: Andi Shyti Link: https://patchwork.freedesktop.org/patch/msgid/20231030-ref_tracker_i915-v1-1-006fe6b96421@intel.com

drm/i915/guc: Track all sent actions to GuC

2023-05-30T22:18:21+00:00

For easier debug of any unexpected error responses from GuC that might be related to non-blocking fast requests, track action code (and stack if under DEBUG_GUC config) for every H2G request. Signed-off-by: Michal Wajdeczko Signed-off-by: John Harrison Reviewed-by: John Harrison Link: https://patchwork.freedesktop.org/patch/msgid/20230526235538.2230780-4-John.C.Harrison@Intel.com

drm/i915: Improve debug Kconfig texts a bit

2021-07-06T08:10:07+00:00

We're not consistently recommending these for developers only. I stumbled over this due to DRM_I915_LOW_LEVEL_TRACEPOINTS, which was added in commit 354d036fcf70654cff2e2cbdda54a835d219b9d2 Author: Tvrtko Ursulin Date: Tue Feb 21 11:01:42 2017 +0000 drm/i915/tracepoints: Add request submit and execute tracepoints to "alleviate the performance impact concerns." Which is nonsense. Tvrtko and Joonas pointed out on irc that the real (but undocumented reason) was stable abi concerns for tracepoints, see https://lwn.net/Articles/705270/ and the specific change that was blocked around tracepoints: https://lwn.net/Articles/442113/ Anyway to make it a notch clearer why we have this Kconfig option consistly add the "Recommended for driver developers only." to it and all the other debug options we have. Cc: Tvrtko Ursulin Cc: Joonas Lahtinen Cc: Matthew Brost Reviewed-by: Joonas Lahtinen Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210702201708.2075793-1-daniel.vetter@ffwll.ch