summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2026-06-24drm/i915/dp_link_training: Use helpers to get forced link paramsImre Deak1-6/+16
Use intel_dp_link_caps_get_forced_params() in the link training fallback code instead of directly accessing the state. This allows the link caps module to track changes to forced parameters internally. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-9-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Move forced and max link debugfs entries to link capsImre Deak4-263/+285
Move the debugfs entries for the forced and max DP link parameters to intel_dp_link_caps. Their functionality is part of the link capability logic and will be updated to use the link capability state in follow-up changes. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-8-imre.deak@intel.com
2026-06-24drm/i915/dp: Simplify querying of forced link parametersImre Deak2-5/+12
Simplify querying the forced link rate and lane count by performing the zero checks inside the helpers, allowing callers to use the returned values directly. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-7-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Move forced link param helpers to link capsImre Deak3-19/+47
Move the helpers handling forced link parameters to intel_dp_link_caps.c. Their functionality is part of the link capability logic and will be updated to use the link capability state in follow-up changes. Return the forced link rate and lane count through a struct intel_dp_link_config, which is the canonical way the rest of the link capability API will also accept and return link configurations. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-6-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Move common rate helpers to link capsImre Deak6-28/+39
Move the helpers handling common link rates to intel_dp_link_caps.c. Their functionality is part of the link capability logic and will be updated to use the link capability state in follow-up changes. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-5-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Introduce DP link capability moduleImre Deak6-0/+55
Start isolating the DP link capability logic from the generic DP code by adding a separate intel_dp_link_caps module and a corresponding state object. Allocate the state so it can remain opaque within its module. Follow-up changes will move link capability helpers and state from intel_dp.c and intel_dp_link_training.c to the new module and state. v2: Remove unnecessary function documentation. (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-4-imre.deak@intel.com
2026-06-24drm/i915/dp: Add struct intel_dp_link_configImre Deak1-0/+8
Add a struct representing the public unpacked format of a link configuration. This will be used by the DP link capability API added as a follow-up, and by DP code in general that needs to track a link configuration. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-3-imre.deak@intel.com
2026-06-24drm/i915/dp: Rename intel_dp_link_config to intel_dp_link_config_entryImre Deak2-9/+9
Rename intel_dp_link_config to intel_dp_link_config_entry to prepare for tracking a link configuration in both an internal packed and a public unpacked format. A follow-up change will add struct intel_dp_link_config representing the public unpacked format. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-2-imre.deak@intel.com
2026-06-24drm/i915/panel: Attempt VRR based refresh rate change for !allow_modesetVille Syrjälä1-3/+39
Adjust the panel fixed mode selection algorithm to only consider fixed modes that are "VRR compatible" with the old fixed mode when userspace doesn't want to allow full modesets. This will allow a VRR based refresh rate changes (ie. just a change in the vblank length) via the fastset path. When full modesets are allowed, we still use the original algorithm as that may pick a fixed mode with a more optimal dotclock, potentially leading to reduced power consumption. This approach works as long as userspace does the initial allow_modeset=true commit using the highest refresh rate it will want to use. Subsequent commits with allow_modeset=false can then switch between lower refresh rates without blinks. One remaining hurdle we may need to solve is the guardband length. Assuming the highest refresh rate vblank is too short for intel_vrr_compute_optimized_guardband() the intitial guardband will match the highest refresh rate vblank. A subsequent switch to a lower refresh rate will then recompute the guardband and select a value that is higher (since the vblank will be longer). The mismatch in guardband lengths will prevent the fastset. We may either have to preserve the original (sub-optimal) guardband, or we'll have to revisit the idea of changing the guardband without a full modeset. Note that I'm not 100% happy with this solution because intel_panel_fixed_mode() is no longer fully idempotent, but I wasn't able to come up with anything truly better either :/ The simple solution would be just to always pick the fixed mode with the highest dotclock, but that could lead to increased power consumption even when high refresh rates are never used. Perhaps the proper solution would be to just deprecate this idea of taking in random modes for internal panels and then cooking up a compatible fixed modes. Life would be easier if userspace was required to provide the desired fixed mode directly. But in order to do that we'd need to introduce new uapi properties to control the pfit aspect of this, and we'd probably need a new client cap to select between the old and new userspace behaviour. Something to consider in the future... v2: Rebase due to earlier changes to VRR fixed mode selection Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> #v1 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260622213602.7244-6-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Tested-by: Vidya Srinivas <vidya.srinivas@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com>
2026-06-24drm/i915/panel: Adjust intel_panel_compute_config() calling conventionVille Syrjälä8-17/+24
Pass the full atomic state to intel_panel_compute_config(). We'll need this for some upcoming VRR fastset tricks. And to accompany full state we'll also need the crtc (or its state) as well. v2: Rebase Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260623114130.7333-1-ville.syrjala@linux.intel.com Tested-by: Vidya Srinivas <vidya.srinivas@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com>
2026-06-24drm/i915: Pass the full atomic state to .compute_config()Ville Syrjälä15-29/+42
Upcoming changes will need access to the full atomic state in .compute_config(). Pass it in from the top. Couple of the implementations already dug this out via the crtc_state/conn_state->state pointer, but we don't want to use that anywhere because it's a bit of a footgun by only being valid during the early stages of the commit. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260622213602.7244-4-ville.syrjala@linux.intel.com Tested-by: Vidya Srinivas <vidya.srinivas@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com>
2026-06-24drm/modes: Add DRM_MODE_MATCH_TIMINGS_VRRVille Syrjälä1-0/+23
Add a new mode matching flag DRM_MODE_MATCH_TIMINGS_VRR. This is identical to DRM_MODE_MATCH_TIMINGS, except it requires the vsync pulse to remain anchored to the end of vtotal, as opposed to the start of the frame. VRR capable hardware can therefore treat matching modes as just variants of the same mode with a different vblank lengths. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260622213602.7244-3-ville.syrjala@linux.intel.com Tested-by: Vidya Srinivas <vidya.srinivas@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com>
2026-06-24drm/i915/panel: Split VRR vs. fixed refresh rate fixed mode selection into ↵Ville Syrjälä1-41/+85
separate stages Split the VRR vs. fixed refresh rate fixed mode selection into two completely separate stages. First try the VRR method, which will only accept fixed modes that are in the VRR range and whose refresh rate is equal or higher to the user's requested mode's refresh rate. If the VRR method doesn't find anything we fall back to the fixed refresh rate method of simply looking for the fixed mode with the closest refresh rate to the user's request. The main benefit is that we will only perform the VRR vtotal adjustment on fixed modes that have equal or higher refresh rate to the user's requested mode, thus we will never end up in a situation where we'd have to shrink the fixed mode's vtotal. This avoids any risk of ending up with a vtotal that is too short. v2: Drop redundant intel_panel_fixed_mode() call (Ankit) Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260623114035.7185-1-ville.syrjala@linux.intel.com Tested-by: Vidya Srinivas <vidya.srinivas@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com>
2026-06-24drm/fb-helper: Remove unused local variable in hotplug_event()Cristian Ciocaltea1-8/+3
Remove the 'err' local variable in drm_fb_helper_hotplug_event() which only stores a return value that is never used beyond the immediate return statement. This simplifies the code without behavior changes. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260602-dw-hdmi-qp-scramb-v7-1-445eb54ee1ed@collabora.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-06-24drm/i915/cdclk: Fix up CDCLK_FREQ_DECIMAL without a full PLL re-enableVille Syrjälä1-7/+34
The GOP (and even Bspec on some platforms) is a bit inconsistent on what the CDCLK_FREQ_DECIMAL divider should be. Currently any mismatch there causes a full CDCLK PLL disable+re-enable, which we really don't want to do if any displays are currently active. Let's instead just reprogram CDCLK_FREQ_DECIMAL when that is the only thing amiss. For any other (more serious) mismatch we still punt to the full PLL reprogramming. We also need to tweak the bxt_cdclk_cd2x_pipe() stuff a bit to consistently select pipe==NONE since we have no idea which pipes are enabled at this point. Since we're not actually changing the CDCLK frequency here we don't need to sync the update to any pipe. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16209 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260612173653.7830-2-ville.syrjala@linux.intel.com Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> (cherry picked from commit 3f9de66f8acbf8ff45a91b4920605ed10c6b7c06) Fixes: ba91b9eecb47 ("drm/i915/cdclk: Decouple cdclk from state->modeset") Fixes: d66a21947e21 ("drm/i915/bxt: Sanitize CDCLK to fix breakage during S4 resume") Fixes: c73666f394fc ("drm/i915/skl: If needed sanitize bios programmed cdclk") Cc: <stable@vger.kernel.org> # v4.5+ Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-06-24drm/i915: Return NULL on error in active_instanceJoonas Lahtinen1-1/+6
Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: bfaae47db3c0 ("drm/i915: make lockdep slightly happier about execbuf.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Simona Vetter <simona.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # v5.13+ Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/20260624090940.74840-1-joonas.lahtinen@linux.intel.com
2026-06-24drm/hibmc: Use gem-shmem with shadow-plane helpers for memory managementThomas Zimmermann5-35/+96
Replace the gem-vram memory manager with gem-shmem. Makes the driver more robust and enables dma-buf sharing with other hardware. Gem-vram was created from various drivers that used TTM for their memory management. All these drivers have meanwhile been converted to gem-shmem. Using gem-vram is deprecated because it has several problems. * TTM requires significant overcommitment of video memory for reliable page flips. There needs to be 3 times the size of the largest possible framebuffer available or page flips can fail. This leaves the display dark without further warning. Hibmc hardware with 32 MiB and a maximum framebuffer size of 1920x2000 is at the limit. * No dma-buf sharing without GTT support. Neither gem-vram nor hibmc hardware support a GTT address space. This is required to share buffers with other devices via dma-buf interfaces. * TTM requires hardware-accelerated rendering into video memory for optimal results. As hibmc hardware cannot do this, hibmc renders in system memory and copies the result to video memory. This can be more effectively implemented with gem-shmem and DRM's shadow-plane helpers. Converting hibmc to gem-shmem and shadow-plane helpers. * Replace gem-vram entry points in struct drm_driver with gem-shmem equivalents. This makes the driver allocate struct drm_gem_shmem_object for its buffers. * Use DRM_GEM_SHADOW_*_PLANE for its plane funcs and plane-helper funcs. The shadow-plane helpers map a plane's gem buffer objects into kernel address space during a page flip, so that atomic_update can copy them to video memory. * Handle framebuffer damage in hibmc_plane_atomic_update(). This updates video memory from the plane's framebuffer. It automatically synchronizes shared buffers with other devices. Create the framebuffer with drm_gem_fb_create_with_dirty() to trigger the update on each page flip. * Initialize the plane with drm_plane_enable_fb_damage_clips() to limit the damage updates to the framebuffer areas that changed. We don't want to do a full-buffer memcpy if only a small area has changed. * Test display modes against the available video memory in hibmc_mode_config_mode_valid(). We only want to announce display modes that fit into display memory. * Map the display memory itself into kernel address space. * Do not set drm_mode_config.prefer_shadow. This would advise user space to install a shadow buffer. But with gem-shmem, the gem buffer object already acts as a shadow buffer for video memory. We use these patterns in many other drivers with similar limitation as hibmc and its hardware. With these changes in place, hibmc is more robust and better integrated into the overall DRM framework. v3: - fix coding style v2: - do not select TTM symbols Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Yongbang Shi <shiyongbang@huawei.com> Link: https://patch.msgid.link/20260618123142.92298-7-tzimmermann@suse.de
2026-06-24drm/hibmc: Verify the framebuffer pitch to be a multiple of 128Thomas Zimmermann1-1/+17
The hibmc hardware requires the framebuffer pitch to be aligned to a multiple of 128. Dumb-buffer creation already guarantees this for the created GEM buffer object. Also verify this contraint during framebuffer creation. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Yongbang Shi <shiyongbang@huawei.com> Link: https://patch.msgid.link/20260618123142.92298-6-tzimmermann@suse.de
2026-06-24drm/hibmc: Do not use cpp from struct drm_format_infoThomas Zimmermann1-2/+9
Replace uses of struct drm_format_info's cpp with appropriate interfaces. The cpp field contains the characters per pixel. It is deprecated and should be avoided. Calculate the line width in bytes with drm_format_info_min_pitch(). This is the preferred way of getting pixel and line sizes. Program HIB_CRT_DISP_CTL_FORMAT from the format's 4CC code instead of calculating the field's value from the cpp. v4: - introduce fb variable in separate patch (Yongbang) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Yongbang Shi <shiyongbang@huawei.com> Link: https://patch.msgid.link/20260618123142.92298-5-tzimmermann@suse.de
2026-06-24drm/hibmc: Store fb in variable in atomic_updateThomas Zimmermann1-8/+7
The atomic-update helper frequently refers to the framebuffer in new_state->fb. Store it in a local variable to make the code more readable. No functional changes. Suggested-by: Yongbang Shi <shiyongbang@huawei.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Yongbang Shi <shiyongbang@huawei.com> Link: https://patch.msgid.link/20260618123142.92298-4-tzimmermann@suse.de
2026-06-24drm/hibmc: Fix list of formats on the primary planeThomas Zimmermann1-4/+2
Remove all formats from the primary plane that are unsupported for various reasons. * Formats with alpha channel: planes should not announce alpha channels unless they support transparency. There's no transparency support in the primary plane's implementation. * Formats with BGR order. The common format is in RGB channel order. There's no BGR support in the primary plane's implementation. * RGB888: atomic_update programs the format from cpp[0] * 8 / 16. For RGB888's cpp value of 3 this returns 1.5; rounded to 1. Programming the value of 1 to HIBMC_CRT_DISP_CTL_FORMAT sets up RGB565. Hence, the output is distorted. This can be tested by booting with video=1024x768-24. Removing all unsupported formats leaves XRGB8888 and RGB565. Both of which are supported and work correctly. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: da52605eea8f ("drm/hisilicon/hibmc: Add support for display engine") Reviewed-by: Yongbang Shi <shiyongbang@huawei.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Xinliang Liu <xinliang.liu@linaro.org> Cc: Dmitry Baryshkov <lumag@kernel.org> Cc: Yongbang Shi <shiyongbang@huawei.com> Cc: Baihan Li <libaihan@huawei.com> Cc: <stable@vger.kernel.org> # v4.10+ Link: https://patch.msgid.link/20260618123142.92298-3-tzimmermann@suse.de
2026-06-24drm/hibmc: Use drm_atomic_helper_check_plane_state()Thomas Zimmermann1-32/+14
Call drm_atomic_helper_check_plane_state() from the primary plane's atomic-check helper and replace the custom implementation. All plane's implementations of atomic_check should call the shared _check_plane_state() helper first. It adjusts the plane state for correct positioning, rotation and scaling of the plane. Do this even if the plane's CRTC has been disabled by setting the parameter can_update_disabled. The original code returned early in this case, but it's safe to so and cleaner to have all plane state initialized. As we don't set can_position, drm_atomic_helper_check_plane_state()'s visibility check tests if the plane covers all of the CRTC. This is a small change from the original code, which tested if the plane is exactly the size of the CRTC. With the new test, the plane still has to cover all of the CRTC, but can be larger than the CRTC's size. A later patch can fully implement this feature in hibmc. If the plane is disabled, the helper clears the visibility flag in the plane state. On errors or if the plane is not visible, the atomic-check helper can return early. Implement all this in hibmc and drop the custom code that does some of it. v2: - extend the commit description (Yongbang) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: da52605eea8f ("drm/hisilicon/hibmc: Add support for display engine") Reviewed-by: Yongbang Shi <shiyongbang@huawei.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Xinliang Liu <xinliang.liu@linaro.org> Cc: Dmitry Baryshkov <lumag@kernel.org> Cc: Baihan Li <libaihan@huawei.com> Cc: Yongbang Shi <shiyongbang@huawei.com> Cc: <stable@vger.kernel.org> # v4.10+ Link: https://patch.msgid.link/20260618123142.92298-2-tzimmermann@suse.de
2026-06-24drm/i915/dp: Decode dsc max delta bpp from sink dpcdNemesa Garg1-2/+41
Add intel_dp_dsc_max_delta_bppx16() to parse sink dsc max delta bpp from dpcd when DP_DSC_MAX_BPP_DELTA_AVAILABILITY is set. This helper decodes the delta range for both RGB/YCbCr444 and YCbCr420 formats from DP_DSC_MAX_BPP_DELTA. With this addition, the flow becomes: 1. First, check for a format-specific range and use it to calculate max compressed bpp. 2. If not, check for sink supported max compressed bpp and use that 3. If this is also not there go with mandatory max range supported bpp. v2: Reorder the check flow for max_bpp. [Ankit] v3: Put RGB and YCbCr444 mask assignment in the same line. [Ankit] v4: Zero max_bpp for reserved RGB/YCbCr444 delta values. [sashiko] Signed-off-by: Nemesa Garg <nemesa.garg@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260623094236.1586318-5-nemesa.garg@intel.com
2026-06-24drm/nouveau/disp/r535: Add scanline position support + head state supportLyude Paul3-8/+6
That's right! It looks like this never actually got finished, something which I just noticed today when I saw this fun message spamming one of my test machine's kernel logs when enabling display debug output for nouveau: [drm:drm_crtc_vblank_helper_get_vblank_timestamp_internal] crtc 0 : scanoutpos query failed. So it looks like we've been falling back to DRM's core fallback for a while now, whoops. So, while it seems that we do have the option of doing this through GSP - that doesn't seem like a great idea. Mainly because reading this from GSP would involve a lot more latency then we should have for vblank handling due to the RPC communication. So instead of implementing that, just use gv100_head_state and gv100_head_rgpos for implementing .state and .rgpos. It seems to work perfectly fine! Fixes: 9e9944449023 ("drm/nouveau/disp/r535: initial support") Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Timur Tabi <ttabi@nvidia.com> Cc: Ben Skeggs <bskeggs@nvidia.com> Cc: James Jones <jajones@nvidia.com> Cc: Faith Ekstrand <faith.ekstrand@collabora.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Aaron Kling <webgeek1234@gmail.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Zhang Enpei <zhang.enpei@zte.com.cn> Cc: <stable@vger.kernel.org> # v6.7+ Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20260429030348.3930866-1-lyude@redhat.com
2026-06-23drm/xe/mmio: Prefer tile-based WARN messageMichal Wajdeczko1-3/+2
If 64-bit read operations are unstable, use tile-based WARN message to provide more details on which tile this was observed. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260622132342.19600-7-michal.wajdeczko@intel.com
2026-06-23drm/xe/mmio: Check MMIO BAR size when initializing tilesMichal Wajdeczko1-7/+21
We initialized all remote tiles' xe_mmio structures with a new size of 4MiB and offsets of 16MiB without sanity checks to see if mapped GTTMMADR_BAR was actually at least that size. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260622132342.19600-6-michal.wajdeczko@intel.com
2026-06-23drm/xe/mmio: Drop tiles_fini actionMichal Wajdeczko1-12/+1
The pointer zeroing is not required, as we check xe->mmio.regs to test if code is not trying to access MMIO after a driver unwind. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260622132342.19600-5-michal.wajdeczko@intel.com
2026-06-23drm/xe/mmio: Add check for minimal BAR sizeMichal Wajdeczko1-1/+6
We initialized the root tile's xe_mmio structure with a new size of 4MiB without sanity checks to see if mapped GTTMMADR_BAR was actually at least that size. Check BAR size against first 16MiB, which is expected minimum BAR size for the one-tile platforms. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260622132342.19600-4-michal.wajdeczko@intel.com
2026-06-23drm/xe/mmio: Map MMIO BAR using managed version of pci_iomapMichal Wajdeczko1-10/+14
This will allow us to simplify our custom release action where we will keep only zeroing of the xe->mmio.regs as we still rely on it all checks during all xe_mmio operations. While around, add missing kernel-doc for the function and update the error message. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260622132342.19600-3-michal.wajdeczko@intel.com
2026-06-23drm/xe/mmio: Verify MMIO is availableMichal Wajdeczko1-0/+21
We shouldn't access device registers after the device was unplugged or the MMIO bar (GTTMMADR) was unmapped. Instead of relying on the NPD splat due to zeroed tile->mmio.regs, which might be unreliable anyway as not all xe_mmio structs are using that directly, add an explicit check during all xe_mmio read/write operations to test if xe->mmio.regs are still mapped and safely abort with WARN if not. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260622132342.19600-2-michal.wajdeczko@intel.com
2026-06-23drm/i915/gem: Add missing nospec on parallel submit slotJoonas Lahtinen1-0/+1
Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: e5e32171a2cf ("drm/i915/guc: Connect UAPI to GuC multi-lrc interface") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Tvrtko Ursulin <tursulin@ursulin.net> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: <stable@vger.kernel.org> # v5.16+ Link: https://patch.msgid.link/20260622132539.165558-1-joonas.lahtinen@linux.intel.com (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-06-23drm/{i915, xe}/panic: drop dependency on struct intel_framebufferJani Nikula6-25/+33
Store tiling function pointer in struct intel_panic instead of struct intel_framebuffer, and store struct intel_panic pointer instead of struct intel_framebuffer pointer in struct drm_scanout_buffer private member. To make this happen, pass the tiling function pointer to panic setup hook, and initialize sb->private in the hook for clarity. This allows us to drop the dependency on struct intel_framebuffer from i915 and xe panic code. Note: It would be less verbose to have a typedef for the tiling function pointer. However, there isn't a nice location for it that wouldn't also increase header interdependencies. Cc: Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/d97abae79db3437c617cd4cb6193ba017b3a8d78.1780394867.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-23drm/xe/panic: store fb bo in struct intel_panicJani Nikula1-2/+5
Drop the dependency on intel_fb_bo() and intel_fb.h by storing the fb bo passed in the setup hook to struct intel_panic. Cc: Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/735c3f18212207db63d71364d6a8569480c81b42.1780394867.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-23drm/{i915,xe}/panic: pass obj to panic setupJani Nikula5-10/+11
Start reducing i915 and xe core dependency on struct intel_framebuffer by passing the fb obj from display. Cc: Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/840c4ccaced5f1c82277285938287776c8cdf513.1780394867.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-23drm/i915/panic: remove the extra layer from panic hooksJani Nikula1-23/+7
The extra layer in the panic hooks is useless. Remove it. Cc: Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/69a776c2951b3d1f81d8eb3870cbc7fda4d1c6e0.1780394867.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-23drm/i915/panic: squash i915_panic.c into i915_gem_panic.cJani Nikula6-59/+32
Having two small files for panic handling is a bit too much. Merge i915_panic.c into i915_gem_panic.c. This is just code movement, cleanups will follow. Cc: Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/4c294d6402e003040b934d94a0b14bd42704e21f.1780394867.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-23drm/i915/panic: split out i915_gem_panic.[ch]Jani Nikula6-136/+155
The panic handling is a bit special and isolated part of i915_gem_pages.c. Split it out to i915_gem_panic.[ch]. Cc: Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/f2093946e723aa27e856987d13692eb0308a4d85.1780394867.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-23drm/i915/gem: Add missing nospec on parallel submit slotJoonas Lahtinen1-0/+1
Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: e5e32171a2cf ("drm/i915/guc: Connect UAPI to GuC multi-lrc interface") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Tvrtko Ursulin <tursulin@ursulin.net> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: <stable@vger.kernel.org> # v5.16+ Link: https://patch.msgid.link/20260622132539.165558-1-joonas.lahtinen@linux.intel.com
2026-06-23gpu: nova-core: fb: Move PDISP register definitionAntonin Malzieu Ridolfi3-24/+27
Move PDISP register definition into fb module and update register visibility. Signed-off-by: Antonin Malzieu Ridolfi <dev@nanonej.com> Link: https://patch.msgid.link/20260617-nova-core-regs-split-v1-1-4c7dc4450ea7@nanonej.com [acourbot: fix rustfmt issue.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-23gpu: nova-core: gsp: Extract and display usable FB regions from GSPJoel Fernandes3-4/+67
Add usable_fb_regions() to GspStaticConfigInfo to extract the usable FB regions from GSP's fbRegionInfoParams. Usable regions are those that are not reserved or protected. The extracted regions are stored in GetGspStaticInfoReply and exposed for use by the memory subsystem. Display the regions and their total size upon device probe. [acourbot: expose all regions as a KVec, display usable regions and total usable VRAM.] Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260617-boot-vram-v3-3-20b9ec5fe9f2@nvidia.com [acourbot: replace dev_info!() with dev_dbg!().] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-22drm/xe/rtp: Ensure locking/ref counting for OA whitelistsAshutosh Dixit2-0/+12
Since multiple OA streams might be open in parallel on a gt, ensure that proper locking is in place. Also ensure that OA registers are whitelisted when the first OA stream is open and de-whitelisted after the last OA stream is closed. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260615224227.34880-10-ashutosh.dixit@intel.com
2026-06-22drm/xe/oa: (De-)whitelist OA registers on OA stream open/releaseAshutosh Dixit1-0/+7
Whitelist OA registers on stream open and de-whitelist on stream close/release. Whitelisting is only done when 'stream->sample' is true. 'stream->sample' is only true when (a) xe_observation_paranoid is set to false by system admin, or (b) the process is perfmon_capable(). This therefore enforces the OA register whitelisting security requirements. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260615224227.34880-9-ashutosh.dixit@intel.com
2026-06-22drm/xe/rtp: (De-)whitelist OA registers for all hwe's for a gtAshutosh Dixit2-1/+35
Whitelist or de-whitelist OA registers for all hwe's on the gt on which the OA stream is opened. This simplifies the case where an oa unit has 0 attached hwe's (but which monitors OA events on the associated GT). Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260615224227.34880-8-ashutosh.dixit@intel.com
2026-06-22drm/xe/rtp: Toggle 'deny' bit to (de-)whitelist OA regsAshutosh Dixit1-0/+15
Whitelist or de-whitelist OA registers by setting or resetting the 'deny' bit in OA nonpriv registers and writing new register values to HW. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260615224227.34880-7-ashutosh.dixit@intel.com
2026-06-22drm/xe/rtp: Save OA nonpriv registers to register save/restore listsAshutosh Dixit1-0/+12
Now we can save OA whitelisting nonpriv registers to register save/restore lists. OA nonpriv registers are saved to both hwe->oa_sr as well as hwe->reg_sr. During probe, resume and gt-reset flows KMD will apply hwe->reg_sr, ensuring OA registers are de-whitelisted after these events. For engine-reset, hwe->reg_sr is registered with GuC and GuC will apply these registers, ensuring OA registers are de-whitelisted after engine resets. hwe->oa_sr is used for whitelisting or de-whitelisting OA registers during OA operation, by toggling the 'deny' bit on oa stream open/close. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260615224227.34880-6-ashutosh.dixit@intel.com
2026-06-22drm/xe/rtp: Generalize whitelist_apply_to_hweAshutosh Dixit1-5/+6
Generalize whitelist_apply_to_hwe to construct both non-OA and OA whitelist nonpriv registers. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260615224227.34880-5-ashutosh.dixit@intel.com
2026-06-22drm/xe/rtp: Keep track of non-OA nonpriv slotsAshutosh Dixit1-2/+5
In order to dynamically whitelist/dewhitelist OA registers on OA stream open/close, we need to keep track of nonpriv slots occupied by non-OA register whitelists. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260615224227.34880-4-ashutosh.dixit@intel.com
2026-06-22drm/xe/rtp: Maintain OA whitelists separatelyAshutosh Dixit4-1/+18
OA registers are dynamically whitelisted (and again dewhitelisted) on OA stream open/close. Maintaining OA whitelists separately from non-OA register whitlists simplifies this management of OA register whitelisting/dewhitelisting. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260615224227.34880-3-ashutosh.dixit@intel.com
2026-06-22drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelistsAshutosh Dixit1-3/+5
Unconditionally whitelisting OA registers is a security violation. Set RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers don't get whitelisted by default after probe, gt reset, resume and engine reset. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Suggested-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260615224227.34880-2-ashutosh.dixit@intel.com
2026-06-22drm/bridge: Remove atomic_reset supportMaxime Ripard2-9/+4
There are no remaining users of the atomic_reset hook. Remove it from the core. Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-78-ff399263111b@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
generated by cgit (git 2.54.0.dirty) at 2026-09-26 22:46:58 +0000