summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2025-10-31drm/i915/xe3p_lpd: use pixel normalizer for fp16 formats for FBCVinod Govindapillai
There is a hw restriction that we could enable the FBC for FP16 formats only if the pixel normalization block is enabled. Hence enable the pixel normalizer block with normalzation factor as 1.0 for the supported FP16 formats to get the FBC enabled. Two existing helper function definitions are moved up to avoid the forward declarations as part of this patch as well. v2: sw/hw state differentiation on handling pixel normalizer (Jani) Bspec: 69863, 68881 Cc: Shekhar Chauhan <shekhar.chauhan@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20251027134001.325064-5-vinod.govindapillai@intel.com
2025-10-31drm/i915/xe3p_lpd: extract pixel format valid routine for FP16 formatsVinod Govindapillai
As the pixel normalizer block is needed only for the FP16 formats, separating out the FP16 formats handling will benefit in selectively enabling the pixel normalizer block in the following patch. Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20251027134001.325064-4-vinod.govindapillai@intel.com
2025-10-31drm/i915/xe3p_lpd: Add FBC support for FP16 formatsVinod Govindapillai
Add supported FP16 formats for FBC. FBC can be enabled with FP16 formats only when plane pixel normalizer block is enabled. The follow up patches will handle the pixel normalizer block configuration. v2: changes related to comments to use better tracking of pixel normalizer Bspec: 6881, 69863, 68904 Cc: Shekhar Chauhan <shekhar.chauhan@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20251027134001.325064-3-vinod.govindapillai@intel.com
2025-10-31drm/i915/xe3p_lpd: Extend FBC support to UINT16 formatsSai Teja Pottumuttu
Starting Xe3p_LPD, FBC is supported on UINT16 formats as well. Also UINT16 being a 64bpp format, will use cpp of 8 for cfb stride and thus size calculations. v2: simplify getting the cpp per format (Ville) simplify the pixel format is valid for xe3p_lp (Vinod) Cc: Shekhar Chauhan <shekhar.chauhan@intel.com> BSpec: 68881, 68904, 69560 Signed-off-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20251027134001.325064-2-vinod.govindapillai@intel.com
2025-10-31drm/xe/compat: reduce i915_utils.[ch]Jani Nikula
Reduce the compat i915_utils.h to only cover the requirements of MISSING_CASE() in soc/ and the few i915_inject_probe_failure() instances, instead of including the entire i915_utils.h from i915. This prevents new users for the utilities from cropping up. With this, we can remove the xe/display/ext/i915_utils.c altogether. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patch.msgid.link/c02f82e45f31caf95bd1339080b9099c3b7190be.1761146196.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-31drm/i915/display: switch to intel_display_utils.hJani Nikula
The remaining utils display needs from i915_utils.h are primarily MISSING_CASE() and fetch_and_zero(), with a couple of i915_inject_probe_failure() uses. To avoid excessive churn, add duplicates of MISSING_CASE() and fetch_and_zero() to intel_display_utils.h, and switch display to use the display utils. As long as there are display files that include i915_drv.h, which includes i915_utils.h, we'll need #ifndef guards for MISSING_CASE() and fetch_and_zero() in both utils headers. We can remove them once display no longer depends on i915_drv.h. A couple of files in display still need i915_utils.h for i915_inject_probe_failure(). Annotate this. They will be handled separately. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patch.msgid.link/79f9e31ca64c8c045834d48e20ceb0c515d1e9e1.1761146196.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-31drm/i915/display: add intel_display_vtd_active()Jani Nikula
Add intel_display_vtd_active() to utils. It's intentional duplication with i915_utils.h i915_vtd_active(), but reduces duplication with xe. Win some, lose some. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patch.msgid.link/e022166af7c67f43904e2d0fc87bc5c13e0f1204.1761146196.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-31drm/i915/display: add intel_display_run_as_guest()Jani Nikula
Add intel_display_utils.c for display utilities that need more than a header. Start off with intel_display_run_as_guest(). The implementation is intentional duplication of the i915_utils.h i915_run_as_guest(), with the idea that it's small enough to not matter. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patch.msgid.link/469f9c41e0c3e3099314a3cf1a7671bf36ec8ffd.1761146196.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-31drm/i915/display: create intel_display_utils.hJani Nikula
Start a file for display specific generic utilities. Move KHz() and MHz() helpers there first. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patch.msgid.link/dbdd1915466850293b9737b751170dd225197873.1761146196.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-31drm/i915: split out separate files for jiffies timeout and wait helpersJani Nikula
Add i915_jiffies.h and intel_display_jiffies.h for jiffies timeout and wait helpers, and use them separately from i915 and display. This helps reduce the display dependency on i915_utils.h. Long term, both msecs_to_jiffies_timeout() and wait_remaining_ms_from_jiffies() really belong in core kernel headers, but for now unblock display refactoring. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patch.msgid.link/d8bc62b3a81afa05c849dde9b0f633572eaf5611.1761146196.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-31drm/i915/dsi: debug log send packet sequence contentsJani Nikula
This might help debug issues better than just debug logging the function name. v2: Debug log type as hex (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251029084603.2254982-2-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-31drm/i915/dsi: log send packet sequence errorsJani Nikula
We might be getting send packet sequence errors and never know. Log them as errors. Also upgrade the not supported read commands to errors. v2: Also error log -EOPNOTSUPP (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251029084603.2254982-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-31drm/panel: ilitek-ili9882t: Add support for Ilitek IL79900A-based panelsLangyan Ye
The Ilitek IL79900A display controller is similar to the ILI9882T and can be supported within the existing `panel-ilitek-ili9882t.c` driver. This patch extends the ILI9882T driver to handle IL79900A-based panels, such as the Tianma TL121BVMS07-00. The IL79900A uses a similar command sequence and initialization flow, with minor differences in power supply configuration and timing. Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251031100447.253164-3-yelangyan@huaqin.corp-partner.google.com
2025-10-31drm/sched: Fix comment in drm_sched_run_job_work()Philipp Stanner
drm_sched_run_job_work() contains a comment which explains that an entity being NULL means that there is no more work to do. It can, however, also mean that there is work, but the scheduler doesn't have enough credits to process the jobs right now. Provide this detail in the comment. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20251028134602.94125-3-phasta@kernel.org
2025-10-31drm/i915/gt: Use standard API for seqcount read in TLB invalidationAndi Shyti
seqprop_sequence() is not intended for use outside seqlock.h. Although it is accessible as a macro, it is meant to be used only internally within the header. Replace it with its proper wrapper, raw_read_seqcount(). Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Co-developed-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@linux.intel.com> Cc: Christoph Lameter (Ampere) <cl@gentwo.org> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Link: https://lore.kernel.org/r/20251023132802.654061-1-andi.shyti@linux.intel.com
2025-10-31drm/i915: Wait for page_sizes_gtt in gtt selftest on CHV/BXT+VTDJanusz Krzysztofik
VMA pinning to GGTT is now commited asynchronously in CHV / BXT+VDT environments to avoid lock inversion among reservation_ww and cpu_hotplug locks, the latter acquired from stop_machine(). Then, vma->resource->page_sizes_gtt the test uses as shift count may still be not populated (equal 0) after i915_vma_pin() returns. Wait for VMA bind completion in those cases to avoid shift-out-of-bounds kernel warnings and the test case failing with -EBADSLT. v2: Explain why VMA pinning is commited asynchronously on CHV/BXT+VTD (Krzysztof), - use more precise wording in commit description. Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Acked-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20251023082925.351307-8-janusz.krzysztofik@linux.intel.com
2025-10-31drm/i915: Wait longer for threads in migrate selftest on CHV/BXT+VTDJanusz Krzysztofik
When running on a Cherryview, or on a Broxton with VTD enabled, pinning of a VMA to GGTT is now committed asynchronously to avoid lock inversion among reservation_ww and cpu_hotplug locks, the latter acquired from stop_machine(). That may defer further processing of resources that depend on that VMA. As a consequence, a 10ms delay in a multithreaded migrate test case may occur too short and still incomplete threads may be interrupted, and the test case may fail with -ERESTARTSYS or -EINTR error code returned by any of those threads. Extend the delay to empirically determined 100ms on affected platforms. v3: Add an in-line comment that explains why 100ms (Andi). v2: Fix spelling (Sebastian, Krzysztof), - explain why VMA pinning is commited asynchronously on CHV/BXT+VTD (Krzysztof). Cc: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Acked-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20251023082925.351307-7-janusz.krzysztofik@linux.intel.com
2025-10-31drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTDJanusz Krzysztofik
On completion of i915_vma_pin_ww(), a synchronous variant of dma_fence_work_commit() is called. When pinning a VMA to GGTT address space on a Cherry View family processor, or on a Broxton generation SoC with VTD enabled, i.e., when stop_machine() is then called from intel_ggtt_bind_vma(), that can potentially lead to lock inversion among reservation_ww and cpu_hotplug locks. [86.861179] ====================================================== [86.861193] WARNING: possible circular locking dependency detected [86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G U [86.861226] ------------------------------------------------------ [86.861238] i915_module_loa/1432 is trying to acquire lock: [86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50 [86.861290] but task is already holding lock: [86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.862233] which lock already depends on the new lock. [86.862251] the existing dependency chain (in reverse order) is: [86.862265] -> #5 (reservation_ww_class_mutex){+.+.}-{3:3}: [86.862292] dma_resv_lockdep+0x19a/0x390 [86.862315] do_one_initcall+0x60/0x3f0 [86.862334] kernel_init_freeable+0x3cd/0x680 [86.862353] kernel_init+0x1b/0x200 [86.862369] ret_from_fork+0x47/0x70 [86.862383] ret_from_fork_asm+0x1a/0x30 [86.862399] -> #4 (reservation_ww_class_acquire){+.+.}-{0:0}: [86.862425] dma_resv_lockdep+0x178/0x390 [86.862440] do_one_initcall+0x60/0x3f0 [86.862454] kernel_init_freeable+0x3cd/0x680 [86.862470] kernel_init+0x1b/0x200 [86.862482] ret_from_fork+0x47/0x70 [86.862495] ret_from_fork_asm+0x1a/0x30 [86.862509] -> #3 (&mm->mmap_lock){++++}-{3:3}: [86.862531] down_read_killable+0x46/0x1e0 [86.862546] lock_mm_and_find_vma+0xa2/0x280 [86.862561] do_user_addr_fault+0x266/0x8e0 [86.862578] exc_page_fault+0x8a/0x2f0 [86.862593] asm_exc_page_fault+0x27/0x30 [86.862607] filldir64+0xeb/0x180 [86.862620] kernfs_fop_readdir+0x118/0x480 [86.862635] iterate_dir+0xcf/0x2b0 [86.862648] __x64_sys_getdents64+0x84/0x140 [86.862661] x64_sys_call+0x1058/0x2660 [86.862675] do_syscall_64+0x91/0xe90 [86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.862703] -> #2 (&root->kernfs_rwsem){++++}-{3:3}: [86.862725] down_write+0x3e/0xf0 [86.862738] kernfs_add_one+0x30/0x3c0 [86.862751] kernfs_create_dir_ns+0x53/0xb0 [86.862765] internal_create_group+0x134/0x4c0 [86.862779] sysfs_create_group+0x13/0x20 [86.862792] topology_add_dev+0x1d/0x30 [86.862806] cpuhp_invoke_callback+0x4b5/0x850 [86.862822] cpuhp_issue_call+0xbf/0x1f0 [86.862836] __cpuhp_setup_state_cpuslocked+0x111/0x320 [86.862852] __cpuhp_setup_state+0xb0/0x220 [86.862866] topology_sysfs_init+0x30/0x50 [86.862879] do_one_initcall+0x60/0x3f0 [86.862893] kernel_init_freeable+0x3cd/0x680 [86.862908] kernel_init+0x1b/0x200 [86.862921] ret_from_fork+0x47/0x70 [86.862934] ret_from_fork_asm+0x1a/0x30 [86.862947] -> #1 (cpuhp_state_mutex){+.+.}-{3:3}: [86.862969] __mutex_lock+0xaa/0xed0 [86.862982] mutex_lock_nested+0x1b/0x30 [86.862995] __cpuhp_setup_state_cpuslocked+0x67/0x320 [86.863012] __cpuhp_setup_state+0xb0/0x220 [86.863026] page_alloc_init_cpuhp+0x2d/0x60 [86.863041] mm_core_init+0x22/0x2d0 [86.863054] start_kernel+0x576/0xbd0 [86.863068] x86_64_start_reservations+0x18/0x30 [86.863084] x86_64_start_kernel+0xbf/0x110 [86.863098] common_startup_64+0x13e/0x141 [86.863114] -> #0 (cpu_hotplug_lock){++++}-{0:0}: [86.863135] __lock_acquire+0x1635/0x2810 [86.863152] lock_acquire+0xc4/0x2f0 [86.863166] cpus_read_lock+0x41/0x100 [86.863180] stop_machine+0x1c/0x50 [86.863194] bxt_vtd_ggtt_insert_entries__BKL+0x3b/0x60 [i915] [86.863987] intel_ggtt_bind_vma+0x43/0x70 [i915] [86.864735] __vma_bind+0x55/0x70 [i915] [86.865510] fence_work+0x26/0xa0 [i915] [86.866248] fence_notify+0xa1/0x140 [i915] [86.866983] __i915_sw_fence_complete+0x8f/0x270 [i915] [86.867719] i915_sw_fence_commit+0x39/0x60 [i915] [86.868453] i915_vma_pin_ww+0x462/0x1360 [i915] [86.869228] i915_vma_pin.constprop.0+0x133/0x1d0 [i915] [86.870001] initial_plane_vma+0x307/0x840 [i915] [86.870774] intel_initial_plane_config+0x33f/0x670 [i915] [86.871546] intel_display_driver_probe_nogem+0x1c6/0x260 [i915] [86.872330] i915_driver_probe+0x7fa/0xe80 [i915] [86.873057] i915_pci_probe+0xe6/0x220 [i915] [86.873782] local_pci_probe+0x47/0xb0 [86.873802] pci_device_probe+0xf3/0x260 [86.873817] really_probe+0xf1/0x3c0 [86.873833] __driver_probe_device+0x8c/0x180 [86.873848] driver_probe_device+0x24/0xd0 [86.873862] __driver_attach+0x10f/0x220 [86.873876] bus_for_each_dev+0x7f/0xe0 [86.873892] driver_attach+0x1e/0x30 [86.873904] bus_add_driver+0x151/0x290 [86.873917] driver_register+0x5e/0x130 [86.873931] __pci_register_driver+0x7d/0x90 [86.873945] i915_pci_register_driver+0x23/0x30 [i915] [86.874678] i915_init+0x37/0x120 [i915] [86.875347] do_one_initcall+0x60/0x3f0 [86.875369] do_init_module+0x97/0x2a0 [86.875385] load_module+0x2c54/0x2d80 [86.875398] init_module_from_file+0x96/0xe0 [86.875413] idempotent_init_module+0x117/0x330 [86.875426] __x64_sys_finit_module+0x77/0x100 [86.875440] x64_sys_call+0x24de/0x2660 [86.875454] do_syscall_64+0x91/0xe90 [86.875470] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.875486] other info that might help us debug this: [86.875502] Chain exists of: cpu_hotplug_lock --> reservation_ww_class_acquire --> reservation_ww_class_mutex [86.875539] Possible unsafe locking scenario: [86.875552] CPU0 CPU1 [86.875563] ---- ---- [86.875573] lock(reservation_ww_class_mutex); [86.875588] lock(reservation_ww_class_acquire); [86.875606] lock(reservation_ww_class_mutex); [86.875624] rlock(cpu_hotplug_lock); [86.875637] *** DEADLOCK *** [86.875650] 3 locks held by i915_module_loa/1432: [86.875663] #0: ffff888101f5c1b0 (&dev->mutex){....}-{3:3}, at: __driver_attach+0x104/0x220 [86.875699] #1: ffffc90002e0b4a0 (reservation_ww_class_acquire){+.+.}-{0:0}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.876512] #2: ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.877305] stack backtrace: [86.877326] CPU: 0 UID: 0 PID: 1432 Comm: i915_module_loa Tainted: G U 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 PREEMPT(voluntary) [86.877334] Tainted: [U]=USER [86.877336] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0079.2020.0420.1316 04/20/2020 [86.877339] Call Trace: [86.877344] <TASK> [86.877353] dump_stack_lvl+0x91/0xf0 [86.877364] dump_stack+0x10/0x20 [86.877369] print_circular_bug+0x285/0x360 [86.877379] check_noncircular+0x135/0x150 [86.877390] __lock_acquire+0x1635/0x2810 [86.877403] lock_acquire+0xc4/0x2f0 [86.877408] ? stop_machine+0x1c/0x50 [86.877422] ? __pfx_bxt_vtd_ggtt_insert_entries__cb+0x10/0x10 [i915] [86.878173] cpus_read_lock+0x41/0x100 [86.878182] ? stop_machine+0x1c/0x50 [86.878191] ? __pfx_bxt_vtd_ggtt_insert_entries__cb+0x10/0x10 [i915] [86.878916] stop_machine+0x1c/0x50 [86.878927] bxt_vtd_ggtt_insert_entries__BKL+0x3b/0x60 [i915] [86.879652] intel_ggtt_bind_vma+0x43/0x70 [i915] [86.880375] __vma_bind+0x55/0x70 [i915] [86.881133] fence_work+0x26/0xa0 [i915] [86.881851] fence_notify+0xa1/0x140 [i915] [86.882566] __i915_sw_fence_complete+0x8f/0x270 [i915] [86.883286] i915_sw_fence_commit+0x39/0x60 [i915] [86.884003] i915_vma_pin_ww+0x462/0x1360 [i915] [86.884756] ? i915_vma_pin.constprop.0+0x6c/0x1d0 [i915] [86.885513] i915_vma_pin.constprop.0+0x133/0x1d0 [i915] [86.886281] initial_plane_vma+0x307/0x840 [i915] [86.887049] intel_initial_plane_config+0x33f/0x670 [i915] [86.887819] intel_display_driver_probe_nogem+0x1c6/0x260 [i915] [86.888587] i915_driver_probe+0x7fa/0xe80 [i915] [86.889293] ? mutex_unlock+0x12/0x20 [86.889301] ? drm_privacy_screen_get+0x171/0x190 [86.889308] ? acpi_dev_found+0x66/0x80 [86.889321] i915_pci_probe+0xe6/0x220 [i915] [86.890038] local_pci_probe+0x47/0xb0 [86.890049] pci_device_probe+0xf3/0x260 [86.890058] really_probe+0xf1/0x3c0 [86.890067] __driver_probe_device+0x8c/0x180 [86.890072] driver_probe_device+0x24/0xd0 [86.890078] __driver_attach+0x10f/0x220 [86.890083] ? __pfx___driver_attach+0x10/0x10 [86.890088] bus_for_each_dev+0x7f/0xe0 [86.890097] driver_attach+0x1e/0x30 [86.890101] bus_add_driver+0x151/0x290 [86.890107] driver_register+0x5e/0x130 [86.890113] __pci_register_driver+0x7d/0x90 [86.890119] i915_pci_register_driver+0x23/0x30 [i915] [86.890833] i915_init+0x37/0x120 [i915] [86.891482] ? __pfx_i915_init+0x10/0x10 [i915] [86.892135] do_one_initcall+0x60/0x3f0 [86.892145] ? __kmalloc_cache_noprof+0x33f/0x470 [86.892157] do_init_module+0x97/0x2a0 [86.892164] load_module+0x2c54/0x2d80 [86.892168] ? __kernel_read+0x15c/0x300 [86.892185] ? kernel_read_file+0x2b1/0x320 [86.892195] init_module_from_file+0x96/0xe0 [86.892199] ? init_module_from_file+0x96/0xe0 [86.892211] idempotent_init_module+0x117/0x330 [86.892224] __x64_sys_finit_module+0x77/0x100 [86.892230] x64_sys_call+0x24de/0x2660 [86.892236] do_syscall_64+0x91/0xe90 [86.892243] ? irqentry_exit+0x77/0xb0 [86.892249] ? sysvec_apic_timer_interrupt+0x57/0xc0 [86.892256] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.892261] RIP: 0033:0x7303e1b2725d [86.892271] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8b bb 0d 00 f7 d8 64 89 01 48 [86.892276] RSP: 002b:00007ffddd1fdb38 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [86.892281] RAX: ffffffffffffffda RBX: 00005d771d88fd90 RCX: 00007303e1b2725d [86.892285] RDX: 0000000000000000 RSI: 00005d771d893aa0 RDI: 000000000000000c [86.892287] RBP: 00007ffddd1fdbf0 R08: 0000000000000040 R09: 00007ffddd1fdb80 [86.892289] R10: 00007303e1c03b20 R11: 0000000000000246 R12: 00005d771d893aa0 [86.892292] R13: 0000000000000000 R14: 00005d771d88f0d0 R15: 00005d771d895710 [86.892304] </TASK> Call asynchronous variant of dma_fence_work_commit() in that case. v3: Provide more verbose in-line comment (Andi), - mention target environments in commit message. Fixes: 7d1c2618eac59 ("drm/i915: Take reservation lock around i915_vma_pin.") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14985 Cc: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Acked-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20251023082925.351307-6-janusz.krzysztofik@linux.intel.com
2025-10-31drm/ttm: Add an allocation flag to propagate -ENOSPC on OOMTvrtko Ursulin
Some graphics APIs differentiate between out-of-graphics-memory and out-of-host-memory (system memory). Add a device init flag to have -ENOSPC propagated from the resource managers instead of being converted to -ENOMEM, to aid driver stacks in determining what error code to return or whether corrective action can be taken at the driver level. Co-developed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Christian König <christian.koenig@amd.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-7-tvrtko.ursulin@igalia.com
2025-10-31drm/amdgpu: Configure max beneficial TTM pool allocation orderTvrtko Ursulin
Let the TTM pool allocator know that we can afford for it to expend less effort for satisfying contiguous allocations larger than 2MiB. The latter is the maximum relevant PTE entry size and the driver and hardware are happy to get larger blocks only opportunistically. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-6-tvrtko.ursulin@igalia.com
2025-10-31drm/ttm: Allow drivers to specify maximum beneficial TTM pool sizeTvrtko Ursulin
GPUs typically benefit from contiguous memory via reduced TLB pressure and improved caching performance, where the maximum size of contiguous block which adds a performance benefit is related to hardware design. TTM pool allocator by default tries (hard) to allocate up to the system MAX_PAGE_ORDER blocks. This varies by the CPU platform and can also be configured via Kconfig. If that limit was set to be higher than the GPU can make an extra use of, lets allow the individual drivers to let TTM know over which allocation order can the pool allocator afford to make a little bit less effort with. We implement this by disabling direct reclaim for those allocations, which reduces the allocation latency and lowers the demands on the page allocator, in cases where expending this effort is not critical for the GPU in question. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-5-tvrtko.ursulin@igalia.com
2025-10-31drm/ttm: Replace multiple booleans with flags in device initTvrtko Ursulin
Multiple consecutive boolean function arguments are usually not very readable. Replace the ones in ttm_device_init() with flags with the additional benefit of soon being able to pass in more data with just a one off code base churning cost. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Sui Jingfeng <suijingfeng@loongson.cn> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Zack Rusin <zack.rusin@broadcom.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Zack Rusin <zack.rusin@broadcom.com> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> # For xe Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-4-tvrtko.ursulin@igalia.com [tursulin: fixup checkpatch while applying]
2025-10-31drm/ttm: Replace multiple booleans with flags in pool initTvrtko Ursulin
Multiple consecutive boolean function arguments are usually not very readable. Replace the ones in ttm_pool_init() with flags with the additional benefit of soon being able to pass in more data with just this one code base churning cost. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-3-tvrtko.ursulin@igalia.com
2025-10-31drm/ttm: Add getter for some pool propertiesTvrtko Ursulin
No functional change but to allow easier refactoring in the future. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-2-tvrtko.ursulin@igalia.com
2025-10-31drm: include drm_print.h where neededJani Nikula
There are a gazillion files that depend on drm_print.h being indirectly included via drm_buddy.h, drm_mm.h, or ttm/ttm_resource.h. In preparation for removing those includes, explicitly include drm_print.h where needed. Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/5fe67395907be33eb5199ea6d540e29fddee71c8.1761734313.git.jani.nikula@intel.com
2025-10-30drm/xe/gt_throttle: Drop individual show functionsLucas De Marchi
They are all doing the same thing with the mask being the param. Just declare our own attribute to store the mask and provide a single function. Another common pattern is to define the show function in the macro, however on follow up work the mask may be used for returning more information, so it'd need to be stored in any case. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-7-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/xe: Improve freq and throttle documentationLucas De Marchi
Add xe_gt_throttle under the "GT Frequency Management" and improve the narrative making sure the documentation for both *_freq and throttle/* attributes follow the same style. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-6-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/xe/gt_throttle: Tidy up attribute definitionLucas De Marchi
Move the attribute definitions to be grouped together rather than near the show() function: checkpatch keeps complaining about the missing newline when defining new attributes and it reads better to group everything, which should match e.g. the xe_pmu.c style. While grouping them, also define a THROTTLE_ATTR_RO(), similar to DEVICE_ATTR_RO(), and use it to define all attributes. This makes it shorter and with a familiar syntax. Finally, during the cri_throttle_attrs[] array definition, also highlight what's coming from common attributes and what is CRI-specific. These 3 things could be done as separate commits, but they are all about the same thing: reduce the attribute definition verbosity and are very simple and mechanical. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-5-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/xe/gt_throttle: Add throttle_to_gt()Lucas De Marchi
Reduce boilerplate code by adding a helper to go directly from the throttle kobject to the gt. Note that there's already a kobj_to_gt(), but that actually converts our kobj_gt object to gt. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-4-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/xe/gt_throttle: Always read and maskLucas De Marchi
Use a single function to read and mask the value the callers will be interested in. This reduces the risk of a caller using a plain call to xe_gt_throttle_get_limit_reasons() without applying any mask, which can return unexpected bits for future platforms. Select which reg and mask it's going to be used according to the platform and gt type and always use that one function. There was an odd xe_gt_dbg() when reading the status, which is not done for any other throttle/* sysfs file, so just make the status be as special as everybody else. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-3-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/xe/gt_throttle: Tidy up perf reasons readingLucas De Marchi
There's no need to be so verbose with two functions per bit: read_reason_xxxxx() and reason_xxxxx_show(). Drop the former and just use a new is_throttled_by() that receives the mask as parameter. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-2-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/xe/cri: Add new performance limit reasons bitsSk Anirban
Crescent Island has some additional and different bits for performance limit reasons. Add the new definitions and use them for CRI. Signed-off-by: Sk Anirban <sk.anirban@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-1-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/client: Flush client buffers with drm_client_buffer_sync()Thomas Zimmermann
Rename drm_client_framebuffer_flush() to drm_cient_buffer_flush() and adapt its callers. The old name was left over from previous naming conventions. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>> Tested-by: Francesco Valla <francesco@valla.it> Link: https://patch.msgid.link/20251027121042.143588-8-tzimmermann@suse.de
2025-10-30drm/client: Create client buffers with drm_client_buffer_create_dumb()Thomas Zimmermann
Rename drm_client_framebuffer_create() to drm_client_buffer_create_dump() and adapt callers. The new name reflects the function's purpose. Using dumb buffers is the easiest way for creating a GEM buffer in a drivers- independent way. There's also drm_client_buffer_create(), which creates the client buffer from a preexisting buffer object. This helper can be exported for drivers that create their own GEM buffer object. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Francesco Valla <francesco@valla.it> Link: https://patch.msgid.link/20251027121042.143588-7-tzimmermann@suse.de
2025-10-30drm/client: Remove drm_client_framebuffer_delete()Thomas Zimmermann
Release client buffers with drm_client_buffer_delete() instead of drm_client_framebuffer_delete(). The latter is just a tiny wrapper around the former. Move the test for !buffer into drm_client_buffer_delete(), although all callers appear to always have a valid pointer. v2: - test for !buffer before deref-ing pointer (Jocelyn, Dan) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Francesco Valla <francesco@valla.it> Link: https://patch.msgid.link/20251027121042.143588-6-tzimmermann@suse.de
2025-10-30drm/client: Deprecate struct drm_client_buffer.gemThomas Zimmermann
The client buffer's framebuffer holds a reference and pointer on each of its GEM buffer objects. Thus the field gem in the client- buffer struct is not necessary. Deprecated the field and convert the client-buffer helpers to use the framebuffer's objects. In drm_client_buffer_delete(), do a possible vunmap before releasing the framebuffer. Otherwise we'd eventually release the framebuffer before unmaping its buffer objects. v2: - avoid dependency on CONFIG_DRM_KMS_HELPER Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Francesco Valla <francesco@valla.it> Link: https://patch.msgid.link/20251027121042.143588-5-tzimmermann@suse.de
2025-10-30drm/client: Inline drm_client_buffer_addfb() and _rmfb()Thomas Zimmermann
Creating and deleting a client buffer always creates and deletes the underlying DRM framebuffer. Inline the helper functions into their callers. With the _addfb code being inlined into drm_client_buffer_create(), clean up the function's error rollback to release the framebuffer's handle and GEM buffer object as needed. Move the _rmfb code into drm_client_buffer_delete() rather than its current location in drm_client_framebuffer_delete(). The former is now the inverse of drm_client_buffer_create(). Makes no difference for cleaning up. Also prepares for the removal of drm_client_framebuffer_delete(). Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Francesco Valla <francesco@valla.it> Link: https://patch.msgid.link/20251027121042.143588-4-tzimmermann@suse.de
2025-10-30drm/client: Move dumb-buffer handling to drm_client_framebuffer_create()Thomas Zimmermann
Dumb-buffer creation within the client code is asymetrically balanced across drm_client_buffer_create() and drm_client_framebuffer_create(). Put all dumb-buffer code into drm_client_framebuffer_create() and leave client-buffer initialization to drm_client_buffer_create(). Clarifies responsibility between these functions. Apart form the architectural improvements, drm_client_buffer_create() can now be exported if needed by clients. The client will be able to initialize buffers that have been created from other interfaces than dumb buffers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Francesco Valla <francesco@valla.it> Link: https://patch.msgid.link/20251027121042.143588-3-tzimmermann@suse.de
2025-10-30drm/client: Remove pitch from struct drm_client_bufferThomas Zimmermann
Only the client-buffer setup uses the pitch field from struct drm_client_buffer. Remove the field and pass the value among setup helpers. Clients that need the pitch should rather look at the framebuffer's pitches[0] directly. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Francesco Valla <francesco@valla.it> Link: https://patch.msgid.link/20251027121042.143588-2-tzimmermann@suse.de
2025-10-30drm/ast: Clear preserved bits from register output valueThomas Zimmermann
Preserve the I/O register bits in __ast_write8_i_masked() as specified by preserve_mask. Accidentally OR-ing the output value into these will overwrite the register's previous settings. Fixes display output on the AST2300, where the screen can go blank at boot. The driver's original commit 312fec1405dd ("drm: Initial KMS driver for AST (ASpeed Technologies) 2000 series (v2)") already added the broken code. Commit 6f719373b943 ("drm/ast: Blank with VGACR17 sync enable, always clear VGACRB6 sync off") triggered the bug. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reported-by: Peter Schneider <pschneider1968@googlemail.com> Closes: https://lore.kernel.org/dri-devel/a40caf8e-58ad-4f9c-af7f-54f6f69c29bb@googlemail.com/ Tested-by: Peter Schneider <pschneider1968@googlemail.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Fixes: 6f719373b943 ("drm/ast: Blank with VGACR17 sync enable, always clear VGACRB6 sync off") Fixes: 312fec1405dd ("drm: Initial KMS driver for AST (ASpeed Technologies) 2000 series (v2)") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Nick Bowler <nbowler@draconx.ca> Cc: Douglas Anderson <dianders@chromium.org> Cc: Dave Airlie <airlied@redhat.com> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v3.5+ Link: https://patch.msgid.link/20251024073626.129032-1-tzimmermann@suse.de
2025-10-30drm/imx: parallel-display: add the bridge before attaching itLuca Ceresoli
Invoking drm_bridge_add() is good practice, so add it to this driver. Link: https://lore.kernel.org/all/DDHZ5GO9MPF0.CGYTVBI74FOZ@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://patch.msgid.link/20251014-drm-bridge-alloc-imx-ipuv3-v1-2-a1bb1dcbff50@bootlin.com Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-10-30drm/imx: parallel-display: convert to devm_drm_bridge_alloc() APILuca Ceresoli
This is the new API for allocating DRM bridges. This conversion was missed during the initial conversion of all bridges to the new API. Thus all kernels with commit 94d50c1a2ca3 ("drm/bridge: get/put the bridge reference in drm_bridge_attach/detach()") and using this driver now warn due to drm_bridge_attach() incrementing the refcount, which is not initialized without using devm_drm_bridge_alloc() for allocation. To make the conversion simple and straightforward without messing up with the drmm_simple_encoder_alloc(), move the struct drm_bridge from struct imx_parallel_display_encoder to struct imx_parallel_display. Also remove the 'struct imx_parallel_display *pd' from struct imx_parallel_display_encoder, not needed anymore. Fixes: 94d50c1a2ca3 ("drm/bridge: get/put the bridge reference in drm_bridge_attach/detach()") Reported-by: Ernest Van Hoecke <ernestvanhoecke@gmail.com> Closes: https://lore.kernel.org/all/hlf4wdopapxnh4rekl5s3kvoi6egaga3lrjfbx6r223ar3txri@3ik53xw5idyh/ Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Tested-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com> Link: https://patch.msgid.link/20251014-drm-bridge-alloc-imx-ipuv3-v1-1-a1bb1dcbff50@bootlin.com Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-10-30drm/imx/parallel-display: drop unused module aliasJohan Hovold
The driver has never supported anything but OF probe so drop the unused platform module alias incorrectly added by commit b2da05ff4797 ("imx-drm: parallel-display: Add MODULE_ALIAS()") Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250924092643.26113-5-johan@kernel.org Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-10-30drm/imx/tve: drop unused module aliasJohan Hovold
The driver has never supported anything but OF probe so drop the unused platform module alias incorrectly added by commit 52db752c3de5 ("imx-drm: imx-tve: Add MODULE_ALIAS()"). Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250924092643.26113-4-johan@kernel.org Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-10-30drm/imx/ldb: drop unused module aliasJohan Hovold
The driver has never supported anything but OF probe so drop the unused platform module alias incorrectly added by commit bc627387a951 ("imx-drm: imx-ldb: Add MODULE_ALIAS()"). Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250924092643.26113-3-johan@kernel.org Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-10-30drm/imx/dw-hdmi: drop unused module aliasJohan Hovold
The driver has never supported anything but OF probe so drop the unused platform module alias which was incorrectly added by commit 3d1b35a3d9f3 ("drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode"). Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250924092643.26113-2-johan@kernel.org Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-10-30drm/panel: synaptics-tddi: fix build error by missing regulator/consumer.h ↵Stephen Rothwell
include Fix up for "backlight: Do not include <linux/fb.h> in header file" interacting with [1] from the drm-misc tree. [1] commit 3eae82503f4f ("drm: panel: add support for Synaptics TDDI series DSI panels") Fixes: 3eae82503f4f ("drm: panel: add support for Synaptics TDDI series DSI panels") Closes: https://lore.kernel.org/all/20251030151428.3c1f11ea@canb.auug.org.au/ Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251030-topic-drm-fix-panel-synaptics-tddi-v1-1-206519d246e8@linaro.org
2025-10-30drm/i915/display: Expose sharpness strength propertyNemesa Garg
Expose the drm crtc sharpness strength property which will enable or disable the sharpness/casf based on user input. With this user can set/update the strength of the sharpness or casf filter. v2: Update subject[Ankit] Signed-off-by: Nemesa Garg <nemesa.garg@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20251028120747.3027332-11-ankit.k.nautiyal@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-30drm/i915/display: Enable/disable casfNemesa Garg
Call intel_casf_enable and intel_casf_disable in atomic commit path to enable and disable casf. Call intel_casf_update_strength to only update the desired strength value. v2: Introduce casf_enable here.[Ankit] v3: Use is_disabling in casf_disabling.[Ankit] v4: Swap old_state and new_state param.[Ankit] v5: In disable fn move win_sz after sharpness_ctl. v6: Rebase and update commit message. Signed-off-by: Nemesa Garg <nemesa.garg@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20251028120747.3027332-10-ankit.k.nautiyal@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-30drm/i915/display: Set and get the casf configNemesa Garg
Set the configuration for CASF and capture it in crtc_state and get the configuration by reading back. Add the support to compare the software and hardware state of CASF. v2: Update subject[Ankit] v3: Add the state compare[Ankit] Signed-off-by: Nemesa Garg <nemesa.garg@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20251028120747.3027332-9-ankit.k.nautiyal@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-25 07:49:08 +0000