summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
2025-11-10drm/xe/vram: Move forcewake down to get_flat_ccs_offset()Lucas De Marchi
With SG_TILE_ADDR_RANGE use, the only thing requiring GT forcewake while probing for vram size is the get_flat_ccs_offset(). Move the forcewake down where it's needed. Suggested-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20251107-tile-addr-v1-2-a3014aadc2e7@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-10drm/xe: Use SG_TILE_ADDR_RANGE instead of TILE_ADDR_RANGEFei Yang
The TILE_ADDR_RANGE register is not available on all platforms going forward as it was deprecated and is being replaced by equivalent registers within SoC MMIO space. While that doesn't happen, the SG_TILE_ADDR_RANGE (base 0x1083a0) is still valid for all platforms supported by xe. Use that instead. BSpec: 59353, 54991 Signed-off-by: Fei Yang <fei.yang@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/20251107-tile-addr-v1-1-a3014aadc2e7@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-10drm/i915/dp_mst: Disable Panel ReplayImre Deak
Disable Panel Replay on MST links until it's properly implemented. For instance the required VSC SDP is not programmed on MST and FEC is not enabled if Panel Replay is enabled. Fixes: 3257e55d3ea7 ("drm/i915/panelreplay: enable/disable panel replay") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15174 Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: stable@vger.kernel.org # v6.8+ Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251107124141.911895-1-imre.deak@intel.com
2025-11-10drm/i915/psr: fix pipe to vblank conversionJani Nikula
First, we can't assume pipe == crtc index. If a pipe is fused off in between, it no longer holds. intel_crtc_for_pipe() is the only proper way to get from a pipe to the corresponding crtc. Second, drivers aren't supposed to access or index drm->vblank[] directly. There's drm_crtc_vblank_crtc() for this. Use both functions to fix the pipe to vblank conversion. Fixes: f02658c46cf7 ("drm/i915/psr: Add mechanism to notify PSR of pipe enable/disable") Cc: Jouni Högander <jouni.hogander@intel.com> Cc: stable@vger.kernel.org # v6.16+ Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20251106200000.1455164-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 2750f6765d6974f7e163c5d540a96c8703f6d8dd) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-11-10drm/panthor: Fix potential memleak of vma structureAkash Goel
This commit addresses a memleak issue of panthor_vma (or drm_gpuva) structure in Panthor driver, that can happen if the GPU page table update operation to map the pages fail. The issue is very unlikely to occur in practice. v2: Add panthor_vm_op_ctx_return_vma() helper (Boris) v3: Add WARN_ON_ONCE (Boris) Fixes: 647810ec2476 ("drm/panthor: Add the MMU/VM logical block") Signed-off-by: Akash Goel <akash.goel@arm.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://patch.msgid.link/20251021081042.1377406-1-akash.goel@arm.com
2025-11-10drm/xe: Fix MTL vm_max_levelRodrigo Vivi
MTL was broken after the vm_max_level movement. Get it back to a working value. [ 37.722413] xe 0000:00:02.0: [drm] Tile0: GT0: VM job timed out on non-killed execqueue [ 37.722465] WARNING: CPU: 0 PID: 12 at drivers/gpu/drm/xe/xe_guc_submit.c:1379 guc_exec_queue_timedout_job+0x2f3/0xe00 [xe] [ 37.722559] Modules linked in: xt_REDIRECT nft_compat nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr sunrpc bnep snd_ctl_led snd_soc_s\ of_sdw snd_soc_intel_hda_dsp_common snd_soc_sdw_utils snd_sof_probes snd_soc_rt712_sdca regmap_sdw_mbq snd_hda_codec_intelhdmi regmap_sdw snd_soc_dmic snd_hda_intel snd_sof_pci_intel_mtl iwlmvm snd_sof_intel_hda_generic soundwire_intel snd_sof_intel_hda_sdw_bpt snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_intel_hda_mlink\ snd_sof_intel_hda snd_hda_codec_hdmi soundwire_cadence snd_sof_pci snd_sof_xtensa_dsp binfmt_misc snd_sof mac80211 vfat snd_sof_utils fat snd_hda_ext_core snd_hda_codec snd_hda_core snd_intel_dspcfg snd_intel_sdw_acpi snd_soc_acpi_intel_match snd_soc_acpi_intel_sdca_quirks soundwire_generic_allocation snd_soc_acpi snd_hwdep \ crc8 soundwire_bus libarc4 snd_soc_sdca snd_soc_core [ 37.722584] snd_compress ac97_bus uvcvideo snd_pcm_dmaengine iwlwifi snd_seq uvc videobuf2_vmalloc snd_seq_device videobuf2_memops videobuf2_v4l2 snd_pcm processor_thermal_device_pci videobuf2_common processor_thermal_device btusb intel_uncore_frequency processor_thermal_wt_hint intel_uncore_frequency_common platform_temp\ erature_control videodev btmtk spi_nor processor_thermal_soc_slider x86_pkg_temp_thermal btrtl snd_timer iTCO_wdt processor_thermal_rfim intel_powerclamp btbcm intel_pmc_bxt snd intel_rapl_msr processor_thermal_rapl coretemp iTCO_vendor_support mei_gsc_proxy btintel intel_rapl_common rapl intel_cstate cfg80211 bluetooth mc in\ tel_pmc_core mtd soundcore acer_wmi mei_me intel_uncore processor_thermal_wt_req i2c_i801 spi_intel_pci pmt_telemetry platform_profile mei processor_thermal_power_floor spi_intel i2c_smbus pmt_discovery igen6_edac pcspkr rfkill wmi_bmof idma64 processor_thermal_mbox intel_hid pmt_class int3403_thermal int3400_thermal joydev i\ nt340x_thermal_zone acpi_pad sparse_keymap [ 37.722611] intel_pmc_ssram_telemetry acpi_thermal_rel acer_wireless loop nfnetlink zram lz4hc_compress lz4_compress dm_crypt xe drm_ttm_helper drm_suballoc_helper gpu_sched drm_gpuvm drm_exec drm_gpusvm_helper i915 nvme i2c_algo_bit nvme_core drm_buddy ucsi_acpi ttm typec_ucsi typec nvme_keyring nvme_auth hkdf drm_displa\ y_helper hid_multitouch polyval_clmulni thunderbolt intel_vpu ghash_clmulni_intel cec vmd i2c_hid_acpi video intel_vsec i2c_hid wmi pinctrl_meteorlake serio_raw i2c_dev fuse [ 37.722638] CPU: 0 UID: 0 PID: 12 Comm: kworker/u88:0 Not tainted 6.18.0-rc2+ #37 PREEMPT(voluntary) [ 37.722641] Hardware name: Acer Swift SFG14-72/Coral_MTH, BIOS V1.01 11/06/2023 [ 37.722643] Workqueue: gt-ordered-wq drm_sched_job_timedout [gpu_sched] [ 37.722649] RIP: 0010:guc_exec_queue_timedout_job+0x2f3/0xe00 [xe] [ 37.722722] Code: 4c 24 10 44 89 44 24 08 e8 5a 95 f1 d4 44 8b 44 24 08 8b 4c 24 10 48 c7 c7 00 b7 25 c1 48 8b 54 24 18 48 89 c6 e8 4d 59 37 d4 <0f> 0b 80 3c 24 00 0f 85 55 03 00 00 49 8b 47 58 a8 01 75 1a 49 8b [ 37.722723] RSP: 0018:ffffd468000f7d80 EFLAGS: 00010246 [ 37.722725] RAX: 0000000000000000 RBX: ffff8e3d4e215c00 RCX: 0000000000000027 [ 37.722726] RDX: ffff8e40ae61cfc8 RSI: 0000000000000001 RDI: ffff8e40ae61cfc0 [ 37.722727] RBP: 00000000fffffffb R08: 0000000000000000 R09: ffffd468000f7c20 [ 37.722727] R10: ffff8e40c09fffa8 R11: 00000000fffbffff R12: ffff8e3d44c00028 [ 37.722728] R13: ffff8e3d807d4000 R14: ffff8e3d807d4018 R15: ffff8e3d95c9d600 [ 37.722729] FS: 0000000000000000(0000) GS:ffff8e4116110000(0000) knlGS:0000000000000000 [ 37.722729] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.722730] CR2: 00007ff1f3e02720 CR3: 0000000113c8d005 CR4: 0000000000f70ef0 [ 37.722731] PKRU: 55555554 [ 37.722731] Call Trace: [ 37.722734] <TASK> [ 37.722735] ? __pfx_autoremove_wake_function+0x10/0x10 [ 37.722740] drm_sched_job_timedout+0x81/0x170 [gpu_sched] Fixes: 50292f9af8ec ("drm/xe: Move 'vm_max_level' flag back to platform descriptor") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/20251108040634.6376-2-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-11-10drm/ast: Handle framebuffer from dma-bufJocelyn Falempe
In the atomic update callback, ast should call drm_gem_fb_begin_cpu_access() to make sure it can read the framebuffer from the CPU, otherwise the data might not be there due to cache, and synchronization. Tested on a Lenovo SE100, while rendering on the ArrowLake GPU with i915 driver, and using ast for display. Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251030091627.340780-1-jfalempe@redhat.com Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2025-11-10drm/panthor: Flush shmem writes before mapping buffers CPU-uncachedBoris Brezillon
The shmem layer zeroes out the new pages using cached mappings, and if we don't CPU-flush we might leave dirty cachelines behind, leading to potential data leaks and/or asynchronous buffer corruption when dirty cachelines are evicted. Fixes: 8a1cc07578bf ("drm/panthor: Add GEM logical block") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251107171214.1186299-1-boris.brezillon@collabora.com
2025-11-10Merge remote-tracking branch 'drm/drm-next' into drm-misc-nextMaarten Lankhorst
Backmerge to prevent getting out of sync with drm-next too much. Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-11-10drm/msm: use drm_crtc_vblank_waitqueue()Jani Nikula
We have drm_crtc_vblank_waitqueue() to get the wait_queue_head_t pointer for a vblank. Use it instead of poking at dev->vblank[] directly. Due to the macro maze of wait_event_timeout() that uses the address-of operator on the argument, we have to pass it in with the indirection operator. Cc: Rob Clark <robin.clark@oss.qualcomm.com> Cc: Dmitry Baryshkov <lumag@kernel.org> Cc: Abhinav Kumar <abhinav.kumar@linux.dev> Cc: Jessica Zhang <jesszhan0024@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: Marijn Suijten <marijn.suijten@somainline.org> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/5917fd537f4a775a1c135a68f294df3917980943.1762513240.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-10drm/atomic: use drm_crtc_vblank_waitqueue()Jani Nikula
We have drm_crtc_vblank_waitqueue() to get the wait_queue_head_t pointer for a vblank. Use it instead of poking at dev->vblank[] directly. Due to the macro maze of wait_event_timeout() that uses the address-of operator on the argument, we have to pass it in with the indirection operator. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/1097348197acea9110da8baebbbc189890d01660.1762513240.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-10drm/gma500: use drm_crtc_vblank_crtc()Jani Nikula
We have drm_crtc_vblank_crtc() to get the struct drm_vblank_crtc pointer for a crtc. Use it instead of poking at dev->vblank[] directly. However, we also need to get the crtc to start with. We could use drm_crtc_from_index(), but refactor to use drm_for_each_crtc() instead. This is all a bit tedious, and perhaps the driver shouldn't be poking at vblank->enabled directly in the first place. But at least hide away the dev->vblank[] access in drm_vblank.c where it belongs. Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patch.msgid.link/27b2c6772c68120d0d5ec28477db0d993743e955.1762513240.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-10drm/vmwgfx: use drm_crtc_vblank_crtc()Jani Nikula
We have drm_crtc_vblank_crtc() to get the struct drm_vblank_crtc pointer for a crtc. Use it instead of poking at dev->vblank[] directly. Cc: Zack Rusin <zack.rusin@broadcom.com> Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/5157c2e927676aad75348855cf7b6745cba90003.1762513240.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-10drm/tidss: use drm_crtc_vblank_crtc()Jani Nikula
We have drm_crtc_vblank_crtc() to get the struct drm_vblank_crtc pointer for a crtc. Use it instead of poking at dev->vblank[] directly. Cc: Jyri Sarha <jyri.sarha@iki.fi> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Acked-by: Jyri Sarha <jyri.sarha@iki.fi> Link: https://patch.msgid.link/ffd5ebe03391b3c01e616c0c844a4b8ddecede36.1762513240.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-10drm/vblank: use drm_crtc_vblank_crtc() in workersJani Nikula
We have drm_crtc_vblank_crtc() to get the struct drm_vblank_crtc pointer for a crtc. Use it instead of poking at dev->vblank[] directly. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/f046701a10340c1dcaecb1b52e41dcf2236fded1.1762513240.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-10drm/i915/ltphy: Return lowest portclock for HDMI from reverse algorithmSuraj Kandpal
Return the lowest port clock for HDMI when the reverse algorithm calculates it to be 0 to avoid errors later but throw a warn. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20251110061940.545183-2-suraj.kandpal@intel.com
2025-11-10drm/i915/ltphy: Implement HDMI Algo for Pll stateSuraj Kandpal
Implement the HDMI Algorithm to dynamically create LT PHY state based on the port clock provided. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20251110061940.545183-1-suraj.kandpal@intel.com
2025-11-10drm/xe/vf: Enable VF resource fixup unconditionallyMichał Winiarski
All the feature enabling code is in place - drop the debug flag requirement for VF resource fixup. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251107161000.1938186-1-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
2025-11-09Merge tag 'kbuild-fixes-6.18-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux Pull Kbuild fixes from Nathan Chancellor: - Strip trailing padding bytes from modules.builtin.modinfo to fix error during modules_install with certain versions of kmod - Drop unused static inline function warning in .c files with clang from W=1 to W=2 - Ensure kernel-doc.py invocations use the PYTHON3 make variable to ensure user's choice of Python interpreter is always respected * tag 'kbuild-fixes-6.18-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux: kbuild: Let kernel-doc.py use PYTHON3 override compiler_types: Move unused static inline functions warning to W=2 kbuild: Strip trailing padding bytes from modules.builtin.modinfo
2025-11-08kbuild: Let kernel-doc.py use PYTHON3 overrideJean Delvare
It is possible to force a specific version of python to be used when building the kernel by passing PYTHON3= on the make command line. However kernel-doc.py is currently called with python3 hard-coded and thus ignores this setting. Use $(PYTHON3) to run $(KERNELDOC) so that the desired version of python is used. Signed-off-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Nicolas Schier <nsc@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://patch.msgid.link/20251107192933.2bfe9e57@endymion Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2025-11-08kbuild: Rename Makefile.extrawarn to Makefile.warnNathan Chancellor
Since commit e88ca24319e4 ("kbuild: consolidate warning flags in scripts/Makefile.extrawarn"), scripts/Makefile.extrawarn contains all warnings for the main kernel build, not just warnings enabled by the values for W=. Rename it to scripts/Makefile.warn to make it clearer that this Makefile is where all Kbuild warning handling should exist. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20251023-rename-scripts-makefile-extrawarn-v1-1-8f7531542169@kernel.org Signed-off-by: Nicolas Schier <nsc@kernel.org>
2025-11-08Revert "drm/nouveau: set DMA mask before creating the flush page"Dave Airlie
This reverts commit ebe755605082eddff80eafe0c50915b1366ee98f. Tested the latest kernel on my GB203 and this seems to break it somehow. Nov 09 04:16:14 bighp kernel: nouveau 0000:02:00.0: gsp: GSP-FMC boot failed (mbox: 0x0000000b) Nov 09 04:16:14 bighp kernel: nouveau 0000:02:00.0: gsp: init failed, -5 Nov 09 04:16:14 bighp kernel: nouveau 0000:02:00.0: init failed with -5 Nov 09 04:16:14 bighp kernel: nouveau: drm:00000000:00000080: init failed with -5 Nov 09 04:16:14 bighp kernel: nouveau 0000:02:00.0: drm: Device allocation failed: -5 Nov 09 04:16:14 bighp kernel: nouveau 0000:02:00.0: probe with driver nouveau failed with error -5 Not sure why, I went over the patch and thought it should have worked, but there must be some 32-bit problem maybe in the FMC boot path. Signed-off-by: Dave Airlie <airlied@redhat.com>
2025-11-08Merge tag 'drm-xe-fixes-2025-11-07' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Fix missing synchronization on unbind (Balasubramani Vivekanandan) - Fix device shutdown when doing FLR (Jouni Högander) - Fix user fence signaling order (Matthew Brost) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/mvfyflloncy76a7nmkatpj6f2afddavwsibz3y4u4wo6gznro5@rdulkuh5wvje
2025-11-07drm/xe/tests: Add KUnit tests for PF fair provisioningMichal Wajdeczko
Add test cases to check outcome of fair GuC context or doorbells IDs allocations for regular and admin-only PF mode. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20251106165932.2143-1-michal.wajdeczko@intel.com
2025-11-07drm/xe/pf: Use migration-friendly doorbells auto-provisioningMichal Wajdeczko
Instead of trying very hard to find the largest fair number of GuC doorbell IDs that could be allocated for VFs on the current GT, pick some smaller rounded down to power-of-two value that is more likely to be provisioned in the same manner by the other PF instance: num VFs | num doorbells --------+-------------- 63..32 | 4 31..16 | 8 15..8 | 16 7..4 | 32 3..2 | 64 1 | 128 (regular PF) 1 | 240 (admin only PF) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20251105183253.863-3-michal.wajdeczko@intel.com
2025-11-07drm/xe/pf: Use migration-friendly context IDs auto-provisioningMichal Wajdeczko
Instead of trying very hard to find the largest fair number of GuC context IDs that could be allocated for VFs on the current GT, pick some smaller rounded down to power-of-two value that is more likely to be provisioned in the same manner by the other PF instance: num VFs | num contexts --------+------------- 63..32 | 1024 31..16 | 2048 15..8 | 4096 7..4 | 8192 3..2 | 16384 1 | 32768 (regular PF) 1 | 64512 (admin only PF) Add also helper function to determine if the PF is admin-only, and for now use .probe_display flag for that. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20251105183253.863-2-michal.wajdeczko@intel.com
2025-11-07drm/i915/pmdemand: Use the default 2 usec fast polling timeoutVille Syrjälä
For whatever unknown reason the pmdemand code is using a custom 50 usec fast polling timeout instead of the normal 2 usec value. Switch to the standard value to get rid of the special case. The eventual aim is to get rid of the fast vs. slow timeout entirely and switch over to poll_timeout_us(). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251106152049.21115-11-ville.syrjala@linux.intel.com
2025-11-07drm/i915/hdcp: Use the default 2 usec fast polling timeoutVille Syrjälä
For whatever unknown reason the HDCP code is using a custom 10 usec fast polling timeout instead of the normal 2 usec value. Switch to the standard value to get rid of the special case. The eventual aim is to get rid of the fast vs. slow timeout entirely and switch over to poll_timeout_us(). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251106152049.21115-10-ville.syrjala@linux.intel.com
2025-11-07drm/i915/ltphy: Nuke bogus weird timeoutsVille Syrjälä
The LT PHY code is abusing intel_de_wait_custom() in all kinds of weird ways. Get rid of the weird fast timeouts, and just use the slow ones. For consistency with intel_wait_for_register() we'll stick to the default 2 usec fast timeout for all cases. Someone really needs to properly document where all these magic numbers came from... This will let us eventually nuke intel_de_wait_custom() and convert over to poll_timeout_us(). v2: Go for the longer (ms) timeout in case it actually matters Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251106152049.21115-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/cx0: s/XELPDP_PORT_RESET_END_TIMEOUT/XELPDP_PORT_RESET_END_TIMEOUT_MS/Ville Syrjälä
Include the units the in the define name for XELPDP_PORT_RESET_END_TIMEOUT to make it match all its other counterparts. v2: It's _MS not _US (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251106155249.2810-1-ville.syrjala@linux.intel.com
2025-11-07drm/i915/cx0: s/XELPDP_MSGBUS_TIMEOUT_SLOW/XELPDP_MSGBUS_TIMEOUT_MS/Ville Syrjälä
The slow vs. fast timeout stuff is really just an implementation detail. Let's not spread that terminology in random timeout defines. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251106152049.21115-7-ville.syrjala@linux.intel.com
2025-11-07drm/i915/cx0: Get rid of XELPDP_MSGBUS_TIMEOUT_FAST_USVille Syrjälä
XELPDP_MSGBUS_TIMEOUT_FAST_US looks to be just an obfuscated version of the default 2 microsecond fast timeout used by intel_wait_for_register(). Get rid of it to make it clear what's going on here. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251106152049.21115-6-ville.syrjala@linux.intel.com
2025-11-07drm/i915/cx0: Replace XELPDP_PORT_POWERDOWN_UPDATE_TIMEOUT_US with ↵Ville Syrjälä
XELPDP_PORT_POWERDOWN_UPDATE_TIMEOUT_MS There was a completely unjustified change to the cx0 powerdown timeout, and the way it was done now prevents future conversion to poll_timeout_us(). Assuming there was some reason the bigger timeout let's nuke the old short timeout (XELPDP_PORT_POWERDOWN_UPDATE_TIMEOUT_US) nd replace it with the bigger timeout (XELPDP_PORT_POWERDOWN_UPDATE_TIMEOUT_MS). For consistency with intel_wait_for_register() we'll stick to the default 2 usec for the fast timeout. v2: Go for the longer (ms) timeout in case it actually matters v3: Note the defaullt 2 usec fast timeout (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251106152049.21115-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/ltphy: Nuke extraneous timeout debugsVille Syrjälä
The actual timeout used isn't particularly interesting, so don't print it. Makes the code simpler. The debugs are also using some random capitalizaton rule. Clean that up a bit while at it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251106152049.21115-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/cx0: Nuke extraneous timeout debugsVille Syrjälä
The actual timeout used isn't particularly interesting, so don't print it. Makes the code simpler. The debugs are also using some random capitalizaton rule. Clean that up a bit while at it. Also intel_cx0_powerdown_change_sequence() used one timeout in the actual code but printed a different one. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251106152049.21115-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/gem: ↵Ville Syrjälä
s/i915_gem_object_get_frontbuffer/i915_gem_object_frontbuffer_lookup/ The i915_gem_object_get_frontbuffer() name is rather confusing wrt. intel_frontbuffer_get(). Rename to i915_gem_object_frontbuffer_lookup() to make things less confusing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-11-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/frontbuffer: Fix intel_frontbuffer lifetime handlingVille Syrjälä
The current attempted split between xe/i915 vs. display for intel_frontbuffer is a mess: - the i915 rcu leaks through the interface to the display side - the obj->frontbuffer write-side is now protected by a display specific spinlock even though the actual obj->framebuffer pointer lives in a i915 specific structure - the kref is getting poked directly from both sides - i915_active is still on the display side Clean up the mess by moving everything about the frontbuffer lifetime management to the i915/xe side: - the rcu usage is now completely contained in i915 - frontbuffer_lock is moved into i915 - kref is on the i915/xe side (xe needs the refcount as well due to intel_frontbuffer_queue_flush()->intel_frontbuffer_ref()) - the bo (and its refcounting) is no longer on the display side - i915_active is contained in i915 I was pondering whether we could do this in some kind of smaller steps, and perhaps we could, but it would probably have to start with a bunch of reverts (which for sure won't go cleanly anymore). So not convinced it's worth the hassle. Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-10-ville.syrjala@linux.intel.com
2025-11-07drm/i915/frontbuffer: Add intel_frontbuffer::displayVille Syrjälä
After upcoming intel_frontbuffer lifetime related changes we won't need intel_frontbuffer::obj for anything apart from getting at the display. Add a direct pointer for that instead so that the obj pointer can be completely eliminated. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/frontbuffer: Extract intel_frontbuffer_ref()Ville Syrjälä
I want to hide the kref from the high level frontbuffer code. To that end abstract the kref_get() in intel_frontbuffer_queue_flush() (which is the only high level function that needs this) as a new intel_frontbuffer_ref(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/frontbuffer: Split fb_tracking.lock into twoVille Syrjälä
Our fb_tracking.lock is serving a double duty: - protects fb_tracking.busy_bits - provides the write-side protection for obj->frontbuffer Split obj->frontbuffer role into a separate lock so that we can clean up the current mess with the frontbuffer lifetime management. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/frontbuffer: Handle the dirtyfb cache flush inside ↵Ville Syrjälä
intel_frontbuffer_flush() intel_bo_frontbuffer_flush_for_display() is a bit too low level to be directly in the high level dirtyfb code. Move the calls into intel_frontbuffer_flush(). There is a slight behavioural change here in that we now skip the flush if the bo is not a current scanout buffer (front->bits == 0). But that is fine as the flush will eventually happen via the fb pinning code if/when the bo becomes a scanout buffer again. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/frontbuffer: Turn intel_bo_flush_if_display() into a frontbuffer ↵Ville Syrjälä
operation Convert intel_bo_flush_if_display() to be an operation on the frontbuffer object rather than the underlying gem bo. This will help with cleaning up the frontbuffer xe/i915 vs. display split. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/frontbuffer: Nuke intel_frontbuffer_flip_{prepare,complete}()Ville Syrjälä
Get rid of intel_frontbuffer_flip_{prepare,complete}() (and the accompanying flip_bits) since they are unused. I suppose these could technically provide a minor optimization over intel_frontbuffer_flip() in that the flush would get deferred further if new rendering were to sneak in between the prepare() and complete() calls. But for correctness it should not make any difference since another flush will anyway follow once the new rendering finishes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/overlay: Switch to intel_frontbuffer_flip()Ville Syrjälä
Get rid of intel_frontbuffer_flip_{prepare,complete}() from the overlay code and just use intel_frontbuffer_flip() instead. The only difference between these are the light interactions with the ORIGIN_CS busyness tracking, but since the only user of this is the overlay/xf86-video-intel/Xv the buffer will always be filled by the CPU and thus we'll never see any ORIGIN_CS frontbuffer activity there anyway. Also I don't think we actually have anything covered by the frontbuffer tracking that affects the overlay (FBC is on the primary plane, DRRS isn't currently enabled on the platforms with overlay, and PSR doesn't exist in the hardware). Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-3-ville.syrjala@linux.intel.com
2025-11-07drm/i915/overlay: Drop the DIRTYFB flushVille Syrjälä
I don't even know why we have this DIRTYFB flush in the overlay code. We'll anyway call intel_frontbuffer_flip() so there should be no need to pretend that this is some kind of frontbuffer only rendering operation. Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-2-ville.syrjala@linux.intel.com
2025-11-07drm/i915/psr: fix pipe to vblank conversionJani Nikula
First, we can't assume pipe == crtc index. If a pipe is fused off in between, it no longer holds. intel_crtc_for_pipe() is the only proper way to get from a pipe to the corresponding crtc. Second, drivers aren't supposed to access or index drm->vblank[] directly. There's drm_crtc_vblank_crtc() for this. Use both functions to fix the pipe to vblank conversion. Fixes: f02658c46cf7 ("drm/i915/psr: Add mechanism to notify PSR of pipe enable/disable") Cc: Jouni Högander <jouni.hogander@intel.com> Cc: stable@vger.kernel.org # v6.16+ Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20251106200000.1455164-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/xe: Enforce correct user fence signaling order usingMatthew Brost
Prevent application hangs caused by out-of-order fence signaling when user fences are attached. Use drm_syncobj (via dma-fence-chain) to guarantee that each user fence signals in order, regardless of the signaling order of the attached fences. Ensure user fence writebacks to user space occur in the correct sequence. v7: - Skip drm_syncbj create of error (CI) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251031234050.3043507-2-matthew.brost@intel.com (cherry picked from commit adda4e855ab6409a3edaa585293f1f2069ab7299) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-07drm/xe: Do clean shutdown also when using flrJouni Högander
Currently Xe driver is triggering flr without any clean-up on shutdown. This is causing random warnings from pending related works as the underlying hardware is reset in the middle of their execution. Fix this by performing clean shutdown also when using flr. Fixes: 501d799a47e2 ("drm/xe: Wire up device shutdown handler") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Maarten Lankhorst <dev@lankhorst.se> Link: https://patch.msgid.link/20251031122312.1836534-1-jouni.hogander@intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> (cherry picked from commit a4ff26b7c8ef38e4dd34f77cbcd73576fdde6dd4) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-07drm/xe: Move declarations under conditional branchTejas Upadhyay
The xe_device_shutdown() function was needing a few declarations that were only required under a specific condition. This change moves those declarations to be within that conditional branch to avoid unnecessary declarations. Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251007100208.1407021-1-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> (cherry picked from commit 15b3036045188f4da4ca62b2ed01b0f160252e9b) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-07drm/xe/guc: Synchronize Dead CT worker with unbindBalasubramani Vivekanandan
Cancel and wait for any Dead CT worker to complete before continuing with device unbinding. Else the worker will end up using resources freed by the undind operation. Cc: Zhanjun Dong <zhanjun.dong@intel.com> Fixes: d2c5a5a926f4 ("drm/xe/guc: Dead CT helper") Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patch.msgid.link/20251103123144.3231829-6-balasubramani.vivekanandan@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 492671339114e376aaa38626d637a2751cdef263) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
generated by cgit v1.2.3 (git 2.0.4) at 2026-01-08 08:07:06 +0000