summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-02-26drm/xe/pf: Don't force 2MB VRAM alignmentMichal Wajdeczko
There is no need to always request VRAM BO to have 2MB alignment as for now this is required by the LMTT only, which could be not present on some platforms with VRAM. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260221152230.7071-3-michal.wajdeczko@intel.com
2026-02-26drm/xe/pf: Use explicit VRAM BO flag for VRAM provisioningMichal Wajdeczko
When we are about to provision VRAM/LMEM for VF, there is no point in using semi-automatic flag that supports fallback to the SMEM. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260221152230.7071-2-michal.wajdeczko@intel.com
2026-02-25drm/amd: Disable MES LR compute W/AMario Limonciello
A workaround was introduced in commit 1fb710793ce2 ("drm/amdgpu: Enable MES lr_compute_wa by default") to help with some hangs observed in gfx1151. This WA didn't fully fix the issue. It was actually fixed by adjusting the VGPR size to the correct value that matched the hardware in commit b42f3bf9536c ("drm/amdkfd: bump minimum vgpr size for gfx1151"). There are reports of instability on other products with newer GC microcode versions, and I believe they're caused by this workaround. As we don't need the workaround any more, remove it. Fixes: b42f3bf9536c ("drm/amdkfd: bump minimum vgpr size for gfx1151") Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 9973e64bd6ee7642860a6f3b6958cbf14e89cabd) Cc: stable@vger.kernel.org
2026-02-25drm/amdgpu: Fix error handling in slot resetLijo Lazar
If the device has not recovered after slot reset is called, it goes to out label for error handling. There it could make decision based on uninitialized hive pointer and could result in accessing an uninitialized list. Initialize the list and hive properly so that it handles the error situation and also releases the reset domain lock which is acquired during error_detected callback. Fixes: 732c6cefc1ec ("drm/amdgpu: Replace tmp_adev with hive in amdgpu_pci_slot_reset") Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Ce Sun <cesun102@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit bb71362182e59caa227e4192da5a612b09349696)
2026-02-25drm/amdgpu/vcn5: Add SMU dpm interface typesguttula
This will set AMDGPU_VCN_SMU_DPM_INTERFACE_* smu_type based on soc type and fixing ring timeout issue seen for DPM enabled case. Signed-off-by: sguttula <suresh.guttula@amd.com> Reviewed-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f0f23c315b38c55e8ce9484cf59b65811f350630)
2026-02-25drm/amdgpu: Fix locking bugs in error pathsBart Van Assche
Do not unlock psp->ras_context.mutex if it has not been locked. This has been detected by the Clang thread-safety analyzer. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: YiPeng Chai <YiPeng.Chai@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Cc: amd-gfx@lists.freedesktop.org Fixes: b3fb79cda568 ("drm/amdgpu: add mutex to protect ras shared memory") Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 6fa01b4335978051d2cd80841728fd63cc597970)
2026-02-25drm/amdgpu: Unlock a mutex before destroying itBart Van Assche
Mutexes must be unlocked before these are destroyed. This has been detected by the Clang thread-safety analyzer. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Yang Wang <kevinyang.wang@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Cc: amd-gfx@lists.freedesktop.org Fixes: f5e4cc8461c4 ("drm/amdgpu: implement RAS ACA driver framework") Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 270258ba320beb99648dceffb67e86ac76786e55)
2026-02-25drm/amd/display: Use GFP_ATOMIC in dc_create_stream_for_sinkNatalie Vock
This can be called while preemption is disabled, for example by dcn32_internal_validate_bw which is called with the FPU active. Fixes "BUG: scheduling while atomic" messages I encounter on my Navi31 machine. Signed-off-by: Natalie Vock <natalie.vock@gmx.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit b42dae2ebc5c84a68de63ec4ffdfec49362d53f1) Cc: stable@vger.kernel.org
2026-02-25drm/amdgpu: add upper bound check on user inputs in wait ioctlSunil Khatri
Huge input values in amdgpu_userq_wait_ioctl can lead to a OOM and could be exploited. So check these input value against AMDGPU_USERQ_MAX_HANDLES which is big enough value for genuine use cases and could potentially avoid OOM. v2: squash in Srini's fix Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit fcec012c664247531aed3e662f4280ff804d1476) Cc: stable@vger.kernel.org
2026-02-25drm/amdgpu: add upper bound check on user inputs in signal ioctlSunil Khatri
Huge input values in amdgpu_userq_signal_ioctl can lead to a OOM and could be exploited. So check these input value against AMDGPU_USERQ_MAX_HANDLES which is big enough value for genuine use cases and could potentially avoid OOM. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit be267e15f99bc97cbe202cd556717797cdcf79a5) Cc: stable@vger.kernel.org
2026-02-25drm/amdgpu/userq: Do not allow userspace to trivially triger kernel warningsTvrtko Ursulin
Userspace can either deliberately pass in the too small num_fences, or the required number can legitimately grow between the two calls to the userq wait ioctl. In both cases we do not want the emit the kernel warning backtrace since nothing is wrong with the kernel and userspace will simply get an errno reported back. So lets simply drop the WARN_ONs. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: a292fdecd728 ("drm/amdgpu: Implement userqueue signal/wait IOCTL") Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 2c333ea579de6cc20ea7bc50e9595ef72863e65c)
2026-02-25drm/amdgpu/userq: Fix reference leak in amdgpu_userq_wait_ioctlTvrtko Ursulin
Drop reference to syncobj and timeline fence when aborting the ioctl due output array being too small. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: a292fdecd728 ("drm/amdgpu: Implement userqueue signal/wait IOCTL") Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 68951e9c3e6bb22396bc42ef2359751c8315dd27) Cc: <stable@vger.kernel.org> # v6.16+
2026-02-25drm/amd: Disable MES LR compute W/AMario Limonciello
A workaround was introduced in commit 1fb710793ce2 ("drm/amdgpu: Enable MES lr_compute_wa by default") to help with some hangs observed in gfx1151. This WA didn't fully fix the issue. It was actually fixed by adjusting the VGPR size to the correct value that matched the hardware in commit b42f3bf9536c ("drm/amdkfd: bump minimum vgpr size for gfx1151"). There are reports of instability on other products with newer GC microcode versions, and I believe they're caused by this workaround. As we don't need the workaround any more, remove it. Fixes: b42f3bf9536c ("drm/amdkfd: bump minimum vgpr size for gfx1151") Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amdgpu: Fix error handling in slot resetLijo Lazar
If the device has not recovered after slot reset is called, it goes to out label for error handling. There it could make decision based on uninitialized hive pointer and could result in accessing an uninitialized list. Initialize the list and hive properly so that it handles the error situation and also releases the reset domain lock which is acquired during error_detected callback. Fixes: 732c6cefc1ec ("drm/amdgpu: Replace tmp_adev with hive in amdgpu_pci_slot_reset") Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Ce Sun <cesun102@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amd/ras: Handle check address validity in SR-IOVJinzhou Su
Handle check address validity command in SR-IOV guest. Signed-off-by: Jinzhou Su <jinzhou.su@amd.com> Reviewed-by: YiPeng Chai <YiPeng.Chai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amdgpu/vcn5: Add SMU dpm interface typesguttula
This will set AMDGPU_VCN_SMU_DPM_INTERFACE_* smu_type based on soc type and fixing ring timeout issue seen for DPM enabled case. Signed-off-by: sguttula <suresh.guttula@amd.com> Reviewed-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amd/ras: Add function to convert retired addressJinzhou Su
Add function to convert retired address in SR-IOV guest. Signed-off-by: Jinzhou Su <jinzhou.su@amd.com> Reviewed-by: YiPeng Chai <YiPeng.Chai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amd/ras: Handle address check in SR-IOV guestJinzhou Su
Handle address check validity command in SR-IOV guest Signed-off-by: Jinzhou Su <jinzhou.su@amd.com> Reviewed-by: YiPeng Chai <YiPeng.Chai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amd/ras: Add convert retired address structureJinzhou Su
Add convert retired address command and structure for uniras. Signed-off-by: Jinzhou Su <jinzhou.su@amd.com> Reviewed-by: YiPeng Chai <YiPeng.Chai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amd/ras: Add address check structureJinzhou Su
Add address check command and data structure for uniras. Signed-off-by: Jinzhou Su <jinzhou.su@amd.com> Reviewed-by: YiPeng Chai <YiPeng.Chai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amdgpu: Fix locking bugs in error pathsBart Van Assche
Do not unlock psp->ras_context.mutex if it has not been locked. This has been detected by the Clang thread-safety analyzer. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: YiPeng Chai <YiPeng.Chai@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Cc: amd-gfx@lists.freedesktop.org Fixes: b3fb79cda568 ("drm/amdgpu: add mutex to protect ras shared memory") Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amdgpu: Unlock a mutex before destroying itBart Van Assche
Mutexes must be unlocked before these are destroyed. This has been detected by the Clang thread-safety analyzer. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Yang Wang <kevinyang.wang@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Cc: amd-gfx@lists.freedesktop.org Fixes: f5e4cc8461c4 ("drm/amdgpu: implement RAS ACA driver framework") Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amd/display: Use GFP_ATOMIC in dc_create_stream_for_sinkNatalie Vock
This can be called while preemption is disabled, for example by dcn32_internal_validate_bw which is called with the FPU active. Fixes "BUG: scheduling while atomic" messages I encounter on my Navi31 machine. Signed-off-by: Natalie Vock <natalie.vock@gmx.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amdgpu: add upper bound check on user inputs in wait ioctlSunil Khatri
Huge input values in amdgpu_userq_wait_ioctl can lead to a OOM and could be exploited. So check these input value against AMDGPU_USERQ_MAX_HANDLES which is big enough value for genuine use cases and could potentially avoid OOM. v2: squash in Srini's fix Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amdgpu: add upper bound check on user inputs in signal ioctlSunil Khatri
Huge input values in amdgpu_userq_signal_ioctl can lead to a OOM and could be exploited. So check these input value against AMDGPU_USERQ_MAX_HANDLES which is big enough value for genuine use cases and could potentially avoid OOM. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amdgpu/userq: Use drm_gem_objects_lookup in amdgpu_userq_wait_ioctlTvrtko Ursulin
Use the existing helper instead of open coding it Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Sunil Khatri <sunil.khatrti@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amdgpu/userq: Use drm_gem_objects_lookup in amdgpu_userq_signal_ioctlTvrtko Ursulin
Use the existing helper instead of open coding it. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Sunil Khatri <sunil.khatrti@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amd/ras: use dedicated memory as vf ras command bufferYiPeng Chai
Use dedicated memory as vf ras command buffer. V2: Add lock to ensure serialization of sending vf ras commands. Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by: Jinzhou Su <jinzhou.su@amd.com> Tested-by: Jinzhou Su <jinzhou.su@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amdkfd: Removed commented line for MQD queue priorityAndrew Martin
Missed deleting the commented line in the original patch. Fixes: 73463e26f7e2 ("drm/amdkfd: Disable MQD queue priority") Signed-off-by: Andrew Martin <andrew.martin@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amdgpu/userq: Consolidate wait ioctl exit pathTvrtko Ursulin
If we gate the fence destruction with a check telling us whether there are valid pointers in there we can eliminate the need for dual, basically identical, exit paths. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amdgpu/userq: Do not allow userspace to trivially triger kernel warningsTvrtko Ursulin
Userspace can either deliberately pass in the too small num_fences, or the required number can legitimately grow between the two calls to the userq wait ioctl. In both cases we do not want the emit the kernel warning backtrace since nothing is wrong with the kernel and userspace will simply get an errno reported back. So lets simply drop the WARN_ONs. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: a292fdecd728 ("drm/amdgpu: Implement userqueue signal/wait IOCTL") Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amdgpu/userq: Fix reference leak in amdgpu_userq_wait_ioctlTvrtko Ursulin
Drop reference to syncobj and timeline fence when aborting the ioctl due output array being too small. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: a292fdecd728 ("drm/amdgpu: Implement userqueue signal/wait IOCTL") Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/xe/guc: Refine CT queue checks and log formattingShuicheng Lin
Fix three code-level cleanups in xe_guc_ct.c: - Use SZ_4K for the queue size alignment assertion in xe_guc_ct_queue_proc_time_jiffies(). - Drop an unused local variable in guc_ct_send_wait_for_retry(). - Add missing trailing newlines in CT error/warn log messages. These changes keep behavior unchanged while improving correctness checks and log formatting. Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260223162350.3205364-6-shuicheng.lin@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-25drm/xe/guc: Accumulate CT H2G retry sleep budgetShuicheng Lin
guc_ct_send_wait_for_retry() introduced sleep_total_ms as a budget guard, but never incremented it. As a result, the "about 1 second" bailout condition never triggers in the H2G backpressure path. Accumulate the delay returned by xe_sleep_exponential_ms() into sleep_total_ms so the timeout logic works as intended. Fixes: 943c4d0637cf ("drm/xe/guc: Limit sleep while waiting for H2G credits") Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260223162350.3205364-5-shuicheng.lin@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-25drm/xe/compat: Remove unused i915_reg.h from compat headerUma Shankar
Display Code is made independent of i915_reg.h, hence it can be dropped from compat header. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260223171015.1035550-1-uma.shankar@intel.com
2026-02-25drm/i915/dp_tunnel: Send BW change notification after tunnel creationImre Deak
Detecting a bandwidth change for a sink connected through a DP tunnel depends on updating the sink's DPRX link rate and lane count. detect_new_tunnel() -> update_tunnel_state() updates the link configuration only if the tunnel state changes. However, after the tunnel is created and bandwidth allocation mode is enabled, the tunnel state itself may remain unchanged. Record the sink bandwidth before creating the tunnel and compare it to the bandwidth after tunnel creation and enabling bandwidth allocation mode, ensuring that any bandwidth change is detected and userspace is notified accordingly. Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260219182823.926702-6-imre.deak@intel.com
2026-02-25drm/i915/dp_tunnel: Sanitize documentation of intel_dp_tunnel_detect()Imre Deak
Clarify the documentation of detect_new_tunnel() return values, including the failure case. Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260219182823.926702-5-imre.deak@intel.com
2026-02-25drm/i915/dp_tunnel: Split update_tunnel_state()Imre Deak
Split update_tunnel_state() into two helpers: one that updates the tunnel state, and another that detects whether the tunnel bandwidth has changed. This prepares for a follow-up change that needs to compare the current bandwidth against the value from before the DP tunnel was detected and bandwidth allocation mode was enabled. While at it, document the return value of update_tunnel_state(). Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260219182823.926702-4-imre.deak@intel.com
2026-02-25drm/i915/dp_tunnel: Simplify detection of link BW changeImre Deak
update_tunnel_state() checks whether a tunnel state change (e.g. available tunnel bandwidth) affects the list of valid modes for the sink connected through the tunnel. If so, its caller sends a hotplug event so userspace can re-enumerate the modes. A change in tunnel bandwidth does not affect the mode list if the bandwidth was above the sink's DPRX bandwidth both before and after the update, since in that case the effective bandwidth remains limited by the DPRX. As get_current_link_bw() via intel_dp_max_link_data_rate() already returns bandwidth values clamped to the DPRX limit, the condition for detecting a mode list change can be simplified to: old_bw != new_bw Remove the explicit checks for whether the bandwidth was below the maximum DPRX bandwidth before and after the update, and rely on the clamped bandwidth values instead. Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260219182823.926702-3-imre.deak@intel.com
2026-02-25drm/i915/dp_tunnel: Don't update tunnel state during system resumeImre Deak
During system resume, restoring the pre-suspend display state must not fail. This requires preserving the sink capabilities from before suspend, including the available link bandwidth. If these capabilities are not preserved, the restore modeset may fail, either due to a missing sink capability or insufficient link bandwidth for the restored mode. When the sink is connected through a DP tunnel, prevent such capability changes by skipping tunnel state updates during resume. This also avoids updating the sink state via the tunnel while it is being resumed. Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260219182823.926702-2-imre.deak@intel.com
2026-02-25drm/i915/fbdev: print info about stolen memory preference for fbdevVinod Govindapillai
If stolen memory cannot be allocated for the fbdev because of the preference for fbc, have an info about that in the log. v2: log text changed Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Mika Kahola <mika.kahola@intel.com> Link: https://patch.msgid.link/20260220170908.201422-7-vinod.govindapillai@intel.com
2026-02-25drm/xe/fbdev: print info about stolen memory preference for fbdevVinod Govindapillai
If stolen memory cannot be allocated for the fbdev and initial plane bo because of the preference for fbc, have an info about that in the log. v2: log text changed Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Mika Kahola <mika.kahola@intel.com> Link: https://patch.msgid.link/20260220170908.201422-6-vinod.govindapillai@intel.com
2026-02-25drm/xe/fbdev: Extract intel_fbdev_fb_prefer_stolen()Ville Syrjälä
Pull the "should we keep the bios fb in stolen?" logic into into a helper function, same as was done for i915. Gives us a single place where to tweak the heuristics. v2: changes related to rebase and consolidated other conditions for the stolen preference into this single function (Vinod) v3: avoid including intel_display_core.h (Jani Nikula) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Mika Kahola <mika.kahola@intel.com> Link: https://patch.msgid.link/20260220170908.201422-5-vinod.govindapillai@intel.com
2026-02-25drm/i915/fbdev: Extract intel_fbdev_fb_prefer_stolen()Ville Syrjälä
Consolidate the "should we allocate fbdev fb in stolen?" check into a helper function. Makes it easier to change the heuristics without having to change so many places. v2: rebase related changes and consolidate all the prefer stolen conditions into a single function (Vinod) v3: avoid including intel_display_core.h (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Mika Kahola <mika.kahola@intel.com> Link: https://patch.msgid.link/20260220170908.201422-4-vinod.govindapillai@intel.com
2026-02-25drm/i915/display: remove the usage of dev_privVinod Govindapillai
Remove the remaining usage of dev_priv in intel_fbdev_fb.c and use i915 instead. Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patch.msgid.link/20260220170908.201422-3-vinod.govindapillai@intel.com
2026-02-25drm/xe/fbdev: Fix BIOS FB vs. stolen size checkVille Syrjälä
Looks like stolen->size is in bytes, not pages. Remove the bogus PAGE_SHIFT stuff. Also for some random reason xe rejects the FB if it takes up exactly half of stolen, whereas i915 allows it to be used in that case. Adjust xe to follow the i915 rule for consistency. v2: rebase related updates Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Mika Kahola <mika.kahola@intel.com> Link: https://patch.msgid.link/20260220170908.201422-2-vinod.govindapillai@intel.com
2026-02-25Merge drm/drm-next into drm-intel-nextJani Nikula
Sync with v7.0-rc1 which contains a few treewide changes affecting i915. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-25drm/client: Do not destroy NULL modesJonathan Cavitt
'modes' in drm_client_modeset_probe may fail to kcalloc. If this occurs, we jump to 'out', calling modes_destroy on it, which dereferences it. This may result in a NULL pointer dereference in the error case. Prevent that. Fixes: 3039cc0c0653 ("drm/client: Make copies of modes") Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260224221227.69126-2-jonathan.cavitt@intel.com
2026-02-25drm: atmel-hlcdc: add LCD controller layer definition for sama7d65Ryan Wanner
Add the LCD controller layer definition and atmel_hlcdc_of_match entry for sama7d65. Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://patch.msgid.link/20251218040521.463937-3-manikandan.m@microchip.com Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
2026-02-25drm/bridge: imx8qxp-pixel-link: get/put the next bridgeLuca Ceresoli
This driver obtains a bridge pointer from of_drm_find_bridge() in the probe function and stores it until driver removal. of_drm_find_bridge() is deprecated, so move to of_drm_find_and_get_bridge() for the bridge to be refcounted and use bridge->next_bridge to put the reference on deallocation. To keep the code as simple and reliable as possible remove the intermediate next_bridge and selected_bridge variables. Get/put operations on the remaining pointer is pl->bridge.next_bridge, which is tied to the struct imx8qxp_pixel_link lifetime, are: - get reference when assigned (by of_drm_find_and_get_bridge()) - put reference before reassignment if reassignment happens - put reference when the struct imx8qxp_pixel_link embedding the struct drm_bridge is destroyed (struct drm_bridge::next_bridge) Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Acked-by: Liu Ying <victor.liu@nxp.com> Signed-off-by: Liu Ying <victor.liu@nxp.com> Link: https://lore.kernel.org/r/20260211-drm-bridge-alloc-getput-drm_of_find_bridge-v6-1-651ddfd13bdb@bootlin.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-06-09 10:13:45 +0000