summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2025-10-11drm/bridge: lt9211: Drop check for last nibble of version registerMarek Vasut
There is now a new LT9211 rev. U5, which reports chip ID 0x18 0x01 0xe4 . The previous LT9211 reported chip ID 0x18 0x01 0xe3 , which is what the driver checks for right now. Since there is a possibility there will be yet another revision of the LT9211 in the future, drop the last version nibble check to allow all future revisions of the chip to work with this driver. This fix makes LT9211 rev. U5 work with this driver. Fixes: 8ce4129e3de4 ("drm/bridge: lt9211: Add Lontium LT9211 bridge driver") Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251011110017.12521-1-marek.vasut@mailbox.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-10-11drm/i915/cdclk: Move intel_cdclk_atomic_check()Ville Syrjälä
Move intel_cdclk_atomic_check() a bit so that we don't need an extra intel_modeset_calc_cdclk() forward declaration. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-21-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/i915/cdclk: Hide intel_modeset_calc_cdclk()Ville Syrjälä
We no longer have anything of importance between intel_cdclk_atomic_check() and intel_modeset_calc_cdclk(), so hide the latter inside the former. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-20-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/i915/cdclk: Use enabled_pipes instead of active_pipes for the glk audio w/aVille Syrjälä
Currently we are considering the set of active pipes when determining if we need to boost the cdclk due to glk audio issues. Replace that with the set of logically enabled pipes instead. That is generally how everything else cdclk related is computed (cdclk_state->logical is based on logically enabled pipes). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-19-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/i915: Introduce intel_calc_enabled_pipes()Ville Syrjälä
Add intel_calc_enabled_pipes() as the counterpart to intel_calc_active_pipes(). We have some uses where the set of logically enabled pipes makes more sense than the set of active pipes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-18-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/i915/cdclk: Decouple cdclk from state->modesetVille Syrjälä
There's no real reason anymore to tie cdclk updates to state->modeset/any_ms. Always call the cdclk functions and allow them to decide whether cdclk update is necessary/desired or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-17-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/i915/cdclk: Move intel_bw_crtc_min_cdclk() handling into ↵Ville Syrjälä
intel_crtc_compute_min_cdclk() intel_bw_crtc_min_cdclk() depends only on per-crtc state, so there is no real point in having it complicate the global bw_min_cdclk. Instead let's just account for it in intel_crtc_compute_min_cdclk(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-16-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/i915/cdclk: Rework crtc min_cdclk handlingVille Syrjälä
Update crtc min_cdclk directly from when calling intel_cdclk_update_crtc_min_cdclk() rather than doing it later from intel_compute_min_cdclk(). This will eg. allow better control over when to update the cdclk. For now we preserve the current behaviour by allowing the cdclk to decrease when any pipe needs to do a full modeset. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-15-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/i915/cdclk: Relocate intel_plane_calc_min_cdclk() callsVille Syrjälä
There's no reason to defer intel_plane_calc_min_cdclk() until intel_cdclk_atomic_check(). Just do this as part of intel_atomic_check_planes() (after we've added all the planes to the state that affect the per-plane min_cdclk calculation). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-14-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/i915/cdclk: Do intel_cdclk_update_crtc_min_cdclk() per-pipeVille Syrjälä
Currently we call intel_cdclk_update_crtc_min_cdclk() per-plane. That is rather wasteful, and also won't account for any of the other per-pipe min_cdclk restrictions from intel_crtc_compute_min_cdclk(). Change the behaviour to do do the comparison per-crtc instead, and use the final min cdclk as computed by intel_crtc_compute_min_cdclk(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-13-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/i915/cdclk: Rework bw_min_cdclk handlingVille Syrjälä
Update bw_min_cdclk directly from intel_bw_calc_min_cdclk() rather than doing it later from intel_compute_min_cdclk(). This will allow better control over when to update the cdclk. For now we preserve the current behaviour by allowing the cdclk to decrease when any pipe needs to do a full modeset. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-12-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/i915/cdclk: Extract intel_cdclk_update_crtc_min_cdclk()Ville Syrjälä
Hide the cdclk state details better by providing a helper (intel_cdclk_update_crtc_min_cdclk()) by which the crtc code can inform the cdclk code about a new per-pipe min_cdclk value. Note that this is currently being called once per-plane, but it'll be changed to be just a single call for the whole pipe later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-11-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/i915/cdclk: Extract intel_cdclk_update_bw_min_cdclk()Ville Syrjälä
Hide the cdclk state details better by providing a helper (intel_cdclk_update_bw_min_cdclk()) by which the bw code can inform the cdclk code about a new bw_min_cdclk value. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-10-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/i915/cdclk: Handle the force_min_cdclk state locking in ↵Ville Syrjälä
intel_cdclk_atomic_check() Clean up the mess inside intel_modeset_calc_cdclk() a bit by moving the intel_atomic_lock_global_state() for force_min_cdclk changes into intel_cdclk_atomic_check(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-9-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/i915/cdclk: Introduce intel_cdclk_modeset_checks()Ville Syrjälä
I plan to better decouple the cdclk computation from actual modesets. To that end make the cdclk code self sufficient in being able to determine if a full cdclk calculation/update is needed or not due to some not strictly cdclk related reason. Currently we have three such things that depend active_pipes: - cdclk_state->actual - glk audio w/a - dg2 power well stuff Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-8-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/i915/cdclk: Extract dg2_power_well_count()Ville Syrjälä
Extract the code to determine the DG2 pipe power well count into a small helper. I'll have other uses for this later. TODO: need to move this power well stuff out from the cdclk code... v2: Don't lose the early return from intel_cdclk_pcode_pre_notify() (kernel test robot) v3: Compare old vs. new, not old vs. old (Jani) Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250926083950.24486-1-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/i915/cdclk: Extract glk_cdclk_audio_wa_needed()Ville Syrjälä
Extract the glk audio w/a check into a small helper. We'll have other uses for this later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-6-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/1915/bw: Drop redundant display version checksVille Syrjälä
intel_bw_modeset_checks() is now only called from intel_bw_atomic_check() which alrady does the display version check. Drop the redundant check from intel_bw_modeset_checks(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-5-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/i915/bw: Skip the bw_state->active_pipes update if no pipe is changing ↵Ville Syrjälä
its active state Currently we may end up doing a bunch of redundant bw_state recomputation whenever any modeset happens. Skip a bunch of that by only considering whether any pipe actually changes its active state. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-4-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/i915: Introduce intel_crtc_active_changed() and ↵Ville Syrjälä
intel_any_crtc_active_changed() Introduce helpers that determine whether any crtc is changing its active state. Will be useful for cdclk stuff. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-3-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-11drm/i915: Introduce intel_crtc_enable_changed() and ↵Ville Syrjälä
intel_any_crtc_enable_changed() Introduce helpers that determine whether any crtc is changing its enabled state. Will be useful for cdclk stuff. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-2-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2025-10-10Merge tag 'drm-next-2025-10-11-1' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull more drm fixes from Dave Airlie: "Just the follow up fixes for rc1 from the next branch, amdgpu and xe mostly with a single v3d fix in there. amdgpu: - DC DCE6 fixes - GPU reset fixes - Secure diplay messaging cleanup - MES fix - GPUVM locking fixes - PMFW messaging cleanup - PCI US/DS switch handling fix - VCN queue reset fix - DC FPU handling fix - DCN 3.5 fix - DC mirroring fix amdkfd: - Fix kfd process ref leak - mmap write lock handling fix - Fix comments in IOCTL xe: - Fix build with clang 16 - Fix handling of invalid configfs syntax usage and spell out the expected syntax in the documentation - Do not try late bind firmware when running as VF since it shouldn't handle firmware loading - Fix idle assertion for local BOs - Fix uninitialized variable for late binding - Do not require perfmon_capable to expose free memory at page granularity. Handle it like other drm drivers do - Fix lock handling on suspend error path - Fix I2C controller resume after S3 v3d: - fix fence locking" * tag 'drm-next-2025-10-11-1' of https://gitlab.freedesktop.org/drm/kernel: (34 commits) drm/amd/display: Incorrect Mirror Cositing drm/amd/display: Enable Dynamic DTBCLK Switch drm/amdgpu: Report individual reset error drm/amdgpu: partially revert "revert to old status lock handling v3" drm/amd/display: Fix unsafe uses of kernel mode FPU drm/amd/pm: Disable VCN queue reset on SMU v13.0.6 due to regression drm/amdgpu: Fix general protection fault in amdgpu_vm_bo_reset_state_machine drm/amdgpu: Check swus/ds for switch state save drm/amdkfd: Fix two comments in kfd_ioctl.h drm/amd/pm: Avoid interface mismatch messaging drm/amdgpu: Merge amdgpu_vm_set_pasid into amdgpu_vm_init drm/amd/amdgpu: Fix the mes version that support inv_tlbs drm/amd: Check whether secure display TA loaded successfully drm/amdkfd: Fix mmap write lock not release drm/amdkfd: Fix kfd process ref leaking when userptr unmapping drm/amdgpu: Fix for GPU reset being blocked by KIQ I/O. drm/amd/display: Disable scaling on DCE6 for now drm/amd/display: Properly disable scaling on DCE6 drm/amd/display: Properly clear SCL_*_FILTER_CONTROL on DCE6 drm/amd/display: Add missing DCE6 SCL_HORZ_FILTER_INIT* SRIs ...
2025-10-10Merge tag 'drm-fixes-2025-10-11' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Some fixes leftover from our fixes branch, just nouveau and vmwgfx: nouveau: - Return errno code from TTM move helper vmwgfx: - Fix null-ptr access in cursor code - Fix UAF in validation - Use correct iterator in validation" * tag 'drm-fixes-2025-10-11' of https://gitlab.freedesktop.org/drm/kernel: drm/nouveau: fix bad ret code in nouveau_bo_move_prep drm/vmwgfx: Fix copy-paste typo in validation drm/vmwgfx: Fix Use-after-free in validation drm/vmwgfx: Fix a null-ptr access in the cursor snooper
2025-10-11Merge tag 'drm-misc-fixes-2025-10-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: nouveau: - Return errno code from TTM move helper vmwgfx: - Fix null-ptr access in cursor code - Fix UAF in validation - Use correct iterator in validation Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20251009120004.GA17570@linux.fritz.box
2025-10-10drm/xe: Change return type of detect_bar2_dgfx() from s64 to u64Shuicheng Lin
The function never returns a negative value, and the return value is assigned to a u64 variable. Use u64 for better type correctness and clarity. v2: add assert to catch theoretical negative or zero stolen size. (Rodrigo) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://lore.kernel.org/r/20251009230239.2830207-8-shuicheng.lin@intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-10-10drm/xe: Fix copyright in xe_ttm_stolen_mgrShuicheng Lin
- Correct Red Hat copyright year from "2002" to "2022". - Sort the include lines alphabetically. No functional changes intended. Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://lore.kernel.org/r/20251009230239.2830207-7-shuicheng.lin@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-10-10drm/xe: Fix copyright and function naming in xe_ttm_sys_mgrShuicheng Lin
- Correct Red Hat copyright year from "2002" to "2022". - Rename ttm_sys_mgr_fini() to xe_ttm_sys_mgr_fini() to avoid confusion with generic TTM helpers. No functional changes intended. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://lore.kernel.org/r/20251009230239.2830207-6-shuicheng.lin@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-10-10drm/xe: Enable media sampler power gatingVinay Belgaumkar
Where applicable, enable media sampler power gating. Also, add it to the powergate_info debugfs. v2: Remove the sampler powergate status since it is cleared quickly anyway. v3: Use vcs mask (Rodrigo) and fix the version check for media v4: Remove extra spaces v5: Media samplers are independent of vcs mask, use Media version 1255 (Matt Roper) Fixes: 38e8c4184ea0 ("drm/xe: Enable Coarse Power Gating") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://lore.kernel.org/r/20251010011047.2047584-1-vinay.belgaumkar@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-10-10drm/xe: Handle mixed mappings and existing VRAM on atomic faultsMatthew Brost
Moving to VRAM will fail if mixed mappings are present or if the page is already located in VRAM. Atomic faults that require a move to VRAM currently retry without attempting to evict mixed mappings or locate existing VRAM mappings. This patch fixes the issue by attempting to evict mixed mappings or find existing VRAM pages when a move to VRAM fails during atomic fault handling. Fixes: a9ac0fa455b0 ("drm/xe: Strict migration policy for atomic SVM faults") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://lore.kernel.org/r/20251009130629.3531962-1-matthew.brost@intel.com
2025-10-10drm/xe/migrate: Fix an error pathThomas Hellström
The exhaustive eviction accidently changed an error path goto to a return. Fix this. Fixes: 59eabff2a352 ("drm/xe: Convert xe_bo_create_pin_map() for exhaustive eviction") Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://lore.kernel.org/r/20250910160939.103473-1-thomas.hellstrom@linux.intel.com
2025-10-10drm/gud: Use kmalloc_array() instead of kmalloc()Mehdi Ben Hadj Khelifa
Replace kmalloc with kmalloc array in drm/gud/gud_pipe.c since the calculation inside kmalloc is dynamic 'width * height' Signed-off-by: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com> Acked-by: Ruben Wauters <rubenru09@aol.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20251007083320.29018-1-mehdi.benhadjkhelifa@gmail.com
2025-10-09drm/xe: Move rebar to be done earlierLucas De Marchi
There may be cases in which the BAR0 also needs to move to accommodate the bigger BAR2. However if it's not released, the BAR2 resize fails. During the vram probe it can't be released as it's already in use by xe_mmio for early register access. Add a new function in xe_vram and let xe_pci call it directly before even early device probe. This allows the BAR2 to resize in cases BAR0 also needs to move, assuming there aren't other reasons to hold that move: [] xe 0000:03:00.0: vgaarb: deactivate vga console [] xe 0000:03:00.0: [drm] Attempting to resize bar from 8192MiB -> 16384MiB [] xe 0000:03:00.0: BAR 0 [mem 0x83000000-0x83ffffff 64bit]: releasing [] xe 0000:03:00.0: BAR 2 [mem 0x4000000000-0x41ffffffff 64bit pref]: releasing [] pcieport 0000:02:01.0: bridge window [mem 0x4000000000-0x41ffffffff 64bit pref]: releasing [] pcieport 0000:01:00.0: bridge window [mem 0x4000000000-0x41ffffffff 64bit pref]: releasing [] pcieport 0000:01:00.0: bridge window [mem 0x4000000000-0x43ffffffff 64bit pref]: assigned [] pcieport 0000:02:01.0: bridge window [mem 0x4000000000-0x43ffffffff 64bit pref]: assigned [] xe 0000:03:00.0: BAR 2 [mem 0x4000000000-0x43ffffffff 64bit pref]: assigned [] xe 0000:03:00.0: BAR 0 [mem 0x83000000-0x83ffffff 64bit]: assigned [] pcieport 0000:00:01.0: PCI bridge to [bus 01-04] [] pcieport 0000:00:01.0: bridge window [mem 0x83000000-0x840fffff] [] pcieport 0000:00:01.0: bridge window [mem 0x4000000000-0x44007fffff 64bit pref] [] pcieport 0000:01:00.0: PCI bridge to [bus 02-04] [] pcieport 0000:01:00.0: bridge window [mem 0x83000000-0x840fffff] [] pcieport 0000:01:00.0: bridge window [mem 0x4000000000-0x43ffffffff 64bit pref] [] pcieport 0000:02:01.0: PCI bridge to [bus 03] [] pcieport 0000:02:01.0: bridge window [mem 0x83000000-0x83ffffff] [] pcieport 0000:02:01.0: bridge window [mem 0x4000000000-0x43ffffffff 64bit pref] [] xe 0000:03:00.0: [drm] BAR2 resized to 16384M [] xe 0000:03:00.0: [drm:xe_pci_probe [xe]] BATTLEMAGE e221:0000 dgfx:1 gfx:Xe2_HPG (20.02) ... For BMG there are additional fix needed in the PCI side, but this helps getting it to a working resize. All the rebar logic is more pci-specific than xe-specific and can be done very early in the probe sequence. In future it would be good to move it out of xe_vram.c, but this refactor is left for later. Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Cc: stable@vger.kernel.org # 6.12+ Link: https://lore.kernel.org/intel-xe/fafda2a3-fc63-ce97-d22b-803f771a4d19@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20250918-xe-pci-rebar-2-v1-2-6c094702a074@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-10Merge tag 'amd-drm-next-6.18-2025-10-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.18-2025-10-09: amdgpu: - DC DCE6 fixes - GPU reset fixes - Secure diplay messaging cleanup - MES fix - GPUVM locking fixes - PMFW messaging cleanup - PCI US/DS switch handling fix - VCN queue reset fix - DC FPU handling fix - DCN 3.5 fix - DC mirroring fix amdkfd: - Fix kfd process ref leak - mmap write lock handling fix - Fix comments in IOCTL Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20251009162915.981503-1-alexander.deucher@amd.com
2025-10-09drm/xe: Don't allow evicting of BOs in same VM in array of VM bindsMatthew Brost
An array of VM binds can potentially evict other buffer objects (BOs) within the same VM under certain conditions, which may lead to NULL pointer dereferences later in the bind pipeline. To prevent this, clear the allow_res_evict flag in the xe_bo_validate call. v2: - Invert polarity of no_res_evict (Thomas) - Add comment in code explaining issue (Thomas) Cc: stable@vger.kernel.org Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6268 Fixes: 774b5fa509a9 ("drm/xe: Avoid evicting object of the same vm in none fault mode") Fixes: 77f2ef3f16f5 ("drm/xe: Lock all gpuva ops during VM bind IOCTL") Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://lore.kernel.org/r/20251009110618.3481870-1-matthew.brost@intel.com
2025-10-09drm/i915/wm: Use fb->modfier to check for tiled vs. untiledVille Syrjälä
There is no point in checking the bo fence tiling mode when we can just check the fb modifier instead. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251003145734.7634-6-ville.syrjala@linux.intel.com
2025-10-09drm/i915/fb: Drop the 'fb' argument from intel_fb_bo_framebuffer_init()Ville Syrjälä
intel_fb_bo_framebuffer_init() doesn't do anything with the passed framebuffer. Don't pass it therefore. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251003145734.7634-5-ville.syrjala@linux.intel.com
2025-10-09drm/i915/fbdev: Select linear modifier explicitlyVille Syrjälä
Currently we use the implicit modifier fb creation path for fbdev, but as we never call set_tiling on the bo it will always end up as linear anyway. The rest of the code (eg. stride alignment) also assumes that we'll use linear. Just select the linear modifier explicitly. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251003145734.7634-4-ville.syrjala@linux.intel.com
2025-10-09drm/i915/fb: Fix the set_tiling vs. addfb race, againVille Syrjälä
intel_frontbuffer_get() is what locks out subsequent set_tiling changes to the bo. Thus the fence vs. modifier check must be done after intel_frontbuffer_get(), or else a concurrent set_tiling ioctl might sneak in and change the fence after the check has been done. Close the race again. See commit dd689287b977 ("drm/i915: Prevent concurrent tiling/framebuffer modifications") for the previous instance. v2: Reorder intel_user_framebuffer_destroy() to match the unwind (Jani) Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Fixes: 10690b8a49bc ("drm/i915/display: Add intel_fb_bo_framebuffer_fini") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251003145734.7634-3-ville.syrjala@linux.intel.com
2025-10-09drm/i915/frontbuffer: Move bo refcounting intel_frontbuffer_{get,release}()Ville Syrjälä
Currently xe's intel_frontbuffer implementation forgets to hold a reference on the bo. This makes the entire thing extremely fragile as the cleanup order now depends on bo references held by other things (namely intel_fb_bo_framebuffer_fini()). Move the bo refcounting to intel_frontbuffer_{get,release}() so that both i915 and xe do this the same way. I first tried to fix this by having xe do the refcounting from its intel_bo_set_frontbuffer() implementation (which is what i915 does currently), but turns out xe's drm_gem_object_free() can sleep and thus drm_gem_object_put() isn't safe to call while we hold fb_tracking.lock. Fixes: 10690b8a49bc ("drm/i915/display: Add intel_fb_bo_framebuffer_fini") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251003145734.7634-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-10-09drm/panfrost: Name scheduler queues after their job slotsAdrián Larumbe
Drawing from commit d2624d90a0b7 ("drm/panthor: assign unique names to queues"), give scheduler queues proper names that reflect the function of their JM slot, so that this will be shown when gathering DRM scheduler tracepoints. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20251009114313.1374948-1-adrian.larumbe@collabora.com
2025-10-09drm/xe: Increase global invalidation timeout to 1000usKenneth Graunke
The previous timeout of 500us seems to be too small; panning the map in the Roll20 VTT in Firefox on a KDE/Wayland desktop reliably triggered timeouts within a few seconds of usage, causing the monitor to freeze and the following to be printed to dmesg: [Jul30 13:44] xe 0000:03:00.0: [drm] *ERROR* GT0: Global invalidation timeout [Jul30 13:48] xe 0000:03:00.0: [drm] *ERROR* [CRTC:82:pipe A] flip_done timed out I haven't hit a single timeout since increasing it to 1000us even after several multi-hour testing sessions. Fixes: 0dd2dd0182bc ("drm/xe: Move DSB l2 flush to a more sensible place") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5710 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Cc: stable@vger.kernel.org Cc: Maarten Lankhorst <dev@lankhorst.se> Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://lore.kernel.org/r/20250912223254.147940-1-kenneth@whitecape.org Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-09drm: Prevent sign extension on hdisplay and vdisplayJonathan Cavitt
Some functions in drm multiply hdisplay and vdisplay with a third factor, which can result in a sign extension according to static analysis due to an implicit s32 promotion. Use a cast to u32 to prevent this. Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Krzystof Karas <krzysztof.karas@intel.com> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Link: https://lore.kernel.org/r/20251007153645.90920-2-jonathan.cavitt@intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-10-09drm/i915/display: Make intel_crtc_get_vblank_counter safe on PREEMPT_RTMaarten Lankhorst
drm_crtc_accurate_vblank_count takes a spinlock, which we should avoid in tracepoints and debug functions. This also prevents taking the spinlock 2x during the critical section of pipe updates for DSI updates. Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250829131701.15607-2-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-10-09drm/i915: Disable tracepoints for PREEMPT_RTMaarten Lankhorst
Luca Abeni reported this: | BUG: scheduling while atomic: kworker/u8:2/15203/0x00000003 | CPU: 1 PID: 15203 Comm: kworker/u8:2 Not tainted 4.19.1-rt3 #10 | Call Trace: | rt_spin_lock+0x3f/0x50 | gen6_read32+0x45/0x1d0 [i915] | g4x_get_vblank_counter+0x36/0x40 [i915] | trace_event_raw_event_i915_pipe_update_start+0x7d/0xf0 [i915] The tracing events use trace_intel_pipe_update_start() among other events use functions acquire spinlock_t locks which are transformed into sleeping locks on PREEMPT_RT. A few trace points use intel_get_crtc_scanline(), others use ->get_vblank_counter() wich also might acquire a sleeping locks on PREEMPT_RT. At the time the arguments are evaluated within trace point, preemption is disabled and so the locks must not be acquired on PREEMPT_RT. Based on this I don't see any other way than disable trace points on PREMPT_RT. [mlankhorst] The original patch was insufficient, and since the tracing infrastructure does not allow for partial disabling of tracepoints. Completely disable tracing for the entire i915 driver in PREEMPT_RT, a separate fix for display tracepoints on xe is added to make those work. Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reported-by: Luca Abeni <lucabe72@gmail.com> Cc: Steven Rostedt <rostedt@goodmis.org> Co-developed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250828090944.101069-1-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-10-09drm/panthor: skip regulator setup if no such propRain Yang
The regulator is optional, skip the setup instead of returning an error if it is not present Signed-off-by: Rain Yang <jiyu.yang@nxp.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250928090334.35389-2-jiyu.yang@oss.nxp.com
2025-10-09drm/panthor: Ensure MCU is disabled on suspendKetil Johnsen
Currently the Panthor driver needs the GPU to be powered down between suspend and resume. If this is not done, then the MCU_CONTROL register will be preserved as AUTO, which again will cause a premature FW boot on resume. The FW will go directly into fatal state in this case. This case needs to be handled as there is no guarantee that the GPU will be powered down after the suspend callback on all platforms. The fix is to call panthor_fw_stop() in "pre-reset" path to ensure the MCU_CONTROL register is cleared (set DISABLE). This matches well with the already existing call to panthor_fw_start() from the "post-reset" path. Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com> Acked-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20251008105112.4077015-1-ketil.johnsen@arm.com
2025-10-09drm/xe/guc: Increase wait timeout to 2sec after BUSY reply from GuCSatyanarayana K V P
Some VF2GUC actions may take longer to process. Increase default timeout after received BUSY indication to 2sec to cover all worst case scenarios. Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251008214532.3442967-35-matthew.brost@intel.com
2025-10-09drm/xe/vf: Rebase CCS save/restore BB GGTT addressesMatthew Brost
Rebase the CCS save/restore BB's GGTT addresses during VF post-migration recovery by setting the software ring tail to zero, the LRC ring head to zero, and rewriting the jump-to-BB instructions. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Link: https://lore.kernel.org/r/20251008214532.3442967-34-matthew.brost@intel.com
2025-10-09drm/xe/vf: Ensure media GT VF recovery runs after primary GT on PTLMatthew Brost
It is possible that the media GT's VF post-migration recovery work item gets scheduled before the primary GT's work item. Since the media GT depends on the primary GT's work item to complete CCS restore, if the media GT's work item is scheduled first, detect this condition and re-queue the media GT's work item for a later time. v5: - Adjust debug message (Tomasz) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Tomasz Lis <tomasz.lis@intel.com> Link: https://lore.kernel.org/r/20251008214532.3442967-33-matthew.brost@intel.com
2025-10-09drm/xe/vf: Use primary GT ordered work queue on media GT on PTL VFMatthew Brost
VF CCS restore is a primary GT operation on which the media GT depends. Therefore, it doesn't make much sense to run these operations in parallel. To address this, point the media GT's ordered work queue to the primary GT's ordered work queue on platforms that require (PTL VFs) CCS restore as part of VF post-migration recovery. v7: - Remove bool from xe_gt_alloc (Lucas) v9: - Fix typo (Lucas) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251008214532.3442967-32-matthew.brost@intel.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-15 15:16:12 +0000