aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm (follow)
AgeCommit message (Collapse)AuthorFilesLines
2025-09-09drm/i915: Drop unused struct_mutex from drm_i915_privateLuiz Otavio Mello2-10/+0
The struct_mutex field in drm_i915_private is no longer used anywhere in the driver. This patch removes it completely to clean up unused code and avoid confusion. Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250908131518.36625-9-luiz.mello@estudante.ufscar.br Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/i915: Clean-up outdated struct_mutex commentsLuiz Otavio Mello2-4/+2
The struct_mutex will be removed from the DRM subsystem, as it was a legacy BKL that was only used by i915 driver. After review, it was concluded that its usage was no longer necessary This patch updates various comments in the i915 codebase to either remove or clarify references to struct_mutex, in order to prevent future misunderstandings. * i915_drv.h: Removed the statement that stolen_lock is the inner lock when overlaps with struct_mutex, since struct_mutex is no longer used in the driver. * i915_gem.c: Removed parentheses suggesting usage of struct_mutex, which which is no longer used. Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250908131518.36625-8-luiz.mello@estudante.ufscar.br Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/i915/display: Remove outdated struct_mutex commentsLuiz Otavio Mello1-5/+1
The struct_mutex will be removed from the DRM subsystem, as it was a legacy BKL that was only used by i915 driver. After review, it was concluded that its usage was no longer necessary This patch update a comment about struct_mutex in i915/display, in order to prevent future misunderstandings. * intel_fbc.c: Removed the statement that intel_fbc->lock is the inner lock when overlapping with struct_mutex, since struct_mutex is no longer used anywhere in the driver. Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250908131518.36625-7-luiz.mello@estudante.ufscar.br Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/i915/gem: Clean-up outdated struct_mutex commentsLuiz Otavio Mello5-10/+10
The struct_mutex will be removed from the DRM subsystem, as it was a legacy BKL that was only used by i915 driver. After review, it was concluded that its usage was no longer necessary This patch updates various comments in the i915/gem and i915/gt codebase to either remove or clarify references to struct_mutex, in order to prevent future misunderstandings. * i915_gem_execbuffer.c: Replace reference to struct_mutex with vm->mutex, as noted in the eb_reserve() function, which states that vm->mutex handles deadlocks. * i915_gem_object.c: Change struct_mutex by drm_i915_gem_object->vma.lock. i915_gem_object_unbind() in i915_gem.c states that this lock is who actually protects the unbind. * i915_gem_shrinker.c: The correct lock is actually i915->mm.obj, as already documented in its declaration. * i915_gem_wait.c: The existing comment already mentioned that struct_mutex was no longer necessary. Updated to refer to a generic global lock instead. * intel_reset_types.h: Cleaned up the comment text. Updated to refer to a generic global lock instead. Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250908131518.36625-6-luiz.mello@estudante.ufscar.br Acked-by: Tvrtko Ursulin <tursulin@ursulin.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/i915: Replace struct_mutex in intel_guc_logLuiz Otavio Mello2-2/+11
Remove the use of struct_mutex from intel_guc_log.c and replace it with a dedicated lock, guc_lock, defined within the intel_guc_log struct.      The struct_mutex was previously used to protect concurrent access and modification of intel_guc_log->level in intel_guc_log_set_level(). However, it was suggested that the lock should reside within the intel_guc_log struct itself.      Initialize the new guc_lock in intel_guc_log_init_early(), alongside the existing relay.lock. The lock is initialized using drmm_mutex_init(), which also ensures it is properly destroyed when the driver is unloaded. Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br> Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250908131518.36625-5-luiz.mello@estudante.ufscar.br Acked-by: Tvrtko Ursulin <tursulin@ursulin.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/i915: Change mutex initialization in intel_guc_logLuiz Otavio Mello1-1/+6
The intel_guc_log->relay.lock is currently initialized in intel_guc_log_init_early(), but it lacks a corresponding destructor, which can lead to a memory leak. This patch replaces the use of mutex_init() with drmm_mutex_init(), which ensures the lock is properly destroyed when the driver is unloaded. Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250908131518.36625-4-luiz.mello@estudante.ufscar.br Acked-by: Tvrtko Ursulin <tursulin@ursulin.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/bridge: ite-it6263: Support HDMI vendor specific infoframeLiu Ying1-20/+44
IT6263 supports HDMI vendor specific infoframe. The infoframe header and payload are configurable via NULL packet registers. The infoframe is enabled and disabled via PKT_NULL_CTRL register. Add the HDMI vendor specific infoframe support. Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250908-it6263-vendor-specific-infoframe-v2-1-3f2ebd9135ad@nxp.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-09drm/bridge: write full Audio InfoFrameDmitry Baryshkov2-17/+24
Instead of writing the first byte of the infoframe (and hoping that the rest is default / zeroes), hook Audio InfoFrame support into the write_infoframe / clear_infoframes callbacks and use drm_atomic_helper_connector_hdmi_update_audio_infoframe() to write the frame. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250903-adv7511-audio-infoframe-v1-2-05b24459b9a4@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-09drm/bridge: adv7511: use update latch for AVI infoframesDmitry Baryshkov1-2/+13
Instead of disabling and then reenabling AVI infoframe, use the recommended way of updating it on the fly: latch current values using the ADV7511_REG_INFOFRAME_UPDATE register. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250903-adv7511-audio-infoframe-v1-1-05b24459b9a4@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-09drm/i915: Remove struct_mutex in i915_irq.cLuiz Otavio Mello1-6/+0
Remove struct_mutex from ivb_parity_work() function. The ivb_parity_work runs in a workqueue so it cannot race with itself. Also, it is not protecting anything with the other remaining usage of struct_mutex. Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br> Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250908131518.36625-3-luiz.mello@estudante.ufscar.br Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/i915: Move struct_mutex to drm_i915_privateLuiz Otavio Mello5-6/+17
Move legacy BKL struct_mutex from drm_device to drm_i915_private, which is the last remaining user. Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250908131518.36625-2-luiz.mello@estudante.ufscar.br Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/msm/mdp4: remove the use of dev_err_probe()Liao Yuanhong1-1/+1
Logging messages that show some type of "out of memory" error are generally unnecessary as there is a generic message and a stack dump done by the memory subsystem. These messages generally increase kernel size without much added value[1]. The dev_err_probe() doesn't do anything when error is '-ENOMEM'. Therefore, remove the useless call to dev_err_probe(), and just return the value instead. [1]: https://lore.kernel.org/lkml/1402419340.30479.18.camel@joe-AO725/ Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/670017/ Link: https://lore.kernel.org/r/20250820131300.499727-1-liaoyuanhong@vivo.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-09drm/msm/dpu: fix incorrect type for retQianfeng Rong1-1/+1
Change 'ret' from unsigned long to int, as storing negative error codes in an unsigned long makes it never equal to -ETIMEDOUT, causing logical errors. Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback") Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/671100/ Link: https://lore.kernel.org/r/20250826092047.224341-1-rongqianfeng@vivo.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-09drm/msm/a6xx: Add a comment to acd_probe()Akhil P Oommen1-0/+1
It is not obvious why we can skip error checking of dev_pm_opp_find_freq_exact() API. Add a comment explaining it. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/672263/ Link: https://lore.kernel.org/r/20250902-assorted-sept-1-v1-4-f3ec9baed513@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-09drm/msm/adreno: Add a modparam to skip GPUAkhil P Oommen1-0/+13
During bringup of a new GPU support, it is convenient to have knob to quickly disable GPU, but keep the display support. This helps to fallback to 'kms_swrast' in case of bootup issues due to GPU. Add a modparam to support this. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/672262/ Link: https://lore.kernel.org/r/20250902-assorted-sept-1-v1-3-f3ec9baed513@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-09drm/msm: Fix bootup splat with separate_gpu_drm modparamAkhil P Oommen1-0/+1
The drm_gem_for_each_gpuvm_bo() call from lookup_vma() accesses drm_gem_obj.gpuva.list, which is not initialized when the drm driver does not support DRIVER_GEM_GPUVA feature. Enable it for msm_kms drm driver to fix the splat seen when msm.separate_gpu_drm=1 modparam is set: [ 9.506020] Unable to handle kernel paging request at virtual address fffffffffffffff0 [ 9.523160] Mem abort info: [ 9.523161] ESR = 0x0000000096000006 [ 9.523163] EC = 0x25: DABT (current EL), IL = 32 bits [ 9.523165] SET = 0, FnV = 0 [ 9.523166] EA = 0, S1PTW = 0 [ 9.523167] FSC = 0x06: level 2 translation fault [ 9.523169] Data abort info: [ 9.523170] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 9.523171] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 9.523172] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 9.523174] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000ad370f000 [ 9.523176] [fffffffffffffff0] pgd=0000000000000000, p4d=0000000ad4787403, pud=0000000ad4788403, pmd=0000000000000000 [ 9.523184] Internal error: Oops: 0000000096000006 [#1] SMP [ 9.592968] CPU: 9 UID: 0 PID: 448 Comm: (udev-worker) Not tainted 6.17.0-rc4-assorted-fix-00005-g0e9bb53a2282-dirty #3 PREEMPT [ 9.592970] Hardware name: Qualcomm CRD, BIOS 6.0.240718.BOOT.MXF.2.4-00515-HAMOA-1 07/18/2024 [ 9.592971] pstate: a1400005 (NzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 9.592973] pc : lookup_vma+0x28/0xe0 [msm] [ 9.592996] lr : get_vma_locked+0x2c/0x128 [msm] [ 9.763632] sp : ffff800082dab460 [ 9.763666] Call trace: [ 9.763668] lookup_vma+0x28/0xe0 [msm] (P) [ 9.763688] get_vma_locked+0x2c/0x128 [msm] [ 9.763706] msm_gem_get_and_pin_iova_range+0x68/0x11c [msm] [ 9.763723] msm_gem_get_and_pin_iova+0x18/0x24 [msm] [ 9.763740] msm_fbdev_driver_fbdev_probe+0xd0/0x258 [msm] [ 9.763760] __drm_fb_helper_initial_config_and_unlock+0x288/0x528 [drm_kms_helper] [ 9.763771] drm_fb_helper_initial_config+0x44/0x54 [drm_kms_helper] [ 9.763779] drm_fbdev_client_hotplug+0x84/0xd4 [drm_client_lib] [ 9.763782] drm_client_register+0x58/0x9c [drm] [ 9.763806] drm_fbdev_client_setup+0xe8/0xcf0 [drm_client_lib] [ 9.763809] drm_client_setup+0xb4/0xd8 [drm_client_lib] [ 9.763811] msm_drm_kms_post_init+0x2c/0x3c [msm] [ 9.763830] msm_drm_init+0x1a8/0x22c [msm] [ 9.763848] msm_drm_bind+0x30/0x3c [msm] [ 9.919273] try_to_bring_up_aggregate_device+0x168/0x1d4 [ 9.919283] __component_add+0xa4/0x170 [ 9.919286] component_add+0x14/0x20 [ 9.919288] msm_dp_display_probe_tail+0x4c/0xac [msm] [ 9.919315] msm_dp_auxbus_done_probe+0x14/0x20 [msm] [ 9.919335] dp_aux_ep_probe+0x4c/0xf0 [drm_dp_aux_bus] [ 9.919341] really_probe+0xbc/0x298 [ 9.919345] __driver_probe_device+0x78/0x12c [ 9.919348] driver_probe_device+0x40/0x160 [ 9.919350] __driver_attach+0x94/0x19c [ 9.919353] bus_for_each_dev+0x74/0xd4 [ 9.919355] driver_attach+0x24/0x30 [ 9.919358] bus_add_driver+0xe4/0x208 [ 9.919360] driver_register+0x60/0x128 [ 9.919363] __dp_aux_dp_driver_register+0x24/0x30 [drm_dp_aux_bus] [ 9.919365] atana33xc20_init+0x20/0x1000 [panel_samsung_atna33xc20] [ 9.919370] do_one_initcall+0x6c/0x1b0 [ 9.919374] do_init_module+0x58/0x234 [ 9.919377] load_module+0x19cc/0x1bd4 [ 9.919380] init_module_from_file+0x84/0xc4 [ 9.919382] __arm64_sys_finit_module+0x1b8/0x2cc [ 9.919384] invoke_syscall+0x48/0x110 [ 9.919389] el0_svc_common.constprop.0+0xc8/0xe8 [ 9.919393] do_el0_svc+0x20/0x2c [ 9.919396] el0_svc+0x34/0xf0 [ 9.919401] el0t_64_sync_handler+0xa0/0xe4 [ 9.919403] el0t_64_sync+0x198/0x19c [ 9.919407] Code: eb0000bf 54000480 d100a003 aa0303e2 (f8418c44) [ 9.919410] ---[ end trace 0000000000000000 ]--- Fixes: 217ed15bd399 ("drm/msm: enable separate binding of GPU and display devices") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/672257/ Link: https://lore.kernel.org/r/20250902-assorted-sept-1-v1-1-f3ec9baed513@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-09drm/msm/dsi/phy: Fix reading zero as PLL rates when unpreparedKrzysztof Kozlowski2-0/+54
Hardware Programming Guide for DSI PHY says that PLL_SHUTDOWNB and DIGTOP_PWRDN_B have to be asserted for any PLL register access. Whenever dsi_pll_7nm_vco_recalc_rate() or dsi_pll_7nm_vco_set_rate() were called on unprepared PLL, driver read values of zero leading to all sort of further troubles, like failing to set pixel and byte clock rates. Asserting the PLL shutdown bit is done by dsi_pll_enable_pll_bias() (and corresponding dsi_pll_disable_pll_bias()) which are called through the code, including from PLL .prepare() and .unprepare() callbacks. The .set_rate() and .recalc_rate() can be called almost anytime from external users including times when PLL is or is not prepared, thus driver should not interfere with the prepare status. Implement simple reference counting for the PLL bias, so set_rate/recalc_rate will not change the status of prepared PLL. Issue of reading 0 in .recalc_rate() did not show up on existing devices, but only after re-ordering the code for SM8750. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/673416/ Link: https://lore.kernel.org/r/20250908094950.72877-2-krzysztof.kozlowski@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-09gpu: drm: display: drm_dp_cec: update Hans' email addressHans Verkuil1-1/+1
Replace hverkuil@xs4all.nl by hverkuil@kernel.org. Signed-off-by: Hans Verkuil <hverkuil@kernel.org> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2025-09-09drm/xe/hwmon: Use devm_mutex_init()Christophe JAILLET1-9/+1
Use devm_mutex_init() instead of hand-writing it. This saves some LoC, improves readability and saves some space in the generated .o file. Before: ====== text data bss dec hex filename 36884 10296 64 47244 b88c drivers/gpu/drm/xe/xe_hwmon.o After: ===== text data bss dec hex filename 36651 10224 64 46939 b75b drivers/gpu/drm/xe/xe_hwmon.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://lore.kernel.org/r/989e96369e9e1f8a44b816962917ec76877c912d.1757252520.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-09-09drm/xe/debugfs: Make residencies definitions constMichal Wajdeczko1-5/+5
No need to keep them non-const. Also fix declaration of .name member, as it points to the const string. This translates to: add/remove: 1/0 grow/shrink: 0/2 up/down: 80/-248 (-168) Function old new delta residencies - 80 +80 dgfx_pcie_link_residencies_show 365 263 -102 dgfx_pkg_residencies_show 454 308 -146 Total: Before=2821548, After=2821380, chg -0.01% Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Soham Purkait <soham.purkait@intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Karthik Poosa <karthik.poosa@intel.com> Cc: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250905180225.8434-1-michal.wajdeczko@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-09-09drm/xe/i2c: Enable bus masteringRaag Jadav1-1/+1
Enable bus mastering for I2C controller to support device initiated in-band transactions. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250908055320.2549722-1-raag.jadav@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-09-09drm/xe/vf: Move VF CCS debugfs attributeMichal Wajdeczko6-39/+67
The VF CCS handling is per-device so its debugfs file should not be exposed on per-GT basis. Move it up to the device level. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Link: https://lore.kernel.org/r/20250908123025.747-8-michal.wajdeczko@intel.com
2025-09-09drm/xe/vf: Move VF CCS data to xe_deviceMichal Wajdeczko6-25/+38
We only need single set of VF CCS contexts, they are not per-tile as initial implementation might suggest. Move all VF CCS data from xe_tile.sriov.vf to xe_device.sriov.vf. Also rename some structs to align with the usage and fix their kernel-doc. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Link: https://lore.kernel.org/r/20250908123025.747-7-michal.wajdeczko@intel.com
2025-09-09drm/xe/bo: Add xe_bo_has_valid_ccs_bb helperMichal Wajdeczko3-9/+16
This will allow as to drop ugly IS_VF_CCS_BB_VALID macro. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Link: https://lore.kernel.org/r/20250908123025.747-6-michal.wajdeczko@intel.com
2025-09-09drm/xe/vf: Use single check when calling VF CCS functionsMichal Wajdeczko6-17/+27
All xe_sriov_vf_ccs() functions but init() expect to be called when initialization was successful and CCS handling is ready. Update IS_VF_CCS_READY macro and use it as single entry guard. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Link: https://lore.kernel.org/r/20250908123025.747-5-michal.wajdeczko@intel.com
2025-09-09drm/xe/vf: Drop IS_VF_CCS_INIT_NEEDED macroMichal Wajdeczko2-7/+5
We only use this macro once and we can open-code it to explicitly show relevant conditions and avoid duplications. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Link: https://lore.kernel.org/r/20250908123025.747-4-michal.wajdeczko@intel.com
2025-09-09drm/xe/guc: Use proper flag definitions when registering contextMichal Wajdeczko2-4/+3
In H2G action context type is specified in flags dword in bits 2:1. Use generic FIELD_PREP macro instead of misleading BIT logic. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250908123025.747-3-michal.wajdeczko@intel.com
2025-09-09drm/xe/guc: Rename xe_guc_register_exec_queueMichal Wajdeczko3-10/+11
This function is dedicated for use by the VFs, we shouldn't use name that might suggests it's general purpose. While there, update asserts to better reflect intended usage. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Link: https://lore.kernel.org/r/20250908123025.747-2-michal.wajdeczko@intel.com
2025-09-09drm/gma500: Do not clear framebuffer GEM objects during cleanupThomas Zimmermann1-2/+0
Gma500 unnecessarily clears the framebuffer's GEM-object pointer before calling drm_framebuffer_cleanup(). Remove this code to make gma500 consistent with the rest of the drivers. The change is cosmetic, as drm_framebuffer_cleanup() does not touch the object pointer on gma500. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250904121157.395128-1-tzimmermann@suse.de
2025-09-09drm/i915/power: fix size for for_each_set_bit() in abox iterationJani Nikula1-3/+3
for_each_set_bit() expects size to be in bits, not bytes. The abox mask iteration uses bytes, but it works by coincidence, because the local variable holding the mask is unsigned long, and the mask only ever has bit 2 as the highest bit. Using a smaller type could lead to subtle and very hard to track bugs. Fixes: 62afef2811e4 ("drm/i915/rkl: RKL uses ABOX0 for pixel transfers") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: stable@vger.kernel.org # v5.9+ Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20250905104149.1144751-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 7ea3baa6efe4bb93d11e1c0e6528b1468d7debf6) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2025-09-09drm/i915/display: add intel_display_device_present()Jani Nikula7-34/+36
Add a proper function for display && HAS_DISPLAY(display) to hide indirect struct intel_display access via the macro from a number of places outside of display. This makes struct intel_display * an opaque pointer in these places. All HAS_DISPLAY() usage is now constrained within display. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250903090408.3492875-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-09drm/i915/backlight: Disable backlight when using luminance controlSuraj Kandpal1-3/+0
We just return when using luminance control instead we should be calling the disable helper to get everything cleaned up properly by default. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://lore.kernel.org/r/20250904044804.948391-1-suraj.kandpal@intel.com
2025-09-09drm/bridge: simple: add Realtek RTD2171 DP-to-HDMI bridgeNeil Armstrong1-0/+5
Add support for the transparent Realtek RTD2171 DP-to-HDMI bridge. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250908-topic-x1e80100-hdmi-v3-2-c53b0f2bc2fb@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-08rust: drm: gem: Simplify use of genericsLyude Paul1-5/+3
Now that my rust skills have been honed, I noticed that there's a lot of generics in our gem bindings that don't actually need to be here. Currently the hierarchy of traits in our gem bindings looks like this: * Drivers implement: * BaseDriverObject<T: DriverObject> (has the callbacks) * DriverObject (has the drm::Driver type) * Crate implements: * IntoGEMObject for Object<T> where T: DriverObject Handles conversion to/from raw object pointers * BaseObject for T where T: IntoGEMObject Provides methods common to all gem interfaces Also of note, this leaves us with two different drm::Driver associated types: * DriverObject::Driver * IntoGEMObject::Driver I'm not entirely sure of the original intent here unfortunately (if anyone is, please let me know!), but my guess is that the idea would be that some objects can implement IntoGEMObject using a different ::Driver than DriverObject - presumably to enable the usage of gem objects from different drivers. A reasonable usecase of course. However - if I'm not mistaken, I don't think that this is actually how things would go in practice. Driver implementations are of course implemented by their associated drivers, and generally drivers are not linked to each-other when building the kernel. Which is to say that even in a situation where we would theoretically deal with gem objects from another driver, we still wouldn't have access to its drm::driver::Driver implementation. It's more likely we would simply want a variant of gem objects in such a situation that have no association with a drm::driver::Driver type. Taking that into consideration, we can assume the following: * Anything that implements BaseDriverObject will implement DriverObject In other words, all BaseDriverObjects indirectly have an associated ::Driver type - so the two traits can be combined into one with no generics. * Not everything that implements IntoGEMObject will have an associated ::Driver, and that's OK. And with this, we now can do quite a bit of cleanup with the use of generics here. As such, this commit: * Removes the generics on BaseDriverObject * Moves DriverObject::Driver into BaseDriverObject * Removes DriverObject * Removes IntoGEMObject::Driver * Add AllocImpl::Driver, which we can use as a binding to figure out the correct File type for BaseObject Leaving us with a simpler trait hierarchy that now looks like this: * Drivers implement: BaseDriverObject * Crate implements: * IntoGEMObject for Object<T> where T: DriverObject * BaseObject for T where T: IntoGEMObject Which makes the code a lot easier to understand and build on :). Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250908185239.135849-2-lyude@redhat.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2025-09-08drm/panel-edp: Add 4 more panels needed by mt8189 ChromebooksZhongtian Wu1-0/+11
Add a few generic edp panels used by mt8189 chromebooks. For BOE-NV140WUM-N44 , the enable timing required 80ms. For CSW-MNE007QB3-1, the hpd_absent timing rquired 80ms, the enable timing required 50ms, the disable timing required 50ms. For CSW-MNE007QS3-6, the enable timing required 50ms. For CMN-N140JCA-ELK, the enable timing required 80ms and disable timing required 50ms. BOE NV140WUM-N44 V8.2 edid-decode (hex): 00 ff ff ff ff ff ff 00 09 e5 6a 0a 00 00 00 00 2e 20 01 04 a5 1e 13 78 03 fb f5 96 5d 5a 91 29 1e 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 61 40 80 04 71 b0 3c 40 30 20 36 00 2d bc 10 00 00 1a 81 33 80 04 71 b0 3c 40 30 20 36 00 2d bc 10 00 00 1a 00 00 00 fd 00 28 3c 4c 4c 10 01 0a 20 20 20 20 20 20 00 00 00 fe 00 4e 56 31 34 30 57 55 4d 2d 4e 34 34 0a 01 7c 02 03 0d 00 68 1a 00 00 01 01 28 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 CSW MNE007QB3-1: edid-decode (hex): 00 ff ff ff ff ff ff 00 0e 77 6e 14 00 00 00 00 00 23 01 04 a5 1e 13 78 07 ee 95 a3 54 4c 99 26 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 35 3c 80 a0 70 b0 23 40 30 20 36 00 2d bc 10 00 00 18 2b 30 80 a0 70 b0 23 40 30 20 36 00 2d bc 10 00 00 18 00 00 00 fd 00 28 3c 4a 4a 0f 01 0a 20 20 20 20 20 20 00 00 00 fc 00 4d 4e 45 30 30 37 51 42 33 2d 31 0a 20 01 69 70 20 79 02 00 21 00 1d c8 0b 5d 07 80 07 b0 04 00 3d 8a 54 cd a4 99 66 62 0f 02 45 54 40 5e 40 5e 00 44 12 78 2e 00 06 00 44 40 5e 40 5e 81 00 20 74 1a 00 00 03 01 28 3c 00 00 00 00 00 00 3c 00 00 00 00 8d 00 e3 05 04 00 e6 06 01 00 60 60 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 68 90 CSW MNE007QS3-6: edid-decode (hex): 00 ff ff ff ff ff ff 00 0e 77 3f 14 00 00 00 00 00 22 01 04 a5 1e 13 78 03 2c c5 94 5c 59 95 29 1e 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ea 3d 80 c8 70 b0 2e 40 30 20 36 00 2e bd 10 00 00 1a 88 31 80 c8 70 b0 2e 40 30 20 36 00 2e bd 10 00 00 1a 00 00 00 fd 00 28 3c 4b 4b 10 01 0a 20 20 20 20 20 20 00 00 00 fc 00 4d 4e 45 30 30 37 51 53 33 2d 36 0a 20 01 80 70 20 79 02 00 81 00 14 74 1a 00 00 03 01 28 3c 00 00 00 00 00 00 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9e 90 CMN N140JCA-ELK: edid-decode (hex): 00 ff ff ff ff ff ff 00 0d ae 41 14 00 00 00 00 25 21 01 04 a5 1e 13 78 03 28 65 97 59 54 8e 27 1e 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 42 3c 80 a0 70 b0 24 40 30 20 a6 00 2d bc 10 00 00 18 35 30 80 a0 70 b0 24 40 30 20 a6 00 2d bc 10 00 00 18 00 00 00 fd 00 28 3c 4b 4b 10 01 0a 20 20 20 20 20 20 00 00 00 fe 00 4e 31 34 30 4a 43 41 2d 45 4c 4b 0a 20 01 14 02 03 0d 00 68 1a 00 00 01 01 28 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Zhongtian Wu <wuzhongtian@huaqin.corp-partner.google.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250908063732.764289-1-wuzhongtian@huaqin.corp-partner.google.com
2025-09-08drm/amdgpu: Wait for bootloader after PSPv11 resetLijo Lazar1-15/+4
Some PSPv11 SOCs take a longer time for PSP based mode-1 reset. Instead of checking for C2PMSG_33 status, add the callback wait_for_bootloader. Wait for bootloader to be back to steady state is already part of the generic mode-1 reset flow. Increase the retry count for bootloader wait and also fix the mask to prevent fake pass. Fixes: 8345a71fc54b ("drm/amdgpu: Add more checks to PSP mailbox") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4531 Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 32f73741d6ee41fd5db8791c1163931e313d0fdc)
2025-09-08drm/xe/configfs: Use config_group_put()Lucas De Marchi1-1/+1
configfs has a config_group_put() helper that was adopted by commit 88df7939d728 ("drm/xe/configfs: Rename struct xe_config_device"). Another pending work to add psmi later landed in commit afe902848b41 ("drm/xe/configfs: Allow to enable PSMI") and didn't use the helper. Use config_group_put() consistently to hide the inner workings of configfs. No change in behavior since it does exactly the same thing as currently being done. Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20250905162236.578117-2-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-09-08drm/msm/a6xx: Enable IFPC on A750 GPUAkhil P Oommen1-1/+2
A750 GPU has similar IFPC related configurations like X1-85. Add the IFPC QUIRK to enable IFPC feature. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/673386/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-09-08drm/msm/a6xx: Enable IFPC on Adreno X1-85Akhil P Oommen3-5/+79
Add the IFPC restore register list and enable IFPC support on Adreno X1-85 gpu. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/673384/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-09-08drm/msm/a6xx: Make crashstate capture IFPC safeAkhil P Oommen3-11/+30
Now with IFPC, GX domain can collapse as soon as GPU becomes IDLE. So add gx_is_on check before accessing any GX registers during crashstate capture and recovery. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/673383/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-09-08drm/msm/adreno: Disable IFPC when sysprof is activeAkhil P Oommen6-0/+47
Moving to IFPC state clears the 'Perfcounter Select' register setup by the userspace. So, lets block the IFPC when sysprof is active by using the perfcounter oob signal to the GMU. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/673380/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-09-08drm/msm/a6xx: Fix hangcheck for IFPCAkhil P Oommen1-2/+13
From the hangcheck handler, KMD checks a few registers in GX domain to see if the GPU made any progress. But it cannot access those registers when IFPC is enabled. Since HW based hang detection is pretty decent, lets rely on it instead of these registers when IFPC is enabled. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/673378/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-09-08drm/msm: Add support for IFPCAkhil P Oommen3-8/+32
Add a new quirk to denote IFPC (Inter-Frame Power Collapse) support for a gpu. Based on this flag send the feature ctrl hfi message to GMU to enable IFPC support. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/673375/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-09-08drm/msm/a6xx: Poll AHB fence status in GPU IRQ handlerAkhil P Oommen2-0/+29
Even though the GX power domain is kept ON when there is a pending GPU interrupt, there is a small window of potential race with GMU where it may move the AHB fence to 'Drop' mode. Once the GMU sees the pending IRQ, it will move back the fence state to ALLOW mode. Close this race window by polling for AHB fence to ensure that it is in 'Allow' mode. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/673377/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-09-08drm/msm/a6xx: Switch to GMU AO counterAkhil P Oommen1-14/+16
CP_ALWAYS_ON counter falls under GX domain which is collapsed during IFPC. So switch to GMU_ALWAYS_ON counter for any CPU reads since it is not impacted by IFPC. Both counters are clocked by same xo clock source. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/673373/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-09-08drm/msm/a6xx: Set Keep-alive votes to block IFPCAkhil P Oommen2-9/+37
Set Keepalive votes at appropriate places to block IFPC power collapse until we access all the required registers. This is required during gpu IRQ handling and also during preemption. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/673369/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-09-08drm/msm/adreno: Add fenced regwrite supportAkhil P Oommen3-11/+90
There are some special registers which are accessible even when GX power domain is collapsed during an IFPC sleep. Accessing these registers wakes up GPU from power collapse and allow programming these registers without additional handshake with GMU. This patch adds support for this special register write sequence. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/673368/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-09-08drm/msm: Add an ftrace for gpu register accessAkhil P Oommen2-0/+20
With IFPC, there is a probability of accessing a GX domain register when it is collapsed, which leads to gmu fence errors. To debug this, we need to trace every gpu register accesses and identify the one just before a gmu fence error. So, add an ftrace to track all gpu register accesses. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/673366/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-09-08drm/msm: a6xx: Refactor a6xx_sptprac_enable()Akhil P Oommen2-4/+7
A minor refactor to combine the subroutines for legacy a6xx GMUs under a single check. This helps to avoid an unnecessary check and return early from the subroutine for majority of a6xx gpus. Also, document an intermediate unknown low power state which is not exposed by the GMU firmware. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/673364/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-09-08drm/msm/a6xx: Fix PDC sleep sequenceAkhil P Oommen2-11/+23
Since the PDC resides out of the GPU subsystem and cannot be reset in case it enters bad state, utmost care must be taken to trigger the PDC wake/sleep routines in the correct order. The PDC wake sequence can be exercised only after a PDC sleep sequence. Additionally, GMU firmware should initialize a few registers before the KMD can trigger a PDC sleep sequence. So PDC sleep can't be done if the GMU firmware has not initialized. Track these dependencies using a new status variable and trigger PDC sleep/wake sequences appropriately. Cc: stable@vger.kernel.org Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/673362/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-12-26 09:02:40 +0000