summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2025-10-28drm/amd/display: Fix notification of vtotal to DMU for cursor offloadNicholas Kazlauskas1-3/+4
[Why] It was placed after the early return and the notification is never sent. [How] Place it after .set_drr and before the return. Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Wayne Lin <wayne.lin@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amd/display: Fix wrong index for DCN401 cursor offloadNicholas Kazlauskas1-1/+1
[Why] Payloads are ignored because the wrong index is written as part of the pipe update implementation for DCN401. [How] Align it to the DCN35 implementation and ensure the + 1 is added. Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Wayne Lin <wayne.lin@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amd/display: Add opp count validation to dml2.1Dmytro Laktyushkin3-3/+28
Newer asics can have mismatching dpp and opp counts and dml needs to account for this. Reviewed-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com> Signed-off-by: Wayne Lin <wayne.lin@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amd/display: Fix DMUB reset sequence for DCN32Dillon Varone2-22/+45
[WHY&HOW] Backport reset sequence fixes implemented on DCN401 to DCN32 to address stability issues when resetting the DMUB. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Dillon Varone <Dillon.Varone@amd.com> Signed-off-by: Wayne Lin <wayne.lin@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amd/display: Bump minimum for frame_warn_limitMario Limonciello1-1/+1
[Why] The bigger of CONFIG_FRAME_WARN and frame_warn_limit is used to trigger warnings about large stack frames. The dml_core_mode_support() stack frame has grown to 2056. [How] Update frame_warn_limit to 2056 so that CONFIG_FRAME_WARN of 2048 doesn't cause a failure. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4609 Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Mario Limonciello <superm1@kernel.org> Signed-off-by: Wayne Lin <wayne.lin@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amd: Re-introduce property to control adaptive backlight modulationMario Limonciello5-3/+106
commit 0887054d14ae ("drm/amd: Drop abm_level property") dropped the abm level property in favor of sysfs control. Since then there have been discussions that compositors showed an interest in modifying a vendor specific property instead. So re-introduce the abm level property, but with different semantics. Rather than being an integer it's now an enum. One of the enum options is 'sysfs', and that is because there is still a sysfs file for use by userspace when the compositor doesn't support this property. If usespace has not modified this property, the default value will be for sysfs to control it. Once userspace has set the property stop allowing sysfs control. The property is only attached to non-OLED eDP panels. Cc: Xaver Hugl <xaver.hugl@kde.org> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amdgpu: Fix pointer casts when reading dynamic region sizesSrinivasan Shanmugam4-5/+5
The function amdgpu_virt_get_dynamic_data_info() writes a 64-bit size value. In two places (amdgpu_bios.c and amdgpu_discovery.c), the code passed the address of a smaller variable by casting it to u64 *, which is unsafe. This could make the function write more bytes than the smaller variable can hold, possibly overwriting nearby memory. Reported by static analysis tools. v2: Dynamic region size comes from the host (SR-IOV setup) and is always fixed to 5 MB. (Lijo/Ellen) 5 MB easily fits inside a 32-bit value, so using a 64-bit type is not needed. It also avoids extra type casts Fixes: b4a8fcc7826a ("drm/amdgpu: Add logic for VF ipd and VF bios to init from dynamic crit_region offsets") Reported by: Dan Carpenter <dan.carpenter@linaro.org> Cc: Ellen Pan <yunru.pan@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amdgpu: null check for hmm_pfns ptr before freeing itSunil Khatri1-1/+3
Due to low memory or when num of pages is too big to be accomodated, allocation could fail for pfn's. Chekc hmm_pfns for NULL before calling the kvfree for the it. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Acked-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amd/pm: smu13: Enable VCN_RESET for pgm 7 with appropriate firmware versionJesse.Zhang1-1/+2
This patch extends the VCN_RESET capability check to include pgm 7 when the firmware version is 0x07551400 or newer. Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amdgpu: Make SR-IOV critical region checks overflow-safeSrinivasan Shanmugam1-4/+5
The function amdgpu_virt_init_critical_region() contained an invalid check for a negative init_hdr_offset value: if (init_hdr_offset < 0) Since init_hdr_offset is an unsigned 32-bit integer, this condition can never be true and triggers a Smatch warning: warn: unsigned 'init_hdr_offset' is never less than zero In addition, the subsequent bounds check: if ((init_hdr_offset + init_hdr_size) > vram_size) was vulnerable to integer overflow when adding the two unsigned values. Thus, by promoting offset and size to 64-bit and using check_add_overflow() to safely validate the sum against VRAM size. Fixes: 07009df6494d ("drm/amdgpu: Introduce SRIOV critical regions v2 during VF init") Reported by: Dan Carpenter <dan.carpenter@linaro.org> Cc: Ellen Pan <yunru.pan@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Ellen Pan <yunru.pan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amdgpu: fix SPDX header on cyan_skillfish_reg_init.cAlex Deucher1-1/+1
This should be MIT. The driver in general is MIT and the license text at the top of the file is MIT so fix it. Fixes: e8529dbc75ca ("drm/amdgpu: add ip offset support for cyan skillfish") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4654 Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amdgpu: fix SPDX header on irqsrcs_vcn_5_0.hAlex Deucher1-1/+1
This should be MIT. The driver in general is MIT and the license text at the top of the file is MIT so fix it. Fixes: d1bb64651095 ("drm/amdgpu: add irq source ids for VCN5_0/JPEG5_0") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4654 Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amdgpu: fix SPDX header on amd_cper.hAlex Deucher1-1/+1
This should be MIT. The driver in general is MIT and the license text at the top of the file is MIT so fix it. Fixes: 523b69c65445 ("drm/amd/include: Add amd cper header") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4654 Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amdgpu: fix SPDX headers on amdgpu_cper.c/hAlex Deucher2-2/+2
These should be MIT. The driver in general is MIT and the license text at the top of the files is MIT so fix it. Fixes: 92d5d2a09de1 ("drm/amdgpu: Introduce funcs for populating CPER") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4654 Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amdgpu/userqueue: Fix use after free in ↵Dan Carpenter1-1/+1
amdgpu_userq_buffer_vas_list_cleanup() The amdgpu_userq_buffer_va_list_del() function frees "va_cursor" but it is dereferenced on the next line when we print the debug message. Print the debug message first and then free it. Fixes: 2a28f9665dca ("drm/amdgpu: track the userq bo va for its obj management") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on IcelandJohn Smith1-1/+1
Previously this was initialized with zero which represented PCIe Gen 1.0 instead of using the maximum value from the speed table which is the behaviour of all other smumgr implementations. Fixes: 18aafc59b106 ("drm/amd/powerplay: implement fw related smu interface for iceland.") Signed-off-by: John Smith <itistotalbotnet@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on FijiJohn Smith1-1/+1
Previously this was initialized with zero which represented PCIe Gen 1.0 instead of using the maximum value from the speed table which is the behaviour of all other smumgr implementations. Fixes: 18edef19ea44 ("drm/amd/powerplay: implement fw image related smu interface for Fiji.") Signed-off-by: John Smith <itistotalbotnet@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amd/pm: fix smu table id bound check issue in smu_cmn_update_table()Yang Wang1-1/+1
'table_index' is a variable defined by the smu driver (kmd) 'table_id' is a variable defined by the hw smu (pmfw) This code should use table_index as a bounds check. Fixes: caad2613dc4bd ("drm/amd/powerplay: move table setting common code to smu_cmn.c") Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amd/display: Don't program BLNDGAM_MEM_PWR_FORCE when CM low-power is ↵Matthew Schwartz1-3/+0
disabled on DCN30 Before commit 33056a97ae5e ("drm/amd/display: Remove double checks for `debug.enable_mem_low_power.bits.cm`"), dpp3_program_blnd_lut(NULL) checked the low-power debug flag before calling dpp3_power_on_blnd_lut(false). After commit 33056a97ae5e ("drm/amd/display: Remove double checks for `debug.enable_mem_low_power.bits.cm`"), dpp3_program_blnd_lut(NULL) unconditionally calls dpp3_power_on_blnd_lut(false). The BLNDGAM power helper writes BLNDGAM_MEM_PWR_FORCE when CM low-power is disabled, causing immediate SRAM power toggles instead of deferring at vupdate. This can disrupt atomic color/LUT sequencing during transitions between direct scanout and composition within gamescope's DRM backend on Steam Deck OLED. To fix this, leave the BLNDGAM power state unchanged when low-power is disabled, matching dpp3_power_on_hdr3dlut and dpp3_power_on_shaper. Fixes: 33056a97ae5e ("drm/amd/display: Remove double checks for `debug.enable_mem_low_power.bits.cm`") Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amdgpu: Add uniras version in sysfsJinzhou Su1-1/+31
Display uniras version in sysfs version interface when uniras enable. v2: display ras version detail info Signed-off-by: Jinzhou Su <jinzhou.su@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amdgpu: get rev_id from strap register or IP-discovery tablePerry Yuan2-11/+17
Query the sub-revision field in the IP Discovery table for the VFs to obtain their revision ID. Meanwhile, read the revision ID from the strap register for the PF. Signed-off-by: Perry Yuan <perry.yuan@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amdgpu: clear bad page info of ras moduleJinzhou Su1-0/+22
Clear bad page info of ras module. Signed-off-by: Jinzhou Su <jinzhou.su@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amd/display: pause the workload setting in dmKenneth Feng1-0/+11
v1: Pause the workload setting in dm when doinn idle optimization v2: Rebase patch to latest kernel code base (kernel 6.16) Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/radeon: Remove calls to drm_put_dev()Daniel Palmer1-21/+4
Since the allocation of the drivers main structure was changed to devm_drm_dev_alloc() drm_put_dev()'ing to trigger it to be free'd should be done by devres. However, drm_put_dev() is still in the probe error and device remove paths. When the driver fails to probe warnings like the following are shown because devres is trying to drm_put_dev() after the driver already did it. [ 5.642230] radeon 0000:01:05.0: probe with driver radeon failed with error -22 [ 5.649605] ------------[ cut here ]------------ [ 5.649607] refcount_t: underflow; use-after-free. [ 5.649620] WARNING: CPU: 0 PID: 357 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110 Fixes: a9ed2f052c5c ("drm/radeon: change drm_dev_alloc to devm_drm_dev_alloc") Signed-off-by: Daniel Palmer <daniel@0x0f.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/radeon: Do not kfree() devres managed rdevDaniel Palmer1-1/+0
Since the allocation of the drivers main structure was changed to devm_drm_dev_alloc() rdev is managed by devres and we shouldn't be calling kfree() on it. This fixes things exploding if the driver probe fails and devres cleans up the rdev after we already free'd it. Fixes: a9ed2f052c5c ("drm/radeon: change drm_dev_alloc to devm_drm_dev_alloc") Signed-off-by: Daniel Palmer <daniel@0x0f.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/radeon: Clean up pdev->dev instances in probeDaniel Palmer1-4/+5
Get a struct device pointer from the start and use it. Signed-off-by: Daniel Palmer <daniel@0x0f.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amd: Check that VPE has reached DPM0 in idle handlerMario Limonciello1-4/+30
[Why] Newer VPE microcode has functionality that will decrease DPM level only when a workload has run for 2 or more seconds. If VPE is turned off before this DPM decrease and the PMFW doesn't reset it when power gating VPE, the SOC can get stuck with a higher DPM level. This can happen from amdgpu's ring buffer test because it's a short quick workload for VPE and VPE is turned off after 1s. [How] In idle handler besides checking fences are drained check PMFW version to determine if it will reset DPM when power gating VPE. If PMFW will not do this, then check VPE DPM level. If it is not DPM0 reschedule delayed work again until it is. v2: squash in return fix (Alex) Cc: Peyton.Lee@amd.com Reported-by: Sultan Alsawaf <sultan@kerneltoast.com> Reviewed-by: Sultan Alsawaf <sultan@kerneltoast.com> Tested-by: Sultan Alsawaf <sultan@kerneltoast.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4615 Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/sched: avoid killing parent entity on child SIGKILLDavid Rosca1-1/+2
The DRM scheduler tracks who last uses an entity and when that process is killed blocks all further submissions to that entity. The problem is that we didn't track who initially created an entity, so when a process accidently leaked its file descriptor to a child and that child got killed, we killed the parent's entities. Avoid that and instead initialize the entities last user on entity creation. This also allows to drop the extra NULL check. Signed-off-by: David Rosca <david.rosca@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4568 Reviewed-by: Alex Deucher <alexander.deucher@amd.com> CC: stable@vger.kernel.org Acked-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20251015140128.1470-1-christian.koenig@amd.com Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20251015140128.1470-1-christian.koenig@amd.com
2025-10-28drm/ttm: add pgprot handling for RISC-VIcenowy Zheng1-1/+2
The RISC-V Svpbmt privileged extension provides support for overriding page memory coherency attributes, and, along with vendor extensions like Xtheadmae, supports pgprot_{writecombine,noncached} on RISC-V. Adapt the codepath that maps ttm_write_combined to pgprot_writecombine and ttm_noncached to pgprot_noncached to RISC-V, to allow proper page access attributes. Signed-off-by: Icenowy Zheng <uwu@icenowy.me> Tested-by: Han Gao <rabenda.cn@gmail.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20251020053523.731353-1-uwu@icenowy.me
2025-10-28drm/etnaviv: fix flush sequence logicTomeu Vizoso1-1/+1
The current logic uses the flush sequence from the current address space. This is harmless when deducing the flush requirements for the current submit, as either the incoming address space is the same one as the currently active one or we switch context, in which case the flush is unconditional. However, this sequence is also stored as the current flush sequence of the GPU. If we switch context the stored flush sequence will no longer belong to the currently active address space. This incoherency can then cause missed flushes, resulting in translation errors. Fixes: 27b67278e007 ("drm/etnaviv: rework MMU handling") Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Link: https://lore.kernel.org/r/20251021093723.3887980-1-l.stach@pengutronix.de
2025-10-27drm/xe/pf: Access VF's register using dedicated MMIO viewMichal Wajdeczko3-28/+41
Instead of creating ad-hoc new register definitions with altered register addresses to mimic the VF's access to these registers, prepare new MMIO instance per required VF, with shifted internal location of the register map. This will allow to use unmodified register definitions in all calls to xe_mmio() functions. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20251024205826.4652-1-michal.wajdeczko@intel.com
2025-10-27drm/xe/xe3: Add WA_14024681466 for Xe3_LPGNitin Gote2-0/+5
Apply WA_14024681466 to Xe3_LPG graphics IP versions from 30.00 to 30.05. v2: (Matthew Roper) - Remove stepping filter as workaround applies to all steppings. - Add an engine class filter so it only applies to the RENDER engine. Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patch.msgid.link/20251027092643.335904-1-nitin.r.gote@intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-27drm/xe/pf: Fix VF FLR synchronization between all GTsMichal Wajdeczko1-0/+2
If subsequent VF FLR request is triggered when previous VF FLR sequence is still being processed, we ignore it as not needed. But in case of the multi-GT platforms, one GT may already finish its VF FLR processing and will start a new sequence, which includes new cross-GT synchronization point. However, since other GT may be still busy with post-sync cleanup steps, this will put on hold this new FLR sequence, which might never finish due to lack of any future synchronization checkouts. Add additional cross-GT FLR synchronization point when each GT ends processing its own FLR sequence. This should also help to cover the case when one GT fails FLR processing before reaching the first synchronization point. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6287 Fixes: 2a8fcf7cc950 ("drm/xe/pf: Synchronize VF FLR between all GTs") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20251025124906.5264-1-michal.wajdeczko@intel.com
2025-10-27drm/xe: Fix spelling and typos across Xe driver filesSanjay Yadav32-63/+63
Corrected various spelling mistakes and typos in multiple files under the Xe directory. These fixes improve clarity and maintain consistency in documentation. v2 - Replaced all instances of "XE" with "Xe" where it referred to the driver name - of -> for - Typical -> Typically v3 - Revert "Xe" to "XE" for macro prefix reference Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20251023121453.1182035-2-sanjay.kumar.yadav@intel.com
2025-10-27drm/nouveau: Fix race in nouveau_sched_fini()Philipp Stanner1-2/+12
nouveau_sched_fini() uses a memory barrier before wait_event(). wait_event(), however, is a macro which expands to a loop which might check the passed condition several times. The barrier would only take effect for the first check. Replace the barrier with a function which takes the spinlock. Cc: stable@vger.kernel.org # v6.8+ Fixes: 5f03a507b29e ("drm/nouveau: implement 1:1 scheduler - entity relationship") Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20251024161221.196155-2-phasta@kernel.org
2025-10-27drm/sched: Fix race in drm_sched_entity_select_rq()Philipp Stanner1-1/+2
In a past bug fix it was forgotten that entity access must be protected by the entity lock. That's a data race and potentially UB. Move the spin_unlock() to the appropriate position. Cc: stable@vger.kernel.org # v5.13+ Fixes: ac4eb83ab255 ("drm/sched: select new rq even if there is only one v3") Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20251022063402.87318-2-phasta@kernel.org
2025-10-27Merge 6.18-rc3 into driver-core-nextGreg Kroah-Hartman61-287/+468
We need the driver core fixes in here as well to build on top of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-26drm/gem-atomic: Reset plane state to NULL if allocation failedThomas Zimmermann1-2/+0
Unconditionally reset plane->state to NULL if the allocation of the shadow plane state fails. Avoids an invalid address in the field. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patch.msgid.link/20251017091919.58770-1-tzimmermann@suse.de
2025-10-26drm/sysfb: Do not dereference NULL pointer in plane resetThomas Zimmermann1-2/+6
The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not deref that pointer, but forward NULL to the other plane-reset helpers. Clears plane->state to NULL. v2: - fix typo in commit description (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: b71565022031 ("drm/gem: Export implementation of shadow-plane helpers") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/dri-devel/aPIDAsHIUHp_qSW4@stanley.mountain/ Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Melissa Wen <melissa.srw@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.15+ Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patch.msgid.link/20251017091407.58488-1-tzimmermann@suse.de
2025-10-25drm/msm: Ensure vm is created in VM_BIND ioctlRob Clark1-1/+1
Since the vm is lazily created, to allow userspace to opt-in to a VM_BIND context, we can't assume it is already created. Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl") Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/682939/ Message-ID: <20251022222039.9937-1-robin.clark@oss.qualcomm.com>
2025-10-25drm/msm: Reject MAP_NULL op if no PRRRob Clark3-7/+17
We need PRR support in order to implement MAP_NULL. Userspace shouldn't be trying to use this if it is unsupported. Reported-by: Valentine Burley <valentine.burley@collabora.com> Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37935#note_3153730 Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Tested-by: Valentine Burley <valentine.burley@collabora.com> Patchwork: https://patchwork.freedesktop.org/patch/682941/ Message-ID: <20251022222051.10030-1-robin.clark@oss.qualcomm.com>
2025-10-25gpu: nova-core: bitfield: remove BitOr implementationAlexandre Courbot1-9/+1
Using this operand can produce invalid values. It also doesn't bring any benefit as one can use the builder pattern to assemble a new value. Reported-by: Edwin Peer <epeer@nvidia.com> Link: https://lore.kernel.org/rust-for-linux/F3853912-2C1C-4F9B-89B0-3168689F35B3@nvidia.com/ Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251022-nova-bitfield-v1-3-73bc0988667b@nvidia.com>
2025-10-25gpu: nova-core: bitfield: simplify expressionAlexandre Courbot1-1/+1
The shift is more easily expressed by the index of the lowest bit of the field. Reported-by: Edwin Peer <epeer@nvidia.com> Link: https://lore.kernel.org/rust-for-linux/F3853912-2C1C-4F9B-89B0-3168689F35B3@nvidia.com/ Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251022-nova-bitfield-v1-2-73bc0988667b@nvidia.com>
2025-10-25gpu: nova-core: bitfield: simplify conditionAlexandre Courbot1-1/+1
This condition was uselessly convoluted. Reported-by: Edwin Peer <epeer@nvidia.com> Link: https://lore.kernel.org/rust-for-linux/F3853912-2C1C-4F9B-89B0-3168689F35B3@nvidia.com/ Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251022-nova-bitfield-v1-1-73bc0988667b@nvidia.com>
2025-10-25gpu: nova-core: replace wait_on with kernel equivalentsAlexandre Courbot5-91/+51
wait_on was a temporary helper function waiting for a kernel crate equivalent. Now that read_poll_timeout and fsleep are available, use them and remove wait_on. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251020-nova_wait_on-v1-1-2eb87fb38d14@nvidia.com>
2025-10-25gpu: nova-core: remove unnecessary need_riscv, bar parametersJohn Hubbard2-23/+2
The need_riscv parameter and its associated RISCV validation logic are are actually unnecessary for correct operation. Remove it, along with the now-unused bar parameter as well. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251025014050.585153-3-jhubbard@nvidia.com>
2025-10-25gpu: nova-core: remove an unnecessary register read: HWCFG1John Hubbard1-5/+0
This register read is not required in order to bring up any of the GPUs, and it is read too early on Hopper/Blackwell+ GPUs anyway. So just stop doing this. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251025014050.585153-2-jhubbard@nvidia.com>
2025-10-25gpu: nova-core: Ada: basic GPU identificationJohn Hubbard2-1/+2
...which is sufficient to make Ada GPUs work, because they use the pre-existing Ampere GPU code, unmodified. Tested on AD102 (RTX 6000 Ada). Signed-off-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251025012017.573078-1-jhubbard@nvidia.com>
2025-10-25gpu: nova-core: regs: rename .alter() --> .update()John Hubbard2-18/+18
This also changes .try_alter() to try_update(). After this commit, instead of "read, write and alter", the methods available for registers are now "read, write and update". This reads a lot easier for people who are used to working with registers, and aligns the API with what e.g. regmap uses. No functional changes are intended. Signed-off-by: John Hubbard <jhubbard@nvidia.com> [acourbot@nvidia.com: add Link tag for context.] [acourbot@nvidida.com: mention regmap in commit log.] Link: https://lore.kernel.org/all/2c5d90c8-e73a-4f04-9c1d-30adbd0fef07@nvidia.com/ Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251025010815.566909-2-jhubbard@nvidia.com>
2025-10-25drm/xe/configfs: Drop MAX_GT_TYPE_CHARS constantMatt Roper1-2/+1
Early revisions of commit 7abd69278bb5 ("drm/xe/configfs: Add attribute to disable GT types") used MAX_GT_TYPE_CHARS not only to size the constant name field, but also for some of the string matching logic. By the time the patch finally landed, the constant was no longer needed for parsing. Stop using it for the string field definition as well; this eliminates the risk that we forget to update the constant if we ever add a GT type name longer than seven characters. Suggested-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20251024200834.1512329-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-04 14:21:50 +0300