summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-05-29drm/msm: Add sysprof accessorsRob Clark
Currently the sysprof param serves two functions, (a) disabling perfcntr clearing on context switch/preemption, and (b) disabling IFPC. In the future, with kernel side global perfcntr collection/stream, the decision about disabling IFPC will change. To prepare for this, split out two helpers/accessors for the two different cases. For now, they are the same thing, but this will change. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Anna Maniscalco <anna.maniscalco2000@gmail.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/728214/ Message-ID: <20260526145137.160554-8-robin.clark@oss.qualcomm.com>
2026-05-29drm/msm: Add a6xx+ perfcntr tablesRob Clark
Wire up the generated perfcntr tables for a6xx+. The PERFCNTR_CONFIG ioctl will use this information to assign counters. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Anna Maniscalco <anna.maniscalco2000@gmail.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/728213/ Message-ID: <20260526145137.160554-7-robin.clark@oss.qualcomm.com>
2026-05-29drm/msm/registers: Add perfcntr jsonRob Clark
Pull in perfcntr json and wire up generation of perfcntr tables. Sync from mesa commit a573e25b6dcd ("freedreno/registers: Gen8 perfcntr fixes") Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Anna Maniscalco <anna.maniscalco2000@gmail.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/728204/ Message-ID: <20260526145137.160554-6-robin.clark@oss.qualcomm.com>
2026-05-29drm/msm/registers: Sync gen_header.py from mesaRob Clark
Update gen_header.py to bring in support for generating perfcntr tables. Sync from mesa commit 96c5179c02d1 ("freedreno/registers: Skip deprecated warns for kernel") Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Anna Maniscalco <anna.maniscalco2000@gmail.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/728203/ Message-ID: <20260526145137.160554-5-robin.clark@oss.qualcomm.com>
2026-05-29drm/msm/adreno: Sync registers from mesaRob Clark
Most of the churn is just reworking the usage attribute on the mesa side. Sync from mesa commit ff41a00fab89 ("freedreno/registers: Correct register name") Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Anna Maniscalco <anna.maniscalco2000@gmail.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/728202/ Message-ID: <20260526145137.160554-4-robin.clark@oss.qualcomm.com>
2026-05-29drm/msm: Allow CAP_PERFMON for setting SYSPROFRob Clark
Use perfmon_capable() which checks both CAP_SYS_ADMIN and CAP_PERFMON. This matches what i915 and xe do, and seems more appropriate. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Anna Maniscalco <anna.maniscalco2000@gmail.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/728198/ Message-ID: <20260526145137.160554-3-robin.clark@oss.qualcomm.com>
2026-05-29drm/msm: Remove obsolete perf infrastructureRob Clark
Outside of a3xx, this was never really used. And it low-key gets in the way of the new perfcntr support (or at least it is confusing to have two things called "perf"). So lets remove it. This drops the "perf" debugfs file. But these days, nvtop is a better option. (Plus perfetto for newer gens.) Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Anna Maniscalco <anna.maniscalco2000@gmail.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/728200/ Message-ID: <20260526145137.160554-2-robin.clark@oss.qualcomm.com>
2026-05-29drm/msm/a8xx: Fix RSCC offsetAkhil P Oommen
In A8xx, the RSCC block is part of GPU's register space. Update the virtual base address of rscc to point to the correct address. Fixes: 50e8a557d8d3 ("drm/msm/a8xx: Add support for A8x GMU") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/727117/ Message-ID: <20260522-glymur-gpu-dt-v5-1-562c406b210c@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-05-29drm/msm/a6xx: Limit GXPD votes to recovery in A8xAkhil P Oommen
In A8x GPUs, the GX GDSC is moved to a separate block called GXCLKCTL which is under the GX power domain. Due to the way the support for this block is implemented in its driver, pm_runtime votes result in a vote on GX/GMxC/MxC rails from the APPS RSC. This is against the Adreno architecture which require GMU to be the sole voter of these collapsible rails on behalf of GPU, except during the GPU/GMU recovery. To align with this architectural requirement and to realize the power benefits of the IFPC feature, remove the GXPD votes during gmu resume and suspend. And during the recovery sequence, enable/disable the GXPD along with the 'synced_poweroff' genpd hint to force collapse this GDSC. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/720979/ Message-ID: <20260427-gfx-clk-fixes-v2-6-797e54b3d464@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-05-29drm/msm/a8xx: Make a8xx_recover IFPC safeAkhil P Oommen
Similar to a6xx_recover(), check the GX power domain status before accessing mmio in GX domain a8xx_recover(). Fixes: 288a93200892 ("drm/msm/adreno: Introduce A8x GPU Support") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/720977/ Message-ID: <20260427-gfx-clk-fixes-v2-5-797e54b3d464@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-05-29drm/msm: Restore second parameter name in purge() and evict()Nathan Chancellor
After commit 3392291fc509 ("drm/msm: Fix shrinker deadlock"), all supported versions of clang warn (or error with CONFIG_WERROR=y): drivers/gpu/drm/msm/msm_gem_shrinker.c:105:58: error: omitting the parameter name in a function definition is a C23 extension [-Werror,-Wc23-extensions] 105 | purge(struct drm_gem_object *obj, struct ww_acquire_ctx *) | ^ drivers/gpu/drm/msm/msm_gem_shrinker.c:117:58: error: omitting the parameter name in a function definition is a C23 extension [-Werror,-Wc23-extensions] 117 | evict(struct drm_gem_object *obj, struct ww_acquire_ctx *) | ^ 2 errors generated. With older but supported versions of GCC, this is an unconditional hard error: drivers/gpu/drm/msm/msm_gem_shrinker.c: In function 'purge': drivers/gpu/drm/msm/msm_gem_shrinker.c:105:35: error: parameter name omitted purge(struct drm_gem_object *obj, struct ww_acquire_ctx *) ^~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/msm/msm_gem_shrinker.c: In function 'evict': drivers/gpu/drm/msm/msm_gem_shrinker.c:117:35: error: parameter name omitted evict(struct drm_gem_object *obj, struct ww_acquire_ctx *) ^~~~~~~~~~~~~~~~~~~~~~~ Restore the parameter name to clear up the warnings, renaming it "unused" to make it clear it is only needed to satisfy the prototype of drm_gem_lru_scan(). Cc: stable@vger.kernel.org Fixes: 3392291fc509 ("drm/msm: Fix shrinker deadlock") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/725924/ Link: https://lore.kernel.org/r/20260518-drm-msm-fix-c23-extensions-v1-1-0833559418c7@kernel.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-05-29drm/msm/dp: clear EDID on display unplugDmitry Baryshkov
Currently the driver only updates the EDID when it detects a connected monitor, which results in the connector still listing outdated modes even after the display is unplugged. Set connector's EDID to NULL on unplug to clear the list of modes. Tested-by: Val Packett <val@packett.cool> # x1e80100-dell-latitude-7455 Tested-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> # Hamoa IOT EVK, QCS8300 Ride Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/727619/ Link: https://lore.kernel.org/r/20260524-hpd-refactor-v6-10-cf3ab488dd7b@oss.qualcomm.com
2026-05-29drm/msm/dp: turn link_ready into pluggedDmitry Baryshkov
Tracking when the DP link is ready isn't that useful from the driver point of view. It doesn't provide a direct information if the device should be suspended, etc. Replace it with the 'plugged' boolean, which is set when the driver knows that there is DPRX plugged. Tested-by: Val Packett <val@packett.cool> # x1e80100-dell-latitude-7455 Tested-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> # Hamoa IOT EVK, QCS8300 Ride Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/727614/ Link: https://lore.kernel.org/r/20260524-hpd-refactor-v6-9-cf3ab488dd7b@oss.qualcomm.com
2026-05-29drm/msm/dp: Add sink_count to debug logsJessica Zhang
Add sink count to the debug logs for [un]plug and HPD IRQ handling. Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> [DB: dropped link_ready handling] Tested-by: Val Packett <val@packett.cool> # x1e80100-dell-latitude-7455 Tested-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> # Hamoa IOT EVK, QCS8300 Ride Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/727620/ Link: https://lore.kernel.org/r/20260524-hpd-refactor-v6-8-cf3ab488dd7b@oss.qualcomm.com
2026-05-29drm/msm/dp: rework HPD handlingJessica Zhang
Handling of the HPD events in the MSM DP driver is plagued with lots of problems. It tries to work aside of the main DRM framework, handling the HPD signals on its own. There are two separate paths, one for the HPD signals coming from the DP HPD pin and another path for signals coming from outside (e.g. from the Type-C AltMode). It lies about the connected state, returning the link established state instead. It is not easy to understand or modify it. Having a separate event machine doesn't add extra clarity. Drop the whole event machine. When the DP receives a HPD event, send it to the DRM core. Then handle the events in the hpd_notify callback, unifying paths for HPD signals. Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> Tested-by: Val Packett <val@packett.cool> # x1e80100-dell-latitude-7455 Tested-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> # Hamoa IOT EVK, QCS8300 Ride Co-developed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/727616/ Link: https://lore.kernel.org/r/20260524-hpd-refactor-v6-7-cf3ab488dd7b@oss.qualcomm.com
2026-05-29drm/msm/dp: drop event dataDmitry Baryshkov
With EV_USER_NOTIFICATION gone event's data is no longer useful. Drop it, removing also the argument from event handlers. Reviewed-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Tested-by: Val Packett <val@packett.cool> # x1e80100-dell-latitude-7455 Tested-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> # Hamoa IOT EVK, QCS8300 Ride Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/727610/ Link: https://lore.kernel.org/r/20260524-hpd-refactor-v6-6-cf3ab488dd7b@oss.qualcomm.com
2026-05-29drm/msm/dp: Drop EV_USER_NOTIFICATIONJessica Zhang
Currently, we queue an event for signalling HPD connect/disconnect. This can mean a delay in plug/unplug handling and notifying DRM core when a hotplug happens. Drop EV_USER_NOTIFICATION and signal the IRQ event as part of hotplug handling. Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Tested-by: Val Packett <val@packett.cool> # x1e80100-dell-latitude-7455 Tested-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> # Hamoa IOT EVK, QCS8300 Ride Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/727607/ Link: https://lore.kernel.org/r/20260524-hpd-refactor-v6-5-cf3ab488dd7b@oss.qualcomm.com
2026-05-29drm/msm/dp: Move link training to atomic_enable()Jessica Zhang
Currently, the DP link training is being done during HPD. Move link training to atomic_enable() in accordance with the atomic_enable() documentation. Link disabling is already done in atomic_post_disable() (as part of the dp_ctrl_off_link_stream() helper). Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> Tested-by: Val Packett <val@packett.cool> # x1e80100-dell-latitude-7455 Tested-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> # Hamoa IOT EVK, QCS8300 Ride Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/727606/ Link: https://lore.kernel.org/r/20260524-hpd-refactor-v6-4-cf3ab488dd7b@oss.qualcomm.com
2026-05-29drm/msm/dp: Read DPCD and sink count in bridge detect()Jessica Zhang
Instead of relying on the link_ready flag to specify if DP is connected, read the DPCD bits and get the sink count to accurately detect if DP is connected. Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> Tested-by: Val Packett <val@packett.cool> # x1e80100-dell-latitude-7455 Tested-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> # Hamoa IOT EVK, QCS8300 Ride Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/727603/ Link: https://lore.kernel.org/r/20260524-hpd-refactor-v6-3-cf3ab488dd7b@oss.qualcomm.com
2026-05-29drm/msm/dp: Fix the ISR_* enum valuesJessica Zhang
The ISR_HPD_* enum should represent values that can be read from the REG_DP_DP_HPD_INT_STATUS register. Swap ISR_HPD_IO_GLITCH_COUNT and ISR_HPD_REPLUG_COUNT to map them correctly to register values. While we are at it, correct the spelling for ISR_HPD_REPLUG_COUNT. Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets") Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Tested-by: Val Packett <val@packett.cool> # x1e80100-dell-latitude-7455 Tested-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> # Hamoa IOT EVK, QCS8300 Ride Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/727602/ Link: https://lore.kernel.org/r/20260524-hpd-refactor-v6-2-cf3ab488dd7b@oss.qualcomm.com
2026-05-29drm/msm/dp: fix HPD state status bit shift valueJessica Zhang
The HPD state status is the 3 most significant bits, not 4 bits of the HPD_INT_STATUS register. Fix the bit shift macro so that the correct bits are returned in msm_dp_aux_is_link_connected(). Fixes: 19e52bcb27c2 ("drm/msm/dp: return correct connection status after suspend") Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Tested-by: Val Packett <val@packett.cool> # x1e80100-dell-latitude-7455 Tested-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> # Hamoa IOT EVK, QCS8300 Ride Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/727611/ Link: https://lore.kernel.org/r/20260524-hpd-refactor-v6-1-cf3ab488dd7b@oss.qualcomm.com
2026-05-29drm/sched: Fix clang build warning in kunit testsTvrtko Ursulin
Initializing compile time constant struct or arrays from another such variable is a gcc extension, while clang strictly requires a compile time constant literal. As reported by LKP: >> drivers/gpu/drm/scheduler/tests/tests_scheduler.c:675:10: error: initializer element is not a compile-time constant drm_sched_scheduler_two_clients_attr), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/kunit/test.h:224:13: note: expanded from macro 'KUNIT_CASE_PARAM_ATTR' .attr = attributes, .module_name = KBUILD_MODNAME} ^~~~~~~~~~ 1 error generated. vim +675 drivers/gpu/drm/scheduler/tests/tests_scheduler.c 671 672 static struct kunit_case drm_sched_scheduler_two_clients_tests[] = { 673 KUNIT_CASE_PARAM_ATTR(drm_sched_scheduler_two_clients_test, 674 drm_sched_scheduler_two_clients_gen_params, > 675 drm_sched_scheduler_two_clients_attr), 676 {} 677 }; 678 Fix it by using a compound literal as other tests do. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202605220312.Pu7UO05u-lkp@intel.com/ Fixes: 97ef806a5314 ("drm/sched: Add some scheduling quality unit tests") Cc: Philipp Stanner <phasta@kernel.org> Acked-by: Philipp Stanner <phasta@kernel.org> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260522090129.9385-1-tvrtko.ursulin@igalia.com
2026-05-29gpu: nova-core: gsp: shuffle boot code a bit to keep chipset-specific parts ↵Alexandre Courbot
close Some parts of the GSP boot process are chip-specific actions, whereas others (like sending the initial post-boot messages) deal directly with the working GSP. Reorganize the boot code a bit so the chipset-specific parts are clumped together, which will make their extraction into a HAL easier. This has no effect on the GSP boot process. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260521-nova-unload-v6-5-65f581c812c9@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-05-29gpu: nova-core: refactor SEC2 booter loading into BooterFirmware::run()John Hubbard
Move the SEC2 reset/load/boot sequence into a BooterFirmware::run() method. This is mostly refactoring, with no significant behavior change, done in preparation for adding an alternative FSP boot path. Suggested-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260521-nova-unload-v6-4-65f581c812c9@nvidia.com [acourbot: fix typo in commit message.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-05-29gpu: nova-core: do not import firmware commands into GSP command moduleAlexandre Courbot
Importing all the firmware commands like we did is a bit confusing, as the layer of a command type (fw or GSP) cannot be inferred from looking at its name alone. Furthermore it makes it impossible to create commands that have the same name as their firmware command. Thus, stop importing all commands and refer to them from the `fw` module instead. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260521-nova-unload-v6-2-65f581c812c9@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-05-29gpu: nova-core: remove unneeded get_gsp_info proxy functionAlexandre Courbot
This function was useful before the generic command-queue send methods got merged, but it is just boilerplate now. Replace it with the correct sequence to queue the `GetGspStaticInfo` command directly. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260521-nova-unload-v6-1-65f581c812c9@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-05-29drm: prevent integer overflows in dumb buffer creation helpersRajat Gupta
Fix integer overflow issues in the dumb buffer creation path: 1. drm_mode_create_dumb() does not bound width, height, or bpp before passing them to driver callbacks. Downstream helpers (e.g. drm_gem_dma_dumb_create_internal) perform pitch/size alignment in u32 arithmetic that can overflow for extreme values. Add hard limits: width and height < 8192, bpp <= 32. No legitimate software rendering use case exceeds these. 2. drm_mode_align_dumb() uses roundup(pitch, hw_pitch_align) without checking for overflow. If pitch is near U32_MAX, roundup() wraps to a small value, making subsequent check_mul_overflow() pass with a much smaller pitch than intended. Add an overflow check after roundup. 3. drm_mode_align_dumb() uses ALIGN(size, hw_size_align) which only works correctly for power-of-two alignment values. Replace with roundup() which works for any alignment. Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Rajat Gupta <rajat.gupta@oss.qualcomm.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2026-05-28drm/managed: use special gfp_t format specifierBrendan Jackman
Patch series "treewide: fixup gfp_t printks", v2. Use vprintf()'s special gfp_t conversion in a few places. This patch (of 3): %pGg produces nice readable output and decouples the format string from the size of gfp_t. Link: https://lore.kernel.org/20260326-gfp64-v2-0-d916021cecdf@google.com Link: https://lore.kernel.org/20260326-gfp64-v2-1-d916021cecdf@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Cc: Alexander Potapenko <glider@google.com> Cc: Allison Collins <allison.henderson@oracle.com> Cc: Allison Henderson <achender@kernel.org> Cc: Dave Airlie <airlied@gmail.com> Cc: David S. Miller <davem@davemloft.net> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kacinski <kuba@kernel.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Marco Elver <elver@google.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Simon Horman <horms@kernel.org> Cc: Stanislaw Gruszka <stf_xl@wp.pl> Cc: Thomas Zimemrmann <tzimmermann@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-05-29Merge tag 'amd-drm-fixes-7.1-2026-05-28' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-7.1-2026-05-28: amdgpu: - GEM_OP warning fix - GEM_OP locking fix - Userq fixes - DCN 2.1 refclk fix - SI fix - HMM fixes amdkfd: - svm_range_set_attr locking fix - CRIU restore fix - KFD debugger fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260528211843.893681-1-alexander.deucher@amd.com
2026-05-29Merge tag 'drm-xe-fixes-2026-05-28' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes - Restore IDLEDLY regiter on engine reset (Bala) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/ahhBUt8fDqjB-mQq@intel.com
2026-05-29gpu: nova: separate driver type from driver dataDanilo Krummrich
Split NovaDriver into a unit struct for trait implementations and a separate Nova struct for the private driver data. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260525225838.276108-6-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-29gpu: nova-core: gsp: replace ARef<Device> with &'a Device in sequencerDanilo Krummrich
GspSequencer, GspSeqIter, and GspSequencerParams are already lifetime-parameterized; the ARef<Device> is unnecessary -- a plain &'a Device reference suffices. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260525225838.276108-5-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-29gpu: nova-core: replace ARef<Device> with &'bound Device in SysmemFlushDanilo Krummrich
Now that SysmemFlush is lifetime-parameterized, the ARef<Device> is unnecessary -- a plain &'bound Device reference suffices. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260525225838.276108-4-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-29gpu: nova-core: unregister sysmem flush page from DropDanilo Krummrich
Now that SysmemFlush can borrow the Bar via HRT lifetime, store a &'bound Bar0 reference and implement Drop to automatically unregister the sysmem flush page. This removes the need for manual unregister() calls and the Gpu::unbind() method. Reported-by: Eliot Courtney <ecourtney@nvidia.com> Closes: https://lore.kernel.org/all/20260409-fix-systemflush-v1-1-a1d6c968f17c@nvidia.com/ Fixes: 6554ad65b589 ("gpu: nova-core: register sysmem flush page") Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260525225838.276108-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-29gpu: nova-core: use lifetime for BarDanilo Krummrich
Take advantage of the lifetime-parameterized pci::Bar<'bound> to hold the BAR mapping directly in NovaCore<'bound>, and pass a borrowed reference to Gpu<'bound>. This eliminates the Arc<Devres<Bar0>> indirection, removes runtime revocation checks for BAR access, and simplifies Gpu::unbind(). Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260525225838.276108-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-29Merge tag 'dd-lifetimes-7.2-rc1' of ↵Danilo Krummrich
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core into drm-rust-next Higher-Ranked Lifetime Types for Rust device drivers Replace drvdata() with registration data on the auxiliary bus. Private data is now scoped to the registration object, removing the ordering constraints and lifetime complications that came with drvdata(). Add Higher-Ranked Lifetime Types (HRT) so driver structs can borrow device resources like pci::Bar and IoMem directly, tied to the device binding scope. This removes the need for Devres indirection and ARef<Device> in most driver code. This is a stable tag for other trees to merge. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-29Merge patch series "rust: device: Higher-Ranked Lifetime Types for device ↵Danilo Krummrich
drivers" Danilo Krummrich <dakr@kernel.org> says: Currently, Rust device drivers access device resources such as PCI BAR mappings and I/O memory regions through Devres<T>. Devres::access() provides zero-overhead access by taking a &Device<Bound> reference as proof that the device is still bound. Since a &Device<Bound> is available in almost all contexts by design, Devres is mostly a type-system level proof that the resource is valid, but it can also be used from scopes without this guarantee through its try_access() accessor. This works well in general, but has a few limitations: - Every access to a device resource goes through Devres::access(), which despite zero cost, adds boilerplate to every access site. - Destructors do not receive a &Device<Bound>, so they must use try_access(), which can fail. In practice the access succeeds if teardown ordering is correct, but the type system can't express this, forcing drivers to handle a failure path that should never be taken. - Sharing a resource across components (e.g. passing a BAR to a sub-component) requires Arc<Devres<T>>. - Device references must be stored as ARef<Device> rather than plain &Device borrows. These limitations stem from the driver's bus device private data being 'static -- the driver struct cannot borrow from the device reference it receives in probe(), even though it structurally cannot outlive the device binding. This series introduces Higher-Ranked Lifetime Types (HRT) for Rust device drivers. An HRT is a type that is generic over a lifetime -- it does not have a fixed lifetime, but can be instantiated with any lifetime chosen by the caller. Bus driver traits use a Generic Associated Type (GAT) type Data<'bound> to introduce the lifetime on the private data, rather than parameterizing the Driver trait itself. This avoids a driver trait global lifetime and avoids the need for ForLt for bus device private data, making the bus implementations much simpler. ForLt is only needed for auxiliary registration data, where the lifetime is not introduced by a trait callback but must be threaded through Registration. With HRT, driver structs carry a lifetime parameter tied to the device binding scope -- the interval of a bus device being bound to a driver. Device resources like pci::Bar<'bound> and IoMem<'bound> are handed out with this lifetime, so the compiler enforces at build time that they do not escape the binding scope. Before: struct MyDriver { pdev: ARef<pci::Device>, bar: Devres<pci::Bar<BAR_SIZE>>, } let io = self.bar.access(dev)?; io.read32(OFFSET); After: struct MyDriver<'bound> { pdev: &'bound pci::Device, bar: pci::Bar<'bound, BAR_SIZE>, } self.bar.read32(OFFSET); Lifetime-parameterized device resources can be put into a Devres at any point via Bar::into_devres() / IoMem::into_devres(), providing the exact same semantics as before. This is useful for resources shared across subsystem boundaries where revocation is needed. This also synergizes with the upcoming self-referential initialization support in pin-init, which allows one field of the driver struct to borrow another during initialization without unsafe code. The same pattern is applied to auxiliary device registration data as a first example beyond bus device private data. Registration<F: ForLt> can hold lifetime-parameterized data tied to the parent driver's binding scope. Since the auxiliary bus guarantees that the parent remains bound while the auxiliary device is registered, the registration data can safely borrow the parent's device resources. More generally, binding resource lifetimes to a registration scope applies to every registration that is scoped to a driver binding -- auxiliary devices, class devices, IRQ handlers, workqueues. A follow-up series extends this to class device registrations, starting with DRM, so that class device callbacks (IOCTLs, etc.) can safely access device resources through the separate registration data bound to the registration's lifetime without Devres indirection. Thanks to Gary for coming up with the ForLt implementation; thanks to Alice for the early discussions around lifetime-parameterized private data that helped shape the direction of this work. Link: https://patch.msgid.link/20260525202921.124698-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-29rust: drm: add FEAT_RENDER flag for render node supportLaura Nao
Add FEAT_RENDER bool constant to the Driver trait to control render node support. When enabled, the driver exposes /dev/dri/renderDXX render nodes to userspace. The flag defaults to false, drivers can opt in by setting it to true in their Driver implementation. This is then enabled in the Tyr driver, while it's left disabled for Nova for the time being. Co-developed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Laura Nao <laura.nao@collabora.com> Link: https://patch.msgid.link/20260507080914.95478-2-laura.nao@collabora.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-28Revert "nouveau/gsp: cleanup IS_ERR_OR_NULL in rm_alloc functions"Lyude Paul
This is probably too risky, see the discussion here: https://lists.freedesktop.org/archives/dri-devel/2026-May/570353.html This reverts commit 281fe11c6c4aebc1a1eb9d21eaab7323ee5af979. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Link: https://patch.msgid.link/20260528192847.4077458-6-lyude@redhat.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-28Revert "nouveau/gsp: cleanup IS_ERR_OR_NULL in rpc_rd"Lyude Paul
This is probably much too risky. See the discussion here: https://lists.freedesktop.org/archives/dri-devel/2026-May/570353.html This reverts commit 47f15f6cf068c14d1a5054066c445bee23f6047e. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Link: https://patch.msgid.link/20260528192847.4077458-5-lyude@redhat.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-28Revert "nouveau/gsp/rm: cleanup WARN_ON(IS_ERR_OR_NULL)"Lyude Paul
This is probably too risky, see the discussion here: https://lists.freedesktop.org/archives/dri-devel/2026-May/570353.html This reverts commit 6198977a78af8769d3f3108e830901325b97cf03. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Link: https://patch.msgid.link/20260528192847.4077458-4-lyude@redhat.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-28Revert "nouveau/gsp/rm: cleanup IS_ERR_OR_NULL in core implementation"Lyude Paul
This is probably too risky, see the discussion here: https://lists.freedesktop.org/archives/dri-devel/2026-May/570353.html This reverts commit 67346c90ce275e835e93a4a13041afee47bd3f9e. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Link: https://patch.msgid.link/20260528192847.4077458-3-lyude@redhat.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-28Revert "nouveau/gsp/rm: cleanup remaining IS_ERR_OR_NULL usage"Lyude Paul
This reverts commit 1a80c009e27b42e8c202d4c5dbd9dad9e22af742. Embarassingly, it seems that I completely missed a pretty big issue this patch causes according to Danilo and Sashiko: https://lists.freedesktop.org/archives/dri-devel/2026-May/570353.html Where it seems this causes some machines to segfault during nouveau probe. So, revert this for the time being. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Link: https://patch.msgid.link/20260528192847.4077458-2-lyude@redhat.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-28drm/tegra: Explicitly specify PMC instance to useThierry Reding
Currently the kernel relies on a global variable to reference the PMC context. Use an explicit lookup for the PMC and pass that to the public PMC APIs. Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-05-28drm/nouveau: tegra: Explicitly specify PMC instance to useThierry Reding
Currently the kernel relies on a global variable to reference the PMC context. Use an explicit lookup for the PMC and pass that to the public PMC APIs. Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-05-28drm/amd/display: Add a default case for dc_status_to_strIvan Lipski
[Why&How] If a parsed dc_status case is not covered by the dc_status_to_str, the switch case is skipped, and the function returns "Unexpected status error". This causes build failures when new dc_status enums are introduced. Changing the 'return "Unexpected status error"' into default resolves it. Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-28drm/amdgpu: fix amdgpu_vm_bo_reset_state_machineChristian König
Can't splice the list but need to handle each entry individually. Otherwise we run into issues after a GPU reset. Fixes: 4cdbba5a16aa ("drm/amdgpu: restructure VM state machine v4") Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Jesse Zhang <jesse.zhang@amd.com> Tested-by: Jesse Zhang <jesse.zhang@amd.com> Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-28Merge remote-tracking branch 'drm/drm-next' into drm-rust-nextDanilo Krummrich
Backmerge to pull in commit 838d852da850 ("rust: allow `clippy::collapsible_match` globally"), in order to get rid of spurious warnings messing with developer tooling. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-28drm/nouveau/gsp: formally support GA100Timur Tabi
Now that Nouveau supports GA100 properly, it should no longer require the NvEnableUnsupportedChipsets parameter in order to enable it. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Link: https://patch.msgid.link/20260430223838.2530778-11-ttabi@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-28drm/nouveau/gsp: require GSP-RM for GA100 supportTimur Tabi
Nouveau supports Turing and Ampere GPUs with or without GSP-RM. Support without GSP-RM is mostly academic, since GSP-RM is needed to run the GPU at full clocks. It is also the default mode for these GPUs. GA100 is a special case, however. The current code has some support for running GA100 without GSP-RM, but several features are missing. More importantly, some required firmware images like ucode_ahesasc.bin are not available and would need to be provided by Nvidia. To prevent Nouveau from even trying to boot on GA100 without GSP-RM, remove the non-GSP fallback option in the ga100_gsps[] array. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260430223838.2530778-10-ttabi@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-07-16 09:55:50 +0000