summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2025-08-15drm/amd/display: Add NULL pointer checks in dc_stream cursor attribute functionsSrinivasan Shanmugam1-1/+7
The function dc_stream_set_cursor_attributes() currently dereferences the `stream` pointer and nested members `stream->ctx->dc->current_state` without checking for NULL. All callers of these functions, such as in `dcn30_apply_idle_power_optimizations()` and `amdgpu_dm_plane_handle_cursor_update()`, already perform NULL checks before calling these functions. Fixes below: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:336 dc_stream_program_cursor_attributes() error: we previously assumed 'stream' could be null (see line 334) drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c 327 bool dc_stream_program_cursor_attributes( 328 struct dc_stream_state *stream, 329 const struct dc_cursor_attributes *attributes) 330 { 331 struct dc *dc; 332 bool reset_idle_optimizations = false; 333 334 dc = stream ? stream->ctx->dc : NULL; ^^^^^^ The old code assumed stream could be NULL. 335 --> 336 if (dc_stream_set_cursor_attributes(stream, attributes)) { ^^^^^^ The refactor added an unchecked dereference. drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c 313 bool dc_stream_set_cursor_attributes( 314 struct dc_stream_state *stream, 315 const struct dc_cursor_attributes *attributes) 316 { 317 bool result = false; 318 319 if (dc_stream_check_cursor_attributes(stream, stream->ctx->dc->current_state, attributes)) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here. This function used to check for if stream as NULL and return false at the start. Probably we should add that back. Fixes: 4465dd0e41e8 ("drm/amd/display: Refactor SubVP cursor limiting logic") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Cc: Alex Hung <alex.hung@amd.com> Cc: Alvin Lee <alvin.lee2@amd.com> Cc: Ray Wu <ray.wu@amd.com> Cc: Dillon Varone <dillon.varone@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Roman Li <roman.li@amd.com> Cc: ChiaHsuan Chung <chiahsuan.chung@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Wheeler <daniel.wheeler@amd.com> Cc: Tom Chung <chiahsuan.chung@amd.com> Cc: Wenjing Liu <wenjing.liu@amd.com> Cc: Jun Lei <Jun.Lei@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Dillon Varone <Dillon.varone@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-15drm/radeon: fix typosAlexandre Demers3-7/+7
Various small typos found around. Signed-off-by: Alexandre Demers <alexandre.f.demers@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-15drm/amdgpu/swm14: Update power limit logicAlex Deucher1-5/+25
Take into account the limits from the vbios. Ported from the SMU13 code. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4352 Reviewed-by: Jesse Zhang <Jesse.Zhang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-15drm/amd/pm: Free SMUv13.0.6 resources on failureLijo Lazar2-3/+13
Free the resources allocated if smu_v13_0_12_tables_init fails. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Fixes: 5bf93e1d6efd ("drm/amd/pm: Add caching to SMUv13.0.12 temp metric") Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-15drm/amd/vcn: Add late_init callback for VCN v4.0.3 reset handlingJesse.Zhang1-4/+14
This change reorganizes VCN reset capability detection by: 1. Moving reset mask configuration from sw_init to new late_init phase 2. Adding vcn_v4_0_3_late_init() to properly check for per-queue reset support 3. Only setting soft full reset mask as fallback when per-queue reset isn't supported 4. Removing TODO comment now that queue reset support is implemented V2: Removed unrelated changes. Keep amdgpu_get_soft_full_reset_mask in place and remove TODO comment. (Alex) v3: set the flags at one place (all in late_init) (Lijo) Suggested-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Ruili Ji <ruiliji2@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-15drm/amdkfd: Handle lack of READ permissions in SVM mappingKent Russell1-0/+23
HMM assumes that pages have READ permissions by default. Inside svm_range_validate_and_map, we add READ permissions then add WRITE permissions if the VMA isn't read-only. This will conflict with regions that only have PROT_WRITE or have PROT_NONE. When that happens, svm_range_restore_work will continue to retry, silently, giving the impression of a hang if pr_debug isn't enabled to show the retries.. If pages don't have READ permissions, simply unmap them and continue. If they weren't mapped in the first place, this would be a no-op. Since x86 doesn't support write-only, and PROT_NONE doesn't allow reads or writes anyways, this will allow the svm range validation to continue without getting stuck in a loop forever on mappings we can't use with HMM. Signed-off-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-15drm/amd/pm: Add VCN reset support for SMU v13.0.6Jesse.Zhang3-2/+12
This commit implements VCN reset capability for SMU v13.0.6 with the following changes: 1. Added new PPSMC message ID (0x5B) for VCN reset in SMU firmware interface 2. Extended SMU capabilities to include VCN_RESET support 3. Implemented VCN reset support check: - Added smu_v13_0_6_reset_vcn_is_supported() function 4. Updated SMU v13.0.6 PPT functions to include VCN reset operations v2: clean up debug info (Alex) v3: remove unsupported message and split smu v13.0.6 changes to a separate patch (Lijo) v4: simply the function (smu_v13_0_6_reset_vcn_is_supported) (Lijo) Suggested-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Ruili Ji <ruiliji2@amd.com> 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-08-15drm/amd/pm: Add VCN reset support check capabilityJesse.Zhang4-0/+31
This change introduces infrastructure to check whether VCN reset is supported by the SMU firmware. Key changes include: 1. Added new functions to query VCN reset support: - amdgpu_dpm_reset_vcn_is_supported() - smu_reset_vcn_is_supported() - pptable_funcs.reset_vcn_is_supported callback 2. Implemented proper locking in the DPM layer with mutex protection 3. Maintained consistency with existing SDMA reset support checks The new capability allows callers to check for VCN reset support before attempting the operation, preventing unnecessary attempts on unsupported platforms. v2: clean up debug info(Alex) Suggested-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Ruili Ji <ruiliji2@amd.com> 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-08-15drm/amdgpu: fix nullptr err of vm_handle_movedHeng Zhou1-1/+14
If a amdgpu_bo_va is fpriv->prt_va, the bo of this one is always NULL. So, such kind of amdgpu_bo_va should be updated separately before amdgpu_vm_handle_moved. Signed-off-by: Heng Zhou <Heng.Zhou@amd.com> Reviewed-by: Kasiviswanathan, Harish <Harish.Kasiviswanathan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-15drm/amdkfd: set uuid for each partition in topologyEric Huang1-0/+2
Currently each kfd compute partition/node is sharing the same uuid of AID, which doen't meet the CUDA spec for visible device, so corresponding XCD id for each partition in smu has been assigned to xcp, and exposed to kfd topology. v2: add NULL check (Lijo) Signed-off-by: Eric Huang <jinhuieric.huang@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-15drm/amd/display: Use boolean context for pointer null checksQianfeng Rong4-4/+4
Replace "out == 0" with "!out" for pointer comparison to improve code readability and conform to coding style. Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-15drm/amd/display: Remove redundant semicolonsLiao Yuanhong1-1/+0
Remove unnecessary semicolons. Fixes: dda4fb85e433 ("drm/amd/display: DML changes for DCN32/321") Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-15drm/radeon: replace min/max nesting with clamp()Xichao Zhao1-2/+2
The clamp() macro explicitly expresses the intent of constraining a value within bounds.Therefore, replacing min(max(a, b), c) and max(min(a,b),c) with clamp(val, lo, hi) can improve code readability. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-15drm/bridge: display-connector: don't set OP_DETECT for DisplayPortsDmitry Baryshkov1-1/+2
Detecting the monitor for DisplayPort targets is more complicated than just reading the HPD pin level: it requires reading the DPCD in order to check what kind of device is attached to the port and whether there is an actual display attached. In order to let DRM framework handle such configurations, disable DRM_BRIDGE_OP_DETECT for dp-connector devices, letting the actual DP driver perform detection. This still keeps DRM_BRIDGE_OP_HPD enabled, so it is valid for the bridge to report HPD events. Currently inside the kernel there are only two targets which list hpd-gpios for dp-connector devices: arm64/qcom/qcs6490-rb3gen2 and arm64/qcom/sa8295p-adp. Both should be fine with this change. Cc: Bjorn Andersson <andersson@kernel.org> Cc: Konrad Dybcio <konradybcio@kernel.org> Cc: linux-arm-msm@vger.kernel.org Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250802-dp-conn-no-detect-v1-1-2748c2b946da@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-08-15drm/panfrost: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus1-2/+0
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250704075411.3218059-1-sakari.ailus@linux.intel.com
2025-08-15drm/i915/bo: remove unnecessary includeJani Nikula1-1/+1
intel_bo.c doesn't need intel_display_types.h for anything. Remove. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20250814132445.1573035-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-15drm/panthor: Add support for Mali-Gx20 and Mali-Gx25 GPUsKarunika Choo2-0/+20
This patch adds firmware binary and GPU model naming support for Mali-Gx20 and Mali-Gx25 GPUs. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250807162633.3666310-8-karunika.choo@arm.com
2025-08-15drm/panthor: Make MMU cache maintenance use FLUSH_CACHES commandKarunika Choo1-0/+33
As the FLUSH_MEM and FLUSH_PT MMU_AS commands are deprecated in GPUs from Mali-Gx20 onwards, this patch adds support for performing cache maintenance via the FLUSH_CACHES command in GPU_COMMAND in place of FLUSH_MEM and FLUSH_PT commands. Mali-Gx10 and Mali-Gx15 GPUs also has support for the FLUSH_CACHES command and will also use this by default going forward. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250807162633.3666310-7-karunika.choo@arm.com
2025-08-15drm/panthor: Serialize GPU cache flush operationsKarunika Choo1-0/+7
In certain scenarios, it is possible for multiple cache flushes to be requested before the previous one completes. This patch introduces the cache_flush_lock mutex to serialize these operations and ensure that any requested cache flushes are completed instead of dropped. Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Co-developed-by: Dennis Tsiang <dennis.tsiang@arm.com> Signed-off-by: Dennis Tsiang <dennis.tsiang@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250807162633.3666310-6-karunika.choo@arm.com
2025-08-15drm/panthor: Add support for Mali-Gx15 family of GPUsKarunika Choo3-0/+19
Mali-Gx15 introduces a new GPU_FEATURES register that provides information about GPU-wide supported features. The register value will be passed on to userspace via gpu_info. Additionally, Mali-Gx15 presents an 'Immortalis' naming variant depending on the shader core count and presence of Ray Intersection feature support. This patch adds: - support for correctly identifying the model names for Mali-Gx15 GPUs. - arch 11.8 FW binary support Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250807162633.3666310-5-karunika.choo@arm.com
2025-08-15drm/panthor: Add support for Mali-G710, Mali-G510 and Mali-G310Karunika Choo2-0/+8
This patch adds GPU model name and FW binary support for Mali-G710, Mali-G510, and Mali-G310. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250807162633.3666310-4-karunika.choo@arm.com
2025-08-15drm/panthor: Simplify getting the GPU model nameKarunika Choo1-44/+17
This patch replaces the panthor_model structure with a simple switch case based on the product_id which is in the format of: ((arch_major << 24) | product_major) This simplifies comparison and allows extending of the function to accommodate naming differences based on supported GPU features. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250807162633.3666310-3-karunika.choo@arm.com
2025-08-15drm/panthor: Add panthor_hw and move gpu_info initialization into itKarunika Choo5-95/+130
This patch introduces panthor_hw and moves the initialization of the gpu_info struct into panthor_hw.c in preparation of handling future GPU register and naming changes. Future GPU support can be added by extending panthor_gpu_info_init() with the necessary register reads behind GPU architecture version guards if the change is minor. For more complex changes, the function can be forked and the appropriate function will need to be called based on the GPU architecture version. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250807162633.3666310-2-karunika.choo@arm.com
2025-08-15drm/i915/audio: drop irq enabled check from LPE audio setupJani Nikula1-7/+4
There shouldn't be anything requiring irqs to be enabled at the point of LPE audio setup. Regardless, we've never hit the warning, as irqs are always enabled at the time LPE audio is initialized. Drop the superfluous warning, and the dependency on i915_drv.h. Fix style a bit while at it. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://lore.kernel.org/r/20250801122832.249985-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-15drm/i915/active: Use try_cmpxchg64() in __active_lookup()Uros Bizjak1-3/+2
Replace this pattern in __active_lookup(): cmpxchg64(*ptr, old, new) == old ... with the simpler and faster: try_cmpxchg64(*ptr, &old, new) The x86 CMPXCHG instruction returns success in the ZF flag, so this change saves a compare after the CMPXCHG. The patch also improves the explanation of what the code really does. cmpxchg64() will *succeed* for the winner of the race and try_cmpxchg64() nicely documents this fact. No functional change intended. Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tursulin@ursulin.net> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250814064326.95519-1-tvrtko.ursulin@igalia.com
2025-08-15drm/bridge: analogix_dp: Fix bailout for devm_drm_bridge_alloc()Liu Ying1-2/+2
devm_drm_bridge_alloc() returns ERR_PTR on failure instead of a NULL pointer, so use IS_ERR() to check the returned pointer. While at it, on failure, return ERR_CAST(dp) instead of ERR_PTR(-ENOMEM) in order not to depend on devm_drm_bridge_alloc() error code implementation. Fixes: 48f05c3b4b70 ("drm/bridge: analogix_dp: Use devm_drm_bridge_alloc() API") Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20250806095224.527938-1-victor.liu@nxp.com
2025-08-15gpu: nova-core: register: add support for relative array registersAlexandre Courbot4-6/+248
Add support for declaring arrays of registers available from a variable base. This is effectively a combination of the relative and array registers features. nova-core does not make much use of this yet, but it will become helpful to have for GSP boot. Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-19-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15gpu: nova-core: falcon: use register arrays for FUSE registersAlexandre Courbot2-21/+20
FUSE registers are an array of 16 consecutive registers. Use the newly available register array feature to define them properly and improve the code using them. Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-18-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15gpu: nova-core: register: add support for register arraysAlexandre Courbot3-8/+204
Having registers that can be interpreted identically in a contiguous I/O area (or at least, following a given stride) is a common way to organize registers, and is used by NVIDIA hardware. Thus, add a way to simply and safely declare such a layout using the register!() macro. Build-time bound-checking is effective for array accesses performed with a constant. For cases where the index cannot be known at compile time, `try_` variants of the accessors are also made available that return `EINVAL` if the access is out-of-bounds. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-17-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15gpu: nova-core: falcon: add distinct base address for PFALCON2Alexandre Courbot4-8/+23
Falcon engines have two distinct register bases: `PFALCON` and `PFALCON2`. So far we assumed that `PFALCON2` was located at `PFALCON + 0x1000` because that is the case of most engines, but there are exceptions (NVDEC uses `0x1c00`). Fix this shortcoming by leveraging the redesigned relative registers definitions to assign a distinct `PFalcon2Base` base address to each falcon engine. Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-16-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15gpu: nova-core: register: redesign relative registersAlexandre Courbot6-96/+212
The relative registers are currently very unsafe to use: callers can specify any constant as the base address for access, meaning they can effectively interpret any I/O address as any relative register. Ideally, valid base addresses for a family of registers should be explicitly defined in the code, and could only be used with the relevant registers This patch changes the relative register declaration from e.g.: register!(CPU_CTL @ +0x0000010, "CPU core control" { 0:0 start as bool, "Start the CPU core"; }); into: register!(CPU_CTL @ CpuCtlBase[0x10], "CPU core control" { 0:0 start as bool, "Start the CPU core"; }); Where `CpuCtlBase` is the name of a ZST used as a parameter of the `RegisterBase<>` trait to define a trait unique to a class of register. This specialized trait is then implemented for every type that provides a valid base address, enabling said types to be passed as the base address provider for the register's I/O accessor methods. This design thus makes it impossible to pass an unexpected base address to a relative register, and, since the valid bases are all known at compile-time, also guarantees that all I/O accesses are done within the valid bounds of the I/O range. [acourbot@nvidia.com: add example in the commit log.] Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-15-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15gpu: nova-core: register: use #[inline(always)] for all methodsAlexandre Courbot1-8/+8
These methods should always be inlined, so use the strongest compiler hint that exists to maximize the chance they will indeed be. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-14-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15gpu: nova-core: register: split @io rule into fixed and relative versionsAlexandre Courbot1-6/+6
We used the same @io rule with different patterns to define both the fixed and relative I/O accessors. This can be confusing as the matching rules are very similar. Since all call sites know which version they want to call, split @io into @io_fixed and @io_relative to remove any ambiguity. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-13-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15gpu: nova-core: register: generate correct `Default` implementationAlexandre Courbot1-3/+23
The `Default` implementation of a register should be the aggregate of the default values of all its fields, and not simply be zeroed. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-12-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15gpu: nova-core: register: improve `Debug` implementationAlexandre Courbot1-10/+15
Now that we have an internal rule to dispatch field information where needed, use it to generate a better `Debug` implementation where the raw hexadecimal value of the register is displayed, as well as the `Debug` values of its individual fields. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-11-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15gpu: nova-core: register: add fields dispatcher internal ruleAlexandre Courbot1-10/+32
Fields are complex and cumbersome to match in a rule, and were only captured in order to generate the field accessors. However, there are other places (like the `Debug` and `Default` implementations) where we would benefit from having access to at least some of the field information, but refrained from doing so because it would have meant matching the whole fields in a rule more complex than we need. Introduce a new `@fields_dispatcher` internal rule that captures all the field information and passes it to `@field_accessors`. It does not provide any functional change in itself, but allows us to reuse the captured field information partially to provide better `Debug` and `Default` implementations in following patches. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-10-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15gpu: nova-core: register: add missing doccomments for fixed registers I/O ↵Alexandre Courbot1-0/+4
accessors Add the missing doccomments for these accessors, as having a bit of inline documentation is always helpful. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-9-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15gpu: nova-core: register: fix documentation and indentationAlexandre Courbot1-25/+9
Fix a few documentation inconsistencies, and harmonize indentation where possible. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-8-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15gpu: nova-core: register: move OFFSET declaration to I/O impl blockAlexandre Courbot1-10/+9
The OFFSET const is an I/O property, and having to pass it to the @common rule makes it impossible to make I/O optional, as we want to get to eventually. Thus, move OFFSET to the I/O impl block so it is not needed by the @common rule anymore. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-7-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15gpu: nova-core: register: remove `try_` accessors for relative registersAlexandre Courbot1-37/+1
Relative registers are always accessed using a literal base, meaning their validity can always be checked at compile-time. Thus remove the `try_` accessors that have no purpose. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-6-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15gpu: nova-core: register: simplify @leaf_accessor ruleAlexandre Courbot1-4/+4
The `$type` metavariable is not used in the @leaf_accessor rule, so remove it. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-5-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15gpu: nova-core: register: improve documentation for basic registersAlexandre Courbot1-11/+13
Reword parts of the documentation that were a bit heavy to read, and harmonize/fix the examples. The relative registers section is about to be redesigned and its documentation rewritten, so do not touch this part. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-4-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15gpu: nova-core: register: allow fields named `offset`Alexandre Courbot2-3/+4
`offset` is a common field name, yet using it triggers a build error due to the conflict between the uppercased field constant (which becomes `OFFSET` in this case) containing the bitrange of the field, and the `OFFSET` constant constaining the offset of the register. Fix this by adding `_RANGE` the field's range constant to avoid the name collision. [acourbot@nvidia.com: fix merge conflict due to switch from `as u32` to `u32::from`.] Reported-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-3-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15gpu: nova-core: register: add missing space in register!()Alexandre Courbot1-1/+1
A space was missing between arguments in this invocation. [acourbot@nvidia.com: use more descriptive commit title] Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-2-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15gpu: nova-core: register: minor grammar and spelling fixesJohn Hubbard1-7/+7
There is only one top-level macro in this file at the moment, but the "macros.rs" file name allows for more. Change the wording so that it will remain valid even if additional macros are added to the file. Fix a couple of spelling errors and grammatical errors, and break up a run-on sentence, for clarity. Cc: Alexandre Courbot <acourbot@nvidia.com> Cc: Danilo Krummrich <dakr@kernel.org> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250718-nova-regs-v2-1-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-15Merge tag 'drm-xe-fixes-2025-08-14' of ↵Dave Airlie5-19/+126
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes - Some more xe_migrate_access_memory fixes (Auld) - Defer buffer object shrinker write-backs and GPU waits (Thomas) - HWMON fix for clamping limits (Karthik) - SRIOV-PF: Set VF LMEM BAR size (Michal) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/aJ4MIZQurSo0uNxn@intel.com
2025-08-15Merge tag 'drm-intel-fixes-2025-08-13' of ↵Dave Airlie2-9/+13
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes - Fix the implementation of wa_18038517565 [fbc] (Vinod Govindapillai) - Do not trigger Frame Change events from frontbuffer flush [psr] (Jouni Högander) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Tvrtko Ursulin <tursulin@igalia.com> Link: https://lore.kernel.org/r/aJ0HAh06VHWVdv63@linux
2025-08-15drm/panel: novatek-nt35560: Clean up driverBrigham Campbell1-138/+60
Update driver to use the "multi" variants of MIPI functions which facilitate improved error handling and cleaner driver code. Remove information from a comment which was made obsolete by commit 994ea402c767 ("drm/panel: Rename Sony ACX424 to Novatek NT35560"), which determined that this driver supports the Novatek NT35560 panel controller. Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Brigham Campbell <me@brighamcampbell.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250731032343.1258366-4-me@brighamcampbell.com
2025-08-15drm: Add MIPI read_multi func and two write macrosBrigham Campbell1-0/+37
Create mipi_dsi_dcs_read_multi(), which accepts a mipi_dsi_multi_context struct for improved error handling and cleaner panel driver code. Create mipi_dsi_dcs_write_var_seq_multi() and mipi_dsi_generic_write_var_seq_multi() macros which allow MIPI panel drivers to write non-constant data to display controllers. Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Brigham Campbell <me@brighamcampbell.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250731032343.1258366-3-me@brighamcampbell.com
2025-08-14drm/xe/pf: Set VF LMEM BAR sizeMichał Winiarski2-0/+23
LMEM is partitioned between multiple VFs and we expect that the more VFs we have, the less LMEM is assigned to each VF. This means that we can achieve full LMEM BAR access without the need to attempt full VF LMEM BAR resize via pci_resize_resource(). Always try to set the largest possible BAR size that allows to fit the number of enabled VFs and inform the user in case the resize attempt is not successful. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20250527120637.665506-7-michal.winiarski@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 32a4d1b98e6663101fd0abfaf151c48feea7abb1) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-11 02:58:57 +0300