| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
[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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
The GPU's ROM may begin with an Init-from-ROM (IFR) header that precedes
the PCI Expansion ROM images (VBIOS). When present, the PROM shadow
method must parse this header to determine the offset where the PCI ROM
images actually begin, and adjust all subsequent reads accordingly.
On most GPUs this is not needed because either the PRAMIN shadow method
(which reads from VRAM via the display engine) succeeds first, or the IFR
microcode has already applied the ROM offset so that PROM reads
transparently skip the header. However, on GA100 neither of these
applies: GA100 has no display engine (so PRAMIN is unavailable), and the
IFR offset is not applied to PROM reads on this GPU.
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260430223838.2530778-9-ttabi@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
The NV_FUSE_STATUS_OPT_DISPLAY register is used to determine whether
the GPU has display hardware. The current code that normally reads
this register is instead hard-coded to check for GA100 vs later GPUs.
Since this function is called only on pre-Hopper GPUs, and this
if-statement applies only to GA100 and later, the check works
because GA100 is the only non-display Ampere and Ada GPU.
However, there actually is a register that can be read, so we should
use it.
Fixes: a34632482f1e ("drm/nouveau/bios/ga10[024]: initial support")
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260430223838.2530778-8-ttabi@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
When booting with GSP-RM, the FRTS data region normally needs to be
allocated. However, on GA100, this region is not used and so its
size needs to be set to zero.
The truth is that GA100 is just special, and the simplest way to
determine the proper FRTS data region size is to check for this
GPU specifically.
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Link: https://patch.msgid.link/20260430223838.2530778-7-ttabi@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
On some Nvidia GPUs (i.e. GA100), the FRTS region is not allocated
(its size is set to 0). In such cases, FWSEC-FRTS should not be run.
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Link: https://patch.msgid.link/20260430223838.2530778-6-ttabi@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
On GA100, the row remapper hardware reserves a small amount of DRAM at
the end of framebuffer for spare rows used to repair memory errors at
runtime. When an uncorrectable ECC error is detected in a DRAM row,
the row remapper redirects accesses to a spare row, transparently
repairing the fault.
The LOCAL_MEMORY_RANGE register (0x100ce0) reports the GPU's FB address
range, but its encoding rounds to 1GB boundaries. On GA100, VBIOS
originally rounded this value down, which could lose up to ~1GB of
usable FB. As a workaround, newer VBIOS instead rounds up to the next
1GB boundary and programs MMU_LOCK (registers 0x1fa82c/0x1fa830) to
mark the gap between the actual usable FB and the rounded-up range as
reserved.
OpenRM's kgspCalculateFbLayout_TU102() handles this by reading the
MMU_LOCK registers and computing the WPR top boundary as:
vbiosReservedOffset = min(mmuLockLo, vgaWorkspaceOffset)
Without this, the WPR region is placed at the top of LOCAL_MEMORY_RANGE,
which overlaps the reserved region. The booter firmware detects this
and rejects the WPR layout.
Add ga100_gsp_mmu_lock_lo() to read the MMU_LOCK range and clamp
gsp->fb.bios.addr accordingly, mirroring OpenRM's behavior.
This is a GA100-only issue. GA102 and later add the
NV_USABLE_FB_SIZE_IN_MB register which reports the correct usable FB
size directly, eliminating the need for the MMU_LOCK workaround.
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Link: https://patch.msgid.link/20260430223838.2530778-5-ttabi@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
In OpenRM's kgspCalculateFbLayout_TU102(), gspFwWprEnd is derived from
vbiosReservedOffset, which is computed as:
vbiosReservedOffset = min(mmuLockLo, vgaWorkspaceOffset)
The VGA workspace offset is one input into this calculation, not the
direct source of gspFwWprEnd. vbiosReservedOffset is the effective
top boundary for WPR2 placement, and it may be lower than the VGA
workspace when VBIOS has locked a region via MMU_LOCK.
In Nouveau, gsp->fb.bios.addr is the equivalent of vbiosReservedOffset,
while gsp->fb.bios.vga_workspace.addr corresponds to the raw VGA
workspace location. The original code assigned vga_workspace.addr to
gspFwWprEnd, which produced the correct result only because bios.addr
was always set equal to vga_workspace.addr and never adjusted.
Use gsp->fb.bios.addr for gspFwWprEnd to correctly mirror OpenRM's
layout logic, so that future adjustments to bios.addr (such as clamping
it to an MMU_LOCK boundary) are properly reflected in the WPR metadata
passed to the booter.
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Link: https://patch.msgid.link/20260430223838.2530778-4-ttabi@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
The booter-load and booter-unload firmware run on the SEC2 falcon.
During tu102_gsp_oneinit(), the booter constructor needs device->sec2
to access the SEC2 falcon.
Without the .sec2 entry, device->sec2 is NULL and this dereference
crashes during GSP-RM boot.
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Link: https://patch.msgid.link/20260430223838.2530778-3-ttabi@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Clean up the remaining IS_ERR_OR_NULL() checks in ctrl.c and rpc.c.
The underlying functions return error pointers, so IS_ERR() is
sufficient.
This affects:
- r535_gsp_rpc_ctrl() in ctrl.c
- r535_gsp_rpc_ctor() in rpc.c
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260528062451.54107-6-zenghongling@kylinos.cn
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
Replace WARN_ON(IS_ERR_OR_NULL()) with WARN_ON(IS_ERR()) in various
GSP-RM files. The underlying functions return error pointers, so
checking for NULL is redundant.
This affects:
- r535_bar_bar2_update_pde() in bar.c
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260528062451.54107-5-zenghongling@kylinos.cn
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
Clean up IS_ERR_OR_NULL() checks in the core RPC and alloc
implementation files. The underlying functions return error pointers,
so IS_ERR() is sufficient.
This affects:
- r535_gsp_rpc_rm_free() in alloc.c
- r535_gsp_rpc_rm_alloc_push() in alloc.c
- r535_gsp_msgq_recv() in rpc.c
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260528062451.54107-4-zenghongling@kylinos.cn
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
The underlying nvkm_gsp_rpc_get() function returns error pointers,
so checking for NULL with IS_ERR_OR_NULL() is redundant. Use IS_ERR()
instead.
This affects nvkm_gsp_rpc_rd().
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260528062451.54107-3-zenghongling@kylinos.cn
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
The underlying functions already return error pointers, so checking for
NULL with IS_ERR_OR_NULL() is redundant. Use IS_ERR() instead.
This affects:
- nvkm_gsp_rm_alloc_get()
- nvkm_gsp_rm_alloc()
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260528062451.54107-2-zenghongling@kylinos.cn
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
Commit "iommu: return full error code from iommu_map_sg[_atomic]()"
changed iommu_map_sgtable() to return an ssize_t and negative values
in error cases, rather than a size_t and a zero.
Update tegra_bo_iommu_map() to correctly check for errors from
iommu_map_sgtable.
Fixes: ad8f36e4b6b1 ("iommu: return full error code from iommu_map_sg[_atomic]()")
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260421-iommu_map_sgtable-return-v1-2-fb484c07d2a1@nvidia.com
|
|
Commit "iommu: return full error code from iommu_map_sg[_atomic]()"
changed iommu_map_sgtable() to return an ssize_t and negative values
in error cases, rather than a size_t and a zero.
pin_job() also was incorrectly assigning to 'int', which could cause
overflows into negative values.
Update pin_job() to correctly check for errors from iommu_map_sgtable.
Fixes: ad8f36e4b6b1 ("iommu: return full error code from iommu_map_sg[_atomic]()")
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260421-iommu_map_sgtable-return-v1-1-fb484c07d2a1@nvidia.com
|
|
The drivers/gpu/host1x/context_bus.c does not include any declaration of
host1x_context_device_bus_type, and after including "context.h" it also
showed that there are two definitions in the kernel because the extern
declaration was missing the const qualifier.
Include linux/host1x_context_bus.h and drop the wrong declaration from
context.h. While at it, also predeclare struct host1x_memory_context.
Fixes the following sparse warning:
drivers/gpu/host1x/context_bus.c:9:23: warning: symbol 'host1x_context_device_bus_type' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
[treding@nvidia.com: minor fixups, reword commit message to reflect changes]
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260123140512.609167-1-ben.dooks@codethink.co.uk
|
|
The of_for_each_phandle() macro increments the reference count of the
device node it iterates over. If the loop exits early, the reference must
be released manually.
In tegra_dc_has_output(), the function returns true immediately when a
match is found, failing to release the current node's reference.
Fix this by adding a call to of_node_put() before returning from the loop.
Fixes: c57997bce423 ("drm/tegra: sor: Add Tegra186 support")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
Acked-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260128-dc-v1-1-a88205826301@gmail.com
|
|
Without the cmu, nvdisplay will display colors that are notably darker
than intended. The vendor bootloader and the downstream display driver
enable the cmu and sets a sRGB table. Loading that table here results in
the intended colors.
Co-developed-by: Kurt Kiefer <kekiefer@gmail.com>
Signed-off-by: Kurt Kiefer <kekiefer@gmail.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Tested-by: Jasper Korten <jja2000@gmail.com>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Tested-by: Mikko Perttunen <mperttunen@nvidia.com> # Jetson AGX Xavier
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260407-tegra-drm-cmu-v4-1-2fe95f305afd@gmail.com
|
|
After device_initialize(), the embedded struct device in struct
host1x_device should be released through the device core with
put_device().
In host1x_device_add(), if host1x_device_parse_dt() fails, the current
error path frees the object directly with kfree(device). That bypasses
the normal device lifetime handling and leaks the reference held on the
embedded struct device.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fix this by using put_device() in the host1x_device_parse_dt() failure
path.
Fixes: f4c5cf88fbd50 ("gpu: host1x: Provide a proper struct bus_type")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Acked-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260413141526.2961841-1-lgs201920130244@gmail.com
|
|
In tegra_mipi_request(), when provider.np is not equal with args.np, it
returns without calling of_node_put(args.np), causing a reference leak.
Convert to use the existing goto out pattern to ensure proper cleanup.
Fixes: 767598d447aa ("gpu: host1x: mipi: Update tegra_mipi_request() to be node based")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260416-mipi-v1-1-9c027175abdf@gmail.com
|
|
Fbdev framebuffer allocation now goes through the regular ioctl call
chain. This makes tegra_fb_alloc() an internal helper function. Declare
it as static.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260421073646.144712-6-tzimmermann@suse.de
|
|
Replace the internal DRM framebuffer with a DRM client buffer. The
client buffer allocates the DRM framebuffer on a file and also uses
GEM object handles via the regular ADDFB2 interfaces.
Using client-buffer interfaces unifies framebuffer allocation for
DRM clients in user space and tegra's internal fbdev emulation. It
also simplifies the clean-up side of the fbdev emulation.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260421073646.144712-5-tzimmermann@suse.de
|
|
Replace the geometry and size calculation in tegra's fbdev emulation
with DRM format helpers. This consists of a 4CC lookup from the fbdev
parameters, format lookup, pitch calculation and size calculation.
Then allocate the GEM buffer object for the framebuffer memory from
the calculated size.
Set up mode_cmd with the calculated values just before allocating the
framebuffer. This code will later be replaced with a DRM client buffer.
Set framebuffer size fields in struct fb_info from the size stored in
the GEM buffer object instead of what has been requested. The requested
size is an estimate, while the buffer size is the exact value rounded
to the correct alignment.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260421073646.144712-4-tzimmermann@suse.de
|
|
The screen_buffer field in struct fb_info contains the kernel address
of the first byte of framebuffer memory. Do not add the display offset.
This offset only describes scrolling during scanout.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: de2ba664c30f ("gpu: host1x: drm: Add memory manager and fb")
Cc: dri-devel@lists.freedesktop.org
Cc: linux-tegra@vger.kernel.org
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260421073646.144712-3-tzimmermann@suse.de
|
|
That field already contains the value being assigned. No need to do
this twice.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 63c971af4036 ("drm/fb-helper: Allocate and release fb_info in single place")
Cc: linux-tegra@vger.kernel.org
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260421073646.144712-2-tzimmermann@suse.de
|
|
Use correct kernel-doc format and add missing nested struct entries to
eliminate kernel-doc warnings:
Warning: drivers/gpu/drm/tegra/dp.h:28 Incorrect use of kernel-doc format:
* tps3_supported:
Warning: drivers/gpu/drm/tegra/dp.h:54 struct member 'tps3_supported'
not described in 'drm_dp_link_caps'
dp.h:73: warning: Function parameter or struct member 'apply_training'
not described in 'drm_dp_link_ops'
dp.h:73: warning: Function parameter or struct member 'configure'
not described in 'drm_dp_link_ops'
dp.h:160: warning: Excess struct member 'cr' description in 'drm_dp_link'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260427184442.693768-1-rdunlap@infradead.org
|
|
In host1x_device_init(), the error teardown paths do not check
client->ops before dereferencing it, unlike the forward init paths
which correctly guard with 'client->ops &&'. This can result in a
NULL pointer dereference if client->ops is NULL.
Fix by adding the missing client->ops check in both the teardown
and teardown_late labels.
Signed-off-by: shayderrr <darknessshayder@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260517170456.84927-1-darknessshayder@gmail.com
|
|
Remove the deprecated trivial helper drm_simple_encoder_init(). Inline
the call to drm_encoder_init and add instance of
drm_encoder_funcs.
Signed-off-by: Jacob McLemore <jmclemore.lkml@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260523012824.81043-1-jmclemore.lkml@gmail.com
|
|
The helper drm_simple_encoder_init() is a trivial wrapper around
drm_encoder_init() that only provides a static drm_encoder_funcs with
.destroy set to drm_encoder_cleanup(). Open-code the initialization
with a driver-specific instance of drm_encoder_funcs and remove the
dependency on drm_simple_kms_helper.
Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Souradipto Das <souradiptodas6@gmail.com>
[treding@nvidia.com: fix issues flagged by checkpatch]
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260513100501.6468-1-souradiptodas6@gmail.com
|
|
When the fence list is empty, host1x_intr_update_hw_state()
falls through to host1x_intr_disable_syncpt_intr()
which does two MMIO writes to disable the syncpoint
interrupt and clear its status.
The ISR has already disabled and acked the interrupt
before calling host1x_intr_handle_interrupt(), making
these two writes redundant. Skip the update_hw_state()
call if no fences remain.
Measured Syncpoint wait latency (50000 samples):
Average latency: 10.6 us -> 9.4 us
99.99 pct latency: 51.90 us -> 36.58 us
Signed-off-by: Tanmay Patil <tanmayp@nvidia.com>
Acked-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260514103153.766343-3-tanmayp@nvidia.com
|
|
In host1x_syncpt_wait(), the hardware syncpoint value was loaded
initially for expiry check, and then loaded a second time to
populate the caller's value pointer. Reuse a single load for
both purposes.
After dma_fence_wait_timeout(), the previous code reloaded the syncpoint
value for the expiry check, which is only required in the timeout case.
On success (i.e., return value > 0, or return value == 0 with zero
jiffies remaining), the ISR has already cached the value before
signaling the fence. The value pointer can therefore be populated using
the cached value using host1x_syncpt_read_min() without MMIO access.
Only the timeout path requires a fresh load, move host1x_syncpt_load()
under that path.
Measured Syncpoint wait latency (50000 samples):
Average latency: 12.2 us -> 10.6 us
99.99 pct latency: 62.96 us -> 51.90 us
Signed-off-by: Tanmay Patil <tanmayp@nvidia.com>
Acked-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260514103153.766343-2-tanmayp@nvidia.com
|
|
When a buffer object is pinned via host1x_bo_pin() with a cache, the
resulting mapping is kept in the cache so it can be reused on subsequent
pins. Each mapping held a reference to the underlying host1x_bo (taken
in tegra_bo_pin / gather_bo_pin), so as long as a mapping was cached,
the bo itself could not be freed.
However, the only way to remove the cached mapping was through the free
path of the buffer object. This meant that if a bo got cached, it could
never get freed again.
Resolve the circularity by holding a weak reference to the bo from the
cache side. This is done by having the .pin callbacks not bump the bo's
refcount -- instead the common Host1x bo code does so, except for the
cache reference.
Also move the remove-cache-mapping-on-free code into a common function
inside Host1x code. This is only called from the TegraDRM GEM buffers
since those are the only ones that can be cached at the moment.
Reported-by: Aaron Kling <webgeek1234@gmail.com>
Fixes: 1f39b1dfa53c ("drm/tegra: Implement buffer object cache")
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Tested-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260515-host1x-bocache-leak-v1-1-a0375f68aeab@nvidia.com
|
|
The current power management configuration causes GR2G/GR3D to malfunction
after resume. Reconfigure all PM actions to be handled within the GR*D
probe and remove operations to address this.
Fixes: 62fa0a985e2c ("drm/tegra: Enable runtime PM during probe")
Acked-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Ion Agorria <ion@agorria.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260517091450.46728-3-clamor95@gmail.com
|
|
is registered
The host1x_client_register() function is called just prior to register map
initialization loop, making the device available to userspace. This may
result in userspace attempting to submits a job before the register map is
initialized. Address this by moving register initialization before host1x
client registration.
Acked-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260517091450.46728-2-clamor95@gmail.com
|
|
Replace the manual ternary "s" pluralization with str_plural() to
simplify the code.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260521194658.366737-4-thorsten.blum@linux.dev
|
|
Replace the manual ternary "s" pluralizations with str_plural() to
simplify the code. This also corrects the "0 lanes" case.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260521194658.366737-3-thorsten.blum@linux.dev
|
|
The "gems" debugfs file is getting a little too wide for comfort. While
a lot of this is unavoidable due to the theoretical upper limits of
numbers here (e.g. size needs to be 16 chars because 2**48-1 in decimal
is 15 digits, plus one space for separation), the refcount column has a
decent 5 characters to be saved, as it can only ever contain a 10-digit
decimal number.
Reduce the refcount column's width to 11, which fulfils this requirement
with an additional space for separation.
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://patch.msgid.link/20260521-panthor-bo-reclaim-observability-v5-2-49313994da55@collabora.com
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
|
|
For fdinfo to be able to fill its evicted counter with data, panthor
needs to keep track of whether a GEM object has ever been reclaimed.
Just checking whether the pages are resident isn't enough, as newly
allocated objects also won't be resident.
Do this with a new atomic_t member on panthor_gem_object. It's increased
when an object gets evicted by the shrinker, and saturates at INT_MAX.
This means that once an object has been evicted at least once, its
reclaim counter will never return to 0.
Due to this, it's possible to distinguish evicted non-resident pages
from newly allocated non-resident pages by checking whether
reclaimed_count is != 0
Also add a new column and status flag to the panthor gems debugfs: the
column is the number of times an object has been evicted, whereas the
flag indicates whether it currently is evicted.
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://patch.msgid.link/20260521-panthor-bo-reclaim-observability-v5-1-49313994da55@collabora.com
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
|
|
Currently the intel_dp_sdp_min_guardband() accounts for AS_SDP for all
platforms that support adaptive sync SDP even for configurations where
it cannot be enabled. Instead account for adaptive sync SDP guardband
only when it is enabled.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260527041050.601735-13-ankit.k.nautiyal@intel.com
|
