summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2025-11-11drm/i915/de: Introduce intel_de_wait_for_{set,clear}_us()Ville Syrjälä1-0/+14
Add intel_de_wait_for_set_us() and intel_de_wait_for_clear_us() as the microsecond counterparts to intel_de_wait_for_set_ms() and intel_de_wait_for_clear_ms(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251110172756.2132-9-ville.syrjala@linux.intel.com Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com>
2025-11-11drm/i915/de: Nuke intel_de_wait_custom()Ville Syrjälä1-19/+0
intel_de_wait_custom() is finally unused. Get rid of it before people start abusing it more. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251110172756.2132-8-ville.syrjala@linux.intel.com Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com>
2025-11-11drm/i915/de: Use intel_de_wait_ms() for the obvious casesVille Syrjälä5-34/+30
Replace some users of intel_de_wait_custom() with intel_de_wait_ms(). This includes the cases where we pass in the default 2 microsecond fast timeout, which is also what intel_de_wait_ms() uses so there are no functional changes here. Done with cocci (with manual formatting fixes): @@ expression display, reg, mask, value, timeout_ms, out_value; @@ - intel_de_wait_custom(display, reg, mask, value, 2, timeout_ms, out_value) + intel_de_wait_ms(display, reg, mask, value, timeout_ms, out_value) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251110172756.2132-7-ville.syrjala@linux.intel.com Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com>
2025-11-11drm/i915/de: Use intel_de_wait_us()Ville Syrjälä8-83/+67
Convert some of the intel_de_wait_custom() users over to intel_de_wait_us(). We'll eventually want to eliminate intel_de_wait_custom() as it's a hinderance towards using poll_timeout_us(). This includes all the obvious cases where we only specify a microsecond timeout to intel_de_wait_custom(). Done with cocci (with manual formatting fixes): @@ expression display, reg, mask, value, timeout_us, out_value; @@ - intel_de_wait_custom(display, reg, mask, value, timeout_us, 0, out_value) + intel_de_wait_us(display, reg, mask, value, timeout_us, out_value) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251110172756.2132-6-ville.syrjala@linux.intel.com Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com>
2025-11-11drm/i915/de: Introduce intel_de_wait_us()Ville Syrjälä1-0/+17
Introduce intel_de_wait_us() as the microsecond based counterpart to the millisecond based intel_de_wait_ms(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251110172756.2132-5-ville.syrjala@linux.intel.com Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com>
2025-11-11drm/i915/de: Include units in intel_de_wait*() function namesVille Syrjälä30-205/+207
intel_de_wait*() take the timeout in milliseconds. Include that information in the function name to make life less confusing. I'll also be introducing microsecond variants of these later. Done with cocci: @@ @@ ( static int - intel_de_wait + intel_de_wait_ms (...) { ... } | static int - intel_de_wait_fw + intel_de_wait_fw_ms (...) { ... } | static int - intel_de_wait_for_set + intel_de_wait_for_set_ms (...) { ... } | static int - intel_de_wait_for_clear + intel_de_wait_for_clear_ms (...) { ... } ) @@ @@ ( - intel_de_wait + intel_de_wait_ms | - intel_de_wait_fw + intel_de_wait_fw_ms | - intel_de_wait_for_set + intel_de_wait_for_set_ms | - intel_de_wait_for_clear + intel_de_wait_for_clear_ms ) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251110172756.2132-4-ville.syrjala@linux.intel.com Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com>
2025-11-11drm/i915/de: Have intel_de_wait() hand out the final register valueVille Syrjälä4-8/+8
We currently have a bunch of places that want the final register value after register polling. Currently those places are mostly using intel_de_wait_custom(). That is not a function that we want to keep around as it pretty much prevents conversion to poll_timeout_us(). Have intel_de_wait() also return the final register value so that some of the current users can be converted over to the simpler interface. Done with cocci: @@ @@ int intel_de_wait(... + ,u32 *out_value ) { ... __intel_wait_for_register(..., - NULL + out_value ) ... } @@ @@ intel_de_wait(... + ,NULL ) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251110172756.2132-3-ville.syrjala@linux.intel.com Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com>
2025-11-11drm/i915/de: Implement register waits one wayVille Syrjälä2-34/+14
Currently we use a messy mix of intel_wait_for_register*() and __intel_wait_for_register*() to implement various register polling functions. Make the mess a bit more understandable by always using the __intel_wait_for_register*() stuff. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251110172756.2132-2-ville.syrjala@linux.intel.com Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com>
2025-11-11drm/i915/rom: convert intel_rom interfaces to struct drm_deviceJani Nikula3-10/+9
Reduce the display dependency on struct drm_i915_private and i915_drv.h by converting the rom interface to struct drm_device. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20251110112048.2366725-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-11Merge drm/drm-next into drm-intel-nextJani Nikula1149-7997/+39708
Primarily sync with the drm_print.h changes from drm-misc. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-11Merge tag 'amd-drm-next-6.19-2025-11-07' of ↵Dave Airlie105-1133/+2437
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.19-2025-11-07: amdgpu: - Misc fixes - HMM cleanup - HDP flush rework - RAS updates - SMU 13.x updates - SI DPM cleanup - Suspend rework - UQ reset support - Replay/PSR fixes - HDCP updates - DC PMO fixes - DC pstate fixes - DCN4 fixes - GPUVM fixes - SMU 13 parition metrics - Fix possible fence leak in job cleanup - Hibernation fix - MST fix amdkfd: - HMM cleanup - Process cleanup fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20251107145938.26669-1-alexander.deucher@amd.com
2025-11-10drm/xe/pf: Add runtime registers for GFX ver >= 35Piotr Piórkowski1-1/+20
Add a dedicated runtime register list for GFX ver >= 35. Compared to the list for GFX >= 30, this variant drops HUC_KERNEL_LOAD_INFO, MIRROR_FUSE1 and adds SERVICE_COPY_ENABLE. v2: - drop MIRROR_FUSE1 register - update commit message Fixes: 5e0de2dfbc1b ("drm/xe/cri: Add CRI platform definition") Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251107211845.3633633-1-piotr.piorkowski@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-10drm/xe/xe3lpg: Extend Wa_15016589081 for xe3lpgNitin Gote1-0/+5
Wa_15016589081 applies to Xe3_LPG renderCS Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patch.msgid.link/20251106100516.318863-2-nitin.r.gote@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 715974499a2199bd199fb4630501f55545342ea4) Cc: stable@vger.kernel.org # v6.16+ Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-10drm/xe/xe3: Extend wa_14023061436Tangudu Tilak Tirumalesh1-0/+2
Extend wa_14023061436 to Graphics Versions 30.03, 30.04 and 30.05. Signed-off-by: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20251030154626.3124565-1-tilak.tirumalesh.tangudu@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 0dd656d06f50ae4cedf160634cf13fd9e0944cf7) Cc: stable@vger.kernel.org # v6.17+ Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-10drm/xe/xe3: Add WA_14024681466 for Xe3_LPGNitin Gote2-0/+5
Apply WA_14024681466 to Xe3_LPG graphics IP versions from 30.00 to 30.05. v2: (Matthew Roper) - Remove stepping filter as workaround applies to all steppings. - Add an engine class filter so it only applies to the RENDER engine. Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patch.msgid.link/20251027092643.335904-1-nitin.r.gote@intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 071089a69e199bd810ff31c4c933bd528e502743) Cc: stable@vger.kernel.org # v6.16+ Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-10drm/xe/vram: Move forcewake down to get_flat_ccs_offset()Lucas De Marchi1-10/+14
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 Yang3-2/+3
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 Deak1-0/+4
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 Nikula1-1/+2
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 Goel1-1/+17
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 Vivi1-1/+1
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 Falempe1-3/+8
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 Brezillon1-0/+18
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 Lankhorst651-4791/+33269
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 Nikula2-2/+4
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 Nikula1-1/+3
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 Nikula1-13/+23
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 Nikula1-4/+2
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 Nikula1-2/+1
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 Nikula1-1/+1
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 Kandpal1-4/+10
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 Kandpal3-2/+348
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ł Winiarski1-8/+0
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 Torvalds2-2/+2
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-09kbuild: Let kernel-doc.py use PYTHON3 overrideJean Delvare2-2/+2
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 Chancellor1-1/+1
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 Airlie1-12/+12
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 Airlie11-25/+96
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 Wajdeczko2-0/+166
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 Wajdeczko1-0/+17
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 Wajdeczko2-0/+27
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ä1-1/+1
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ä1-1/+1
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ä2-10/+8
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ä2-2/+2
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ä3-8/+8
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ä2-3/+1
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ä2-2/+2
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ä1-18/+16
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ä1-19/+16
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>
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-02 23:53:06 +0300