drm/i915/guc: Include the GuC registers in the error state
If GuC hangs, the GuC logs might not contain enough information to
understand exactly why the hang occurred. In this case, we need to
look at the GuC HW state to try to understand where the GuC is stuck. It
is therefore useful to include the GuC HW state in the error capture.
The list of registers that are part of the GuC HW state can change based
on platform, but it is the same for all platforms from TGL to MTL so we
only need to support one version for i915.
v2: revised list
v3: remove confusing comment, use sizeof(u32) instead of 4 (John)
Jonathan Cavitt [Thu, 4 Sep 2025 19:30:42 +0000 (19:30 +0000)]
drm/i915/gt: Fix memory leak in hangcheck selftest
In active_engines, if intel_context_create fails, we need to go
backwards through all the created contexts to free/put them. However,
the way this is currently performed skips the first created context, as
if count == 1, then --count returns 0 and exits the while-loop
prematurely without performing the intel_context_put on context 0.
Fix this by post-decrementing count in the while-loop, rather than
pre-decrementing it. This change makes the prior guard against count
underflowing unnecessary, as the while-loop exits when count == 0.
Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Krzysztof Karas <krzysztof.karas@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20250904193041.12888-2-jonathan.cavitt@intel.com
drm/i915: Replace kmalloc() + copy_from_user() with memdup_user()
Replace kmalloc() followed by copy_from_user() with memdup_user() to
improve and simplify set_context_image(), and to silence the following
Coccinelle/coccicheck warning reported by memdup_user.cocci:
CACHE_MODE_0 register should be saved and restored as part
of the context, not during engine reset. Move the related
workaround (RC_OP_FLUSH_ENABLE) from rcs_engine_wa_init() to
gen6_ctx_workarounds_init() for Gen6 platforms. This ensures the WA
is applied during context initialisation.
CM0_STC_EVICT_DISABLE_LRA_SNB is also Gen6-specific, but it does
not stick when applied in context, so it remains in engine init.
CACHE_MODE_1 and CACHE_MODE_0 register should be saved and restored
as part of the context, not during engine reset. Move the related
workarounds (RC_OP_FLUSH_ENABLE, PIXEL_SUBSPAN_COLLECT_OPT_DISABLE)
from rcs_engine_wa_init() to gen7_ctx_workarounds_init() for
Gen7 platforms. This ensures the WA is applied during context
initialisation.
Sebastian Brzezinka [Mon, 11 Aug 2025 09:12:31 +0000 (09:12 +0000)]
drm/i915/gt: Relocate compression repacking WA for JSL/EHL
CACHE_MODE_0 registers should be saved and restored as part of
the context, not during engine reset. Move the related workaround
(Disable Repacking for Compression) from rcs_engine_wa_init()
to icl_ctx_workarounds_init() for Jasper Lake and Elkhart
Lake platforms. This ensures the WA is applied during context
initialisation.
BSPEC: 11322
Fixes: 0ddae025ab6c ("drm/i915: Disable compression tricks on JSL") Closes: Fixes: 0ddae025ab6c ("drm/i915: Disable compression tricks on JSL") Signed-off-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Cc: stable@vger.kernel.org # v6.13+ Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/4feaa24094e019e000ceb6011d8cd419b0361b3f.1754902406.git.sebastian.brzezinka@intel.com
Uros Bizjak [Thu, 14 Aug 2025 06:43:26 +0000 (07:43 +0100)]
drm/i915/active: Use try_cmpxchg64() in __active_lookup()
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.
Krzysztof Karas [Tue, 5 Aug 2025 11:41:42 +0000 (11:41 +0000)]
drm/i915/gt: Protect against overflow in active_engine()
It is unlikely, but possible for the first call to
intel_context_create() to fail with -ENOMEM, which would result
in entering the following code block and decrementing "count",
when it is set to 0 (initial condition in the for loop).
Protect from overflowing the variable by checking for 0 value
of "count" before entering the loop.
Krzysztof Karas [Wed, 30 Jul 2025 07:39:23 +0000 (07:39 +0000)]
drm/i915/selftests: Do not overwrite error code after intel_context_migrate_clear() call
Currently this function's error code is stored in err variable,
which, if a i915_request is present, will be immediately
overwritten by return from dma_resv_reserve_fences(). Call DMA
functions only if intel_context_migrate_clear() succeeded.
Sebastian Brzezinka [Fri, 18 Jul 2025 10:28:19 +0000 (10:28 +0000)]
drm/i915: Replace empty conditional with continue in eb_relocate_vma()
Simplifies the control flow by replacing an empty
`if (likely(offset == 0))` block with a `continue` statement. This
improves readability and avoids unnecessary nesting.
Sebastian Brzezinka [Fri, 18 Jul 2025 10:28:04 +0000 (10:28 +0000)]
drm/i915: Add braces around the else block in clflush_write32()
According to the kernel coding style, if only one branch of a
conditional statement is a single statement, braces should
still be used in both branches.
Signed-off-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20250718102752.684975-2-sebastian.brzezinka@intel.com
John Harrison [Sat, 14 Jun 2025 03:02:22 +0000 (20:02 -0700)]
drm/i915/guc: Enable CT_DEAD output in regular debug builds
There is a sporadic failure to enable CTs ocurring in CI on one
specific machine that can't be reproduced locally. The driver already
supports dumping out a whole bunch of GuC related debug info on such a
failure but only when the verbose GuC debug config option is enabled.
It would be preferable to not enable all the verbose debug output. So
just bump the CT_DEAD code to regular I915 debug level rather than GUC
debug level, at least temporarily for CI.
To prevent excessive spam in other parts of CI, also add a check
against doing a CT_DEAD dump during an error injection test. No point
in dumping large amounts of 'why did this fail' info when the fail is
deliberately induced.
v2: Revert accidentally enabling some other verbose debug output.
drm/i915/gsc: mei interrupt top half should be in irq disabled context
MEI GSC interrupt comes from i915. It has top half and bottom half.
Top half is called from i915 interrupt handler. It should be in
irq disabled context.
With RT kernel, by default i915 IRQ handler is in threaded IRQ. MEI GSC
top half might be in threaded IRQ context. generic_handle_irq_safe API
could be called from either IRQ or process context, it disables local
IRQ then calls MEI GSC interrupt top half.
This change fixes A380/A770 GPU boot hang issue with RT kernel.
Fixes: 1e3dc1d8622b ("drm/i915/gsc: add gsc as a mei auxiliary device") Tested-by: Furong Zhou <furong.zhou@intel.com> Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Junxiao Chang <junxiao.chang@intel.com> Link: https://lore.kernel.org/r/20250425151108.643649-1-junxiao.chang@intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Closer analysis of CI results history has revealed a dependency of the
error on a few IGT tests, namely:
- igt@api_intel_allocator@fork-simple-stress-signal,
- igt@api_intel_allocator@two-level-inception-interruptible,
- igt@gem_linear_blits@interruptible,
- igt@prime_mmap_coherency@ioctl-errors,
which invisibly trigger the issue, then exhibited with first driver unbind
attempt.
All of the above tests perform actions which are actively interrupted with
signals. Further debugging has allowed to narrow that scope down to
DRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring
submission, in particular.
If successful then that function, or its execlists or GuC submission
equivalent, is supposed to be called only once per GEM context engine,
followed by raise of a flag that prevents the function from being called
again. The function is expected to unwind its internal errors itself, so
it may be safely called once more after it returns an error.
In case of ring submission, the function first gets a reference to the
engine's legacy timeline and then allocates a VMA. If the VMA allocation
fails, e.g. when i915_vma_instance() called from inside is interrupted
with a signal, then ring_context_alloc() fails, leaving the timeline held
referenced. On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the
timeline is got, and only that last one is put on successful completion.
As a consequence, the legacy timeline, with its underlying engine status
page's VMA object, is still held and not released on driver unbind.
Get the legacy timeline only after successful allocation of the context
engine's VMA.
v2: Add a note on other submission methods (Krzysztof Karas):
Both execlists and GuC submission use lrc_alloc() which seems free
from a similar issue.
Fixes: 75d0a7f31eec ("drm/i915: Lift timeline into intel_context") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12061 Cc: Chris Wilson <chris.p.wilson@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20250611104352.1014011-2-janusz.krzysztofik@linux.intel.com
Arnd Bergmann [Fri, 20 Jun 2025 11:36:38 +0000 (13:36 +0200)]
drm/i915: reduce stack usage in igt_vma_pin1()
The igt_vma_pin1() function has a rather high stack usage, which gets
in the way of reducing the default warning limit:
In file included from drivers/gpu/drm/i915/i915_vma.c:2285:
drivers/gpu/drm/i915/selftests/i915_vma.c:257:12: error: stack frame size (1288) exceeds limit (1280) in 'igt_vma_pin1' [-Werror,-Wframe-larger-than]
There are two things going on here:
- The on-stack modes[] array is really large itself and gets constructed
for every call, using around 1000 bytes itself depending on the configuration.
- The call to i915_vma_pin() gets inlined and adds another 200 bytes for
the i915_gem_ww_ctx structure since commit 7d1c2618eac5 ("drm/i915: Take
reservation lock around i915_vma_pin.")
The second one is easy enough to change, by moving the function into the
appropriate .c file. Since it is already large enough to not always be
inlined, this seems like a good idea regardless, reducing both the code size
and the internal stack usage of each of its 67 callers.
Arnd Bergmann [Fri, 20 Jun 2025 11:18:18 +0000 (13:18 +0200)]
drm/i915: fix build error some more
An earlier patch fixed a build failure with clang, but I still see the
same problem with some configurations using gcc:
drivers/gpu/drm/i915/i915_pmu.c: In function 'config_mask':
include/linux/compiler_types.h:568:38: error: call to '__compiletime_assert_462' declared with attribute error: BUILD_BUG_ON failed: bit > BITS_PER_TYPE(typeof_member(struct i915_pmu, enable)) - 1
drivers/gpu/drm/i915/i915_pmu.c:116:3: note: in expansion of macro 'BUILD_BUG_ON'
116 | BUILD_BUG_ON(bit >
As I understand it, the problem is that the function is not always fully
inlined, but the __builtin_constant_p() can still evaluate the argument
as being constant.
Marking it as __always_inline so far works for me in all configurations.
Fixes: 686d773186bf ("drm/i915/pmu: Fix build error with GCOV and AutoFDO enabled") Fixes: a644fde77ff7 ("drm/i915/pmu: Change bitmask of enabled events to u32") Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20250620111824.3395007-1-arnd@kernel.org Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tzung-Bi Shih [Thu, 12 Jun 2025 08:30:23 +0000 (08:30 +0000)]
drm/i915/pmu: Fix build error with GCOV and AutoFDO enabled
i915_pmu.c may fail to build with GCOV and AutoFDO enabled.
../drivers/gpu/drm/i915/i915_pmu.c:116:3: error: call to '__compiletime_assert_487' declared with 'error' attribute: BUILD_BUG_ON failed: bit > BITS_PER_TYPE(typeof_member(struct i915_pmu, enable)) - 1
116 | BUILD_BUG_ON(bit >
| ^
Here is a way to reproduce the issue:
$ git checkout v6.15
$ mkdir build
$ ./scripts/kconfig/merge_config.sh -O build -n -m <(cat <<EOF
CONFIG_DRM=y
CONFIG_PCI=y
CONFIG_DRM_I915=y
CONFIG_AUTOFDO_CLANG=y
EOF
)
$ PATH=${PATH}:${HOME}/llvm-20.1.5-x86_64/bin make LLVM=1 O=build \
olddefconfig
$ PATH=${PATH}:${HOME}/llvm-20.1.5-x86_64/bin make LLVM=1 O=build \
CLANG_AUTOFDO_PROFILE=...PATH_TO_SOME_AFDO_PROFILE... \
drivers/gpu/drm/i915/i915_pmu.o
Although not super sure what happened, by reviewing the code, it should
depend on `__builtin_constant_p(bit)` directly instead of assuming
`__builtin_constant_p(config)` makes `bit` a builtin constant.
Also fix a nit, to reuse the `bit` local variable.
Jesus Narvaez [Wed, 28 May 2025 23:05:51 +0000 (16:05 -0700)]
drm/i915/guc: Handle race condition where wakeref count drops below 0
There is a rare race condition when preparing for a reset where
guc_lrc_desc_unpin() could be in the process of deregistering a context
while a different thread is scrubbing outstanding contexts and it alters
the context state and does a wakeref put. Then, if there is a failure
with deregister_context(), a second wakeref put could occur. As a result
the wakeref count could drop below 0 and fail an INTEL_WAKEREF_BUG_ON()
check.
Therefore if there is a failure with deregister_context(), undo the
context state changes and do a wakeref put only if the context was set
to be destroyed earlier.
v2: Expand comment to better explain change. (Daniele)
v3: Removed addition to the original comment. (Daniele)
Fixes: 2f2cc53b5fe7 ("drm/i915/guc: Close deregister-context race against CT-loss") Signed-off-by: Jesus Narvaez <jesus.narvaez@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Mousumi Jana <mousumi.jana@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://lore.kernel.org/r/20250528230551.1855177-1-jesus.narvaez@intel.com
Jesus Narvaez [Wed, 14 May 2025 22:52:24 +0000 (15:52 -0700)]
drm/i915/guc: Check if expecting reply before decrementing outstanding_submission_g2h
When sending a H2G message where a reply is expected in
guc_submission_send_busy_loop(), outstanding_submission_g2h is
incremented before the send. However, if there is an error sending the
message, outstanding_submission_g2h is decremented without checking if a
reply is expected.
Therefore, check if reply is expected when there is a failure before
decrementing outstanding_submission_g2h.
Fixes: 2f2cc53b5fe7 ("drm/i915/guc: Close deregister-context race against CT-loss") Signed-off-by: Jesus Narvaez <jesus.narvaez@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Mousumi Jana <mousumi.jana@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://lore.kernel.org/r/20250514225224.4142684-1-jesus.narvaez@intel.com
Joonas Lahtinen [Wed, 28 May 2025 07:20:17 +0000 (10:20 +0300)]
Merge drm/drm-next into drm-intel-gt-next
Need to pull in a67221b5eb8d ("drm/i915/dp: Return min bpc supported by source instead of 0")
in order to fix build breakage on GCC 9.4.0 (from Ubuntu 20.04).
The IS_DGFX check was put in place because error capture of buffer
objects is expected to be broken on devices with VRAM.
Userspace fix[1] to the impacted media driver has been submitted, merged
and a new driver release is out as 25.2.3 where the capture flag is
dropped on DG1 thus unblocking the usage of media driver on DG1.
Dan Carpenter [Fri, 23 May 2025 16:07:58 +0000 (19:07 +0300)]
drm/nouveau/tegra: Fix error pointer vs NULL return in nvkm_device_tegra_resource_addr()
The nvkm_device_tegra_resource() function returns a mix of error pointers
and NULL. The callers only expect it to return NULL on error. Change it
to only return NULL.
Dave Airlie [Fri, 23 May 2025 21:43:11 +0000 (07:43 +1000)]
Merge tag 'drm-intel-next-fixes-2025-05-22' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-next
- Fix for Thunderbolt sink disconnect on MTL/ARL/LNL
- Fix for DDI port clock select mask on PTL+
- Add error checks for alloc_ordered_workqueue() and alloc_workqueue() in display
Aradhya Bhatia [Fri, 16 May 2025 14:19:02 +0000 (14:19 +0000)]
drm/xe/guc: Make creation of SLPC debugfs files conditional
Platforms that do not support SLPC are exempted from the GuC PC support.
The GuC PC does not get initialized, and neither do its BOs get created.
This causes a problem because the GuC PC debugfs file is still being
created. Whenever the file is attempted to read, it causes a NULL
pointer dereference on the supposed BO of the GuC PC.
So, make the creation of SLPC debugfs files conditional to when SLPC
features are supported.
Fixes: aaab5404b16f ("drm/xe: Introduce GuC PC debugfs") Suggested-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@intel.com> Link: https://lore.kernel.org/r/20250516141902.5614-1-aradhya.bhatia@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
(cherry picked from commit 17486cf3df5320752cc67ee8bcb2379d1b9de76c) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Haoxiang Li [Fri, 16 May 2025 12:16:54 +0000 (15:16 +0300)]
drm/i915/display: Add check for alloc_ordered_workqueue() and alloc_workqueue()
Add check for the return value of alloc_ordered_workqueue()
and alloc_workqueue(). Furthermore, if some allocations fail,
cleanup works are added to avoid potential memory leak problem.
Imre Deak [Mon, 19 May 2025 13:34:17 +0000 (16:34 +0300)]
drm/i915/dp_mst: Work around Thunderbolt sink disconnect after SINK_COUNT_ESI read
Due to a problem in the iTBT DP-in adapter's firmware the sink on a TBT
link may get disconnected inadvertently if the SINK_COUNT_ESI and the
DP_LINK_SERVICE_IRQ_VECTOR_ESI0 registers are read in a single AUX
transaction. Work around the issue by reading these registers in
separate transactions.
The issue affects MTL+ platforms and will be fixed in the DP-in adapter
firmware, however releasing that firmware fix may take some time and is
not guaranteed to be available for all systems. Based on this apply the
workaround on affected platforms.
Imre Deak [Mon, 12 May 2025 14:26:00 +0000 (17:26 +0300)]
drm/i915/ptl: Use everywhere the correct DDI port clock select mask
The PTL XELPDP_PORT_CLOCK_CTL register XELPDP_DDI_CLOCK_SELECT field's
size is 5 bits vs. the earlier platforms where its size is 4 bits. Make
sure the field is read-out/programmed everywhere correctly, according to
the above.
Dave Airlie [Mon, 19 May 2025 01:05:57 +0000 (11:05 +1000)]
Merge tag 'drm-msm-next-2025-05-16' of https://gitlab.freedesktop.org/drm/msm into drm-next
Updates for v6.16
CI:
- uprev mesa
GPU:
- ACD (Adaptive Clock Distribution) support for X1-85. This is required
enable the higher frequencies.
- Drop fictional `address_space_size`. For some older devices, the address
space size is limited to 4GB to avoid potential 64b rollover math problems
in the fw. For these, an `ADRENO_QUIRK_4GB_VA` quirk is added. For
everyone else we get the address space size from the SMMU `ias` (input
address sizes), which is usually 48b.
- Improve robustness when GMU HFI responses time out
- Fix crash when throttling GPU immediately during boot
- Fix for rgb565_predicator on Adreno 7c3
- Remove `MODULE_FIRMWARE()`s for GPU, the GPU can load the firmware after
probe and having partial set of fw (ie. sqe+gmu but not zap) causes problems
MDSS:
- Added SAR2130P support to MDSS driver
DPU:
- Changed to use single CTL path for flushing on DPU 5.x+
- Improved SSPP allocation code to allow sharing of SSPP between planes
- Enabled SmartDMA on SM8150, SC8180X, SC8280XP, SM8550
- Added SAR2130P support
- Disabled DSC support on MSM8937, MSM8917, MSM8953, SDM660
- Misc fixes
DP:
- Switch to use new helpers for DP Audio / HDMI codec handling
- Fixed LTTPR handling
DSI:
- Added support for SA8775P
- Added SAR2130P support
MDP4:
- Fixed LCDC / LVDS controller on
HDMI:
- Switched to use new helpers for ACR data
- Fixed old standing issue of HPD not working in some cases
Ben Skeggs [Mon, 3 Feb 2025 22:55:17 +0000 (08:55 +1000)]
drm/nouveau/kms: add support for GB20x
Adds basic support for the new display classes available on GB20x GPUs.
Most of the changes here deal with HW method moves, with the only other
change of note being tweaks to skip allocation of CTXDMA objects, which
aren't required on Blackwell display.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Mon, 3 Mar 2025 15:56:03 +0000 (01:56 +1000)]
drm/dp: add option to disable zero sized address only transactions.
Some older NVIDIA and some newer NVIDIA hardware/firmware seems to
have issues with address only transactions (firmware rejects them).
Add an option to the core drm dp to avoid address only transactions,
This just puts the MOT flag removal on the last message of the transfer
and avoids the start of transfer transaction.
This with the flag set in nouveau, allows eDP probing on GB203 device.
Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Mon, 3 Feb 2025 22:54:57 +0000 (08:54 +1000)]
drm/nouveau: add support for GB20x
This commit adds support for the GB20x GPUs found on GeForce RTX 50xx
series boards.
Beyond a few miscellaneous register moves and HW class ID plumbing,
this reuses most of the code added to support GH100/GB10x.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Tue, 25 Feb 2025 21:49:00 +0000 (07:49 +1000)]
drm/nouveau/gsp: add hal for fifo.chan.doorbell_handle
The doorbell register on GB20x GPUs has additional fields.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Mon, 25 Nov 2024 00:27:02 +0000 (10:27 +1000)]
drm/nouveau: add support for GB10x
This commit enables basic support for the GB100/GB102 Blackwell GPUs.
Beyond HW class ID plumbing there's very little change here vs GH100.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Wed, 19 Jun 2024 04:23:04 +0000 (14:23 +1000)]
drm/nouveau/gf100-: track chan progress with non-WFI semaphore release
From VOLTA_CHANNEL_GPFIFO_A onwards, HW no longer updates the GET/GP_GET
pointers in USERD following channel progress, but instead updates on a
timer for compatibility, and SW is expected to implement its own method
of tracking channel progress (typically via non-WFI semaphore release).
Nouveau has been making use of the compatibility mode up until now,
however, from BLACKWELL_CHANNEL_GPFIFO_A HW no longer supports USERD
writeback at all.
Allocate a per-channel buffer in system memory, and append a non-WFI
semaphore release to the end of each push buffer segment to simulate
the pointers previously read from USERD.
This change is implemented for Fermi (which is the first to support non-
WFI semaphore release) onwards, as readback from system memory is likely
faster than BAR1 reads.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Wed, 19 Jun 2024 04:15:22 +0000 (14:15 +1000)]
drm/nouveau/nv50-: separate CHANNEL_GPFIFO handling out from CHANNEL_DMA
Primarily a cleanup to allow for changes in newer CHANNEL_GPFIFO classes
to be more easily implemented.
Compared to the prior implementation, this submits userspace push buffer
segments as subroutines and uses the NV_RAMUSERD_TOP_LEVEL_GET registers
to track the main (kernel) push buffer progress.
Fixes a number of sporadic failures seen during piglit runs.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Tue, 11 Mar 2025 08:21:19 +0000 (18:21 +1000)]
drm/nouveau: add helper functions for allocating pinned/cpu-mapped bos
Replace some awkward sequences that are repeated in a number of places
with helper functions.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Mon, 25 Nov 2024 00:21:18 +0000 (10:21 +1000)]
drm/nouveau: add support for GH100
This commit enables basic support for Hopper GPUs, and is intended
primarily as a base supporting Blackwell GPUs, which reuse most of
the code added here.
Advanced features such as Confidential Compute are not supported.
Beyond a few miscellaneous register moves and HW class ID plumbing,
the bulk of the changes implemented here are to support the GSP-RM
boot sequence used on Hopper/Blackwell GPUs, as well as a new page
table layout.
There should be no changes here that impact prior GPUs.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Co-developed-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Fri, 21 Mar 2025 03:35:17 +0000 (13:35 +1000)]
drm/nouveau: improve handling of 64-bit BARs
GPUs exist now with a 64-bit BAR0, which mean that BAR1 and BAR2's
indices (as passed to pci_resource_len() etc) are bumped up by one.
Modify nvkm_device.resource_addr/size() to take an enum instead of
an integer bar index, and take IORESOURCE_MEM_64 into account when
translating to the "raw" bar id.
[airlied: fixup ERR_PTR] Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Fri, 7 Feb 2025 04:16:11 +0000 (14:16 +1000)]
drm/nouveau/gv100-: switch to volta semaphore methods
HOPPER_CHANNEL_GPFIFO_A removes the SEMAPHORE[A-D] methods that are
currently used by nouveau to implement fences on GF100 and newer.
Switch to the newer SEM methods available from VOLTA_CHANNEL_GPFIFO,
which are also available on the Hopper/Blackwell host classes.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 8 May 2025 19:21:17 +0000 (05:21 +1000)]
drm/nouveau/gsp: support deeper page tables in COPY_SERVER_RESERVED_PDES
Use data from 'struct nvkm_vmm_page/desc' to determine which PDEs need
to be mirrored to RM instead of hardcoded values for pre-Hopper page
tables.
Needed to support Hopper/Blackwell.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 8 May 2025 00:02:49 +0000 (10:02 +1000)]
drm/nouveau/gsp: init client VMMs with NV0080_CTRL_DMA_SET_PAGE_DIRECTORY
The current code using NV90F1_CTRL_CMD_VASPACE_COPY_SERVER_RESERVED_PDES
not only requires changes to support the new page table layout used on
Hopper/Blackwell GPUs, but is also broken in that it always mirrors the
PDEs used for virtual address 0, rather than the area reserved for RM.
This works fine for the non-NVK case where the kernel has full control
of the VMM layout and things end up in the right place, but NVK puts
its kernel reserved area much higher in the address space.
Fixing the code to work at any VA is not enough as some parts of RM want
the reserved area in a specific location, and NVK would then hit other
assertions in RM instead.
Fortunately, it appears that RM never needs to allocate anything within
its reserved area for DRM clients, and the COPY_SERVER_RESERVED_PDES
control call primarily serves to allow RM to locate the root page table
when initialising a channel's instance block.
Flag VMMs allocated by the DRM driver as externally owned, and use
NV0080_CTRL_CMD_DMA_SET_PAGE_DIRECTORY to inform RM of the root page
table in a similar way to NVIDIA's UVM driver.
The COPY_SERVER_RESERVED_PDES paths are kept for the golden context
image and gr scrubber channel, where RM needs the reserved area.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 13 Feb 2025 08:17:53 +0000 (18:17 +1000)]
drm/nouveau/gsp: fetch level shift and PDE from BAR2 VMM
When mirroring BAR2 page tables to RM, we need to know the level shift
for the root page table (which is currently hardcoded), as well as the
raw PDE value (which is currently hardcoded in GP1xx-AD1xx format).
In order to support GH100/GBxxx, modify the code to determine the page
shift from per-GPU info in nvkm_vmm_page, as well as read the relevant
PDE back from the root page table rather than recalculating it.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Wed, 12 Feb 2025 21:42:28 +0000 (07:42 +1000)]
drm/nouveau/mmu: bump up the maximum page table depth
GH100/GBxxx have 6-level page tables.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 30 Jan 2025 07:28:02 +0000 (17:28 +1000)]
drm/nouveau/instmem: add hal for set_bar0_window_addr()
GH100/GBxxx have moved the register that controls where in VRAM the
the BAR0 NV_PRAMIN window points.
Add a HAL for this, as the BAR0 window is needed for BAR2 bootstrap.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 30 Jan 2025 15:56:33 +0000 (01:56 +1000)]
drm/nouveau/pci: add PRI address of config space mirror to nvkm_pci_func
These registers have moved on GH100/GBxxx, and the GSP-RM init code uses
hardcoded values from earlier GPUs to fill GspSystemInfo.
Replace the per-GPU accessors in nvkm_pci_func with region info, and use
it when initialising GspSystemInfo.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:37 +0000 (13:02 +1000)]
drm/nouveau/gsp: add support for 570.144
Add r570-specific HAL routines, and support loading of GSP-RM version
570.144 if firmware is available.
There should be no impact on r535, or non-GSP paths.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Mon, 31 Mar 2025 19:22:41 +0000 (05:22 +1000)]
drm/nouveau/gsp: add hal for gsp.sr_data_size()
570.86.15 uses a slightly different calculation for the size of the
sysmem buffer needed to store GSP-RM's vidmem data across suspend.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:39 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for disp.chan.dmac_alloc()
565.57.01 has incompatible changes to
NV50VAIO_CHANNELDMA_ALLOCATION_PARAMETERS.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:39 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for fifo.rc_triggered()
565.57.01 has incompatible changes to rpc_rc_triggered_v17_02.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:38 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for fifo.rsvd_chids
555.42.02 reserves some CHIDs for internal use.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Wed, 20 Nov 2024 02:59:53 +0000 (12:59 +1000)]
drm/nouveau/gsp: add hal for fifo.chan.alloc
570.86.16 has incompatible changes to NV_CHANNEL_ALLOC_PARAMS.
At the same time, remove the duplicated channel allocation code from
golden context init.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:38 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for disp.dp.get_caps()
555.42.02 has incompatible changes to NV0073_CTRL_CMD_DP_GET_CAPS.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:38 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for disp.get_active()
555.42.02 has incompatible changes to NV0073_CTRL_CMD_SYSTEM_GET_ACTIVE.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:38 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for disp.get_connect_state()
555.42.02 has incompatible changes to
NV0073_CTRL_CMD_SYSTEM_GET_CONNECT_STATE.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:38 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for disp.get_supported()
555.42.02 has incompatible changes to
NV0073_CTRL_CMD_SYSTEM_GET_SUPPORTED.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Wed, 29 Jan 2025 00:29:40 +0000 (10:29 +1000)]
drm/nouveau/gsp: add hals for fbsr.suspend/resume()
555.42.02 has incompatible changes to FBSR.
At the same time, move the calling of FBSR functions from the instmem
subdev's suspend/resume paths, to GSP's. This is needed to fix ordering
issues that arise from changes to FBSR in newer RM versions.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:38 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for gsp.set_rmargs()
555.42.02 has incompatible changes to GSP_ARGUMENTS_CACHED.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:38 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for gr.get_ctxbufs_info()
NV2080_CTRL_CMD_INTERNAL_STATIC_KGR_GET_CONTEXT_BUFFERS_INFO has
incompatible changes in 550.40.07.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:38 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for fifo.ectx_size()
NV2080_CTRL_CMD_INTERNAL_GET_CONSTRUCTED_FALCON_INFO is moved to
NV2080_CTRL_CMD_GPU_GET_CONSTRUCTED_FALCON_INFO in 550.40.07.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:38 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for fifo.xlat_rm_engine_type()
550.40.07 has incompatible changes to RM_ENGINE_TYPE defines.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:38 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for disp.chan.set_pushbuf()
550.40.07 has incompatible changes to
NV2080_CTRL_CMD_INTERNAL_DISPLAY_CHANNEL_PUSHBUFFER.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:38 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for disp.get_static_info()
550.40.07 has incompatible changes to
NV2080_CTRL_CMD_INTERNAL_DISPLAY_GET_STATIC_INFO.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:37 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for disp.dp.set_indexed_link_rates()
545.23.06 has incompatible changes to
NV0073_CTRL_CMD_DP_CONFIG_INDEXED_LINK_RATES.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:37 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for disp.bl_ctrl()
545.23.06 has incompatible changes to
NV0073_CTRL_SPECIFIC_BACKLIGHT_BRIGHTNESS_PARAMS.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:37 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for gsp.drop_send_user_shared_data()
545.23.06 removes NV_VGPU_MSG_EVENT_GSP_SEND_USER_SHARED_DATA, but has
another event (NVLINK_FAULT_UP) in its place.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:37 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for gsp.xlat_mc_engine_idx()
545.23.06 has incompatible changes to MC_ENGINE_IDX definitions.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:37 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for gsp.get_static_info()
545.23.06 has incompatible changes to a number of definitions that
impact the layout of GspStaticConfigInfo.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:37 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for gsp.set_system_info()
545.23.06 has incompatible changes to GspSystemInfo.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:37 +0000 (13:02 +1000)]
drm/nouveau/gsp: add hal for wpr config info + meta init
545.23.06 increases the libos3 heap size requirements, and GH100/GBxxx
will need their own implementation entirely.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Wed, 7 May 2025 20:48:37 +0000 (06:48 +1000)]
drm/nouveau/gsp: add defines for rmapi object handles
Add header containing defines for RMAPI handles used by NVKM, and
use them in place of magic values when calling RM_ALLOC.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Fri, 14 Feb 2025 17:21:47 +0000 (03:21 +1000)]
drm/nouveau/gsp: add common code for engines/engine objects
With minimal to no direct HW programming required, most nvkm_engine
implementations are nearly identical when running on top of GSP-RM.
Add a common implementation of the boilerplate, and use nvkm_rm_gpu to
expose the correct class IDs.
As they're now handled by common code, and there's no support for them
prior to GSP-RM support - this deletes the GA100 NVDEC/NVJPG/OFA HALs,
the GA102 NVENC/OFA HALs, and the AD102 GR/NVDEC/NVENC/NVJPG/OFA HALs.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Tue, 18 Feb 2025 10:51:56 +0000 (20:51 +1000)]
drm/nouveau/gsp: add channel class id to gpu hal
Use channel class ID from nvkm_rm_gpu, instead of copying it from the
non-GSP HALs.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Tue, 18 Feb 2025 10:33:39 +0000 (20:33 +1000)]
drm/nouveau/gsp: add usermode class id to gpu hal
Use usermode class ID from nvkm_rm_gpu, instead of copying it from the
non-GSP HALs.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Tue, 18 Feb 2025 10:11:55 +0000 (20:11 +1000)]
drm/nouveau/gsp: add display class ids to gpu hal
Use display class IDs from nvkm_rm_gpu, instead of copying them from the
non-GSP HALs.
Removes the AD102 display HAL, which is no longer required as there's no
support for it without GSP-RM.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Fri, 14 Feb 2025 16:55:45 +0000 (02:55 +1000)]
drm/nouveau/gsp: add gpu hal stubs
With GSP-RM handling the majority of the HW programming, NVKM's usual
HALs are more elaborate than necessary, resulting in a fair amount of
duplicated boilerplate.
Adds 'nvkm_rm_gpu' which serves to provide GPU-specific constants and
functions in a more streamlined manner.
This is initially used in subsequent commits to store engine class IDs,
and replace the per-engine/engobj boilerplate with common code for all
GSP-RM supported engines - and is further extended when adding GH100,
GB10x and GB20x support.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:37 +0000 (13:02 +1000)]
drm/nouveau/gsp: switch to a simpler GSP-RM header layout
Rather than using OpenRM's directory structure for headers, move to a
layout that's split roughly around RM API boundaries.
Also move the headers from include/nvrm to subdev/gsp/rm/r535/nvrm,
with the rest of the r535-specific code.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:37 +0000 (13:02 +1000)]
drm/nouveau/gsp: move subdev/engine impls to subdev/gsp/rm/r535/
Move all the remaining GSP-RM code together underneath a versioned path,
to make the code easier to work with when adding support for a newer RM
version.
Aside from adjusting include paths, no code change is intended.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Wed, 22 Jan 2025 11:21:03 +0000 (21:21 +1000)]
drm/nouveau/gsp: move booter handling to GPU-specific code
GH100/GBxxx have significant changes to the GSP-RM boot process.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Mon, 3 Feb 2025 22:38:19 +0000 (08:38 +1000)]
drm/nouveau/gsp: move firmware loading to GPU-specific code
GH100/GBxxx use a slightly different set of firmwares to boot GSP-RM.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:37 +0000 (13:02 +1000)]
drm/nouveau/gsp: split device handling out on its own
Split handling of NV01_DEVICE (and other related objects) out into its
own module.
Aside from moving the function pointers, no code change is intended.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:37 +0000 (13:02 +1000)]
drm/nouveau/gsp: split client handling out on its own
Split NV01_ROOT handling out into its own module.
Aside from moving the function pointers, no code change is intended.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:36 +0000 (13:02 +1000)]
drm/nouveau/gsp: split rm alloc handling out on its own
Split base RM_ALLOC handling out into its own module.
Aside from moving the function pointers, no code change is intended.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:36 +0000 (13:02 +1000)]
drm/nouveau/gsp: split rm ctrl handling out on its own
Split base RM_CONTROL handling out into its own module.
Aside from moving the function pointers, no code change is intended.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 14 Nov 2024 03:02:36 +0000 (13:02 +1000)]
drm/nouveau/gsp: split rpc handling out on its own
Later patches in the series add HALs around various RM APIs in order to
support a newer version of GSP-RM firmware. In order to do this, begin
by splitting the code up into "modules" that roughly represent RM's API
boundaries so they can be more easily managed.
Aside from moving the RPC function pointers, no code change is indended.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Thu, 20 Feb 2025 20:26:13 +0000 (06:26 +1000)]
drm/nouveau/ofa: bump max instances to 2
560.28.03 supports more NVENC instances.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Sun, 17 Nov 2024 23:47:14 +0000 (09:47 +1000)]
drm/nouveau/nvenc: bump max instances to 4
570.86.16 supports more NVENC instances.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Mon, 25 Nov 2024 00:46:40 +0000 (10:46 +1000)]
drm/nouveau/ce: bump max instances to 20
560.28.03 supports more copy engine instances.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
In order to specify a channel ID to RM during channel allocation, the
channel ID is broken down into a "userd page" index and an index into
that page.
It was assumed that RM would enforce that the same physical block of
memory be used for all CHIDs within a "userd page", and the GSP paths
override NVKM's normal CHID allocation to handle this.
However, none of that turns out to be necessary.
Remove the GSP-specific code and use the regular CHID allocation path.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Tue, 4 Feb 2025 17:12:51 +0000 (03:12 +1000)]
drm/nouveau/gsp: fix rm shutdown wait condition
Though the initial upstreamed GSP-RM version in nouveau was 535.113.01,
the code was developed against earlier versions.
535.42.02 modified the mailbox value used by GSP-RM to signal shutdown
has completed, which was missed at the time.
I'm not aware of any issues caused by this, but noticed the bug while
working on GB20x support.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
projects / users / hch / misc.git / log