summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/nouveau
AgeCommit message (Collapse)Author
2023-09-20nouveau/u_memcpya: use vmemdup_userDave Airlie
I think there are limit checks in place for most things but the new uAPI wants to not have them. Add a limit check and use the vmemdup_user helper instead. Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Danilo Krummrich <dakr@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230810185020.231135-1-airlied@gmail.com
2023-09-20drm/nouveau: sched: fix leaking memory of timedout jobDanilo Krummrich
Always stop and re-start the scheduler in order to let the scheduler free up the timedout job in case it got signaled. In case of exec jobs the job type specific callback will take care to signal all fences and tear down the channel. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Signed-off-by: Danilo Krummrich <dakr@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230916162835.5719-1-dakr@redhat.com
2023-09-20drm/nouveau: fence: fix type cast warning in nouveau_fence_emit()Danilo Krummrich
Fix the following warning. drivers/gpu/drm/nouveau/nouveau_fence.c:210:45: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct nouveau_channel *chan @@ got struct nouveau_channel [noderef] __rcu *channel We're just about to emit the fence, there is nothing to protect against yet, hence it is safe to just cast __rcu away. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202309140340.BwKXzaDx-lkp@intel.com/ Fixes: 978474dc8278 ("drm/nouveau: fence: fix undefined fence state after emit") Signed-off-by: Danilo Krummrich <dakr@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230916011501.15813-1-dakr@redhat.com
2023-09-15drm/nouveau/pm: refactor deprecated strncpyJustin Stitt
`strncpy` is deprecated for use on NUL-terminated destination strings [1]. We should prefer more robust and less ambiguous string interfaces. A suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230914-strncpy-drivers-gpu-drm-nouveau-nvkm-engine-pm-base-c-v1-1-4b09ed453f84@google.com
2023-09-15drm/nouveau/core: refactor deprecated strncpyJustin Stitt
`strncpy` is deprecated for use on NUL-terminated destination strings [1]. We should prefer more robust and less ambiguous string interfaces. A suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. There is likely no bug in the current implementation due to the safeguard: | cname[sizeof(cname) - 1] = '\0'; ... however we can provide simpler and easier to understand code using the newer (and recommended) `strscpy` api. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230914-strncpy-drivers-gpu-drm-nouveau-nvkm-core-firmware-c-v1-1-3aeae46c032f@google.com
2023-09-15drm/nouveau/nvif: refactor deprecated strncpyJustin Stitt
`strncpy` is deprecated and as such we should prefer more robust and less ambiguous string interfaces. A suitable replacement is `strscpy_pad` due to the fact that it guarantees NUL-termination on the destination buffer whilst also maintaining the NUL-padding behavior that `strncpy` provides. I am not sure whether NUL-padding is strictly needed but I see in `nvif_object_ctor()` args is memcpy'd elsewhere so I figured we'd keep the same functionality. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230914-strncpy-drivers-gpu-drm-nouveau-nvif-client-c-v1-1-dc3b3719fcb4@google.com
2023-09-08drm/mst: Refactor the flow for payload allocation/removementWayne Lin
[Why] Today, the allocation/deallocation steps and status is a bit unclear. For instance, payload->vc_start_slot = -1 stands for "the failure of updating DPCD payload ID table" and can also represent as "payload is not allocated yet". These two cases should be handled differently and hence better to distinguish them for better understanding. [How] Define enumeration - ALLOCATION_LOCAL, ALLOCATION_DFP and ALLOCATION_REMOTE to distinguish different allocation status. Adjust the code to handle different status accordingly for better understanding the sequence of payload allocation and payload removement. For payload creation, the procedure should look like this: DRM part 1: * step 1 - update sw mst mgr variables to add a new payload * step 2 - add payload at immediate DFP DPCD payload table Driver: * Add new payload in HW and sync up with DFP by sending ACT DRM Part 2: * Send ALLOCATE_PAYLOAD sideband message to allocate bandwidth along the virtual channel. And as for payload removement, the procedure should look like this: DRM part 1: * step 1 - Send ALLOCATE_PAYLOAD sideband message to release bandwidth along the virtual channel * step 2 - Clear payload allocation at immediate DFP DPCD payload table Driver: * Remove the payload in HW and sync up with DFP by sending ACT DRM part 2: * update sw mst mgr variables to remove the payload Note that it's fine to fail when communicate with the branch device connected at immediate downstrean-facing port, but updating variables of SW mst mgr and HW configuration should be conducted anyway. That's because it's under commit_tail and we need to complete the HW programming. Changes since v1: * Remove the set but not use variable 'old_payload' in function 'nv50_msto_prepare'. Catched by kernel test robot <lkp@intel.com> Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230807025639.1612361-3-Wayne.Lin@amd.com
2023-09-08Merge tag 'drm-misc-next-fixes-2023-09-01' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next Short summary of fixes pull: * ivpu: Replace strncpy * nouveau: Fix fence state in nouveau_fence_emit() Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230901070123.GA6987@linux-uq9g
2023-08-31drm/nouveau: fence: fix undefined fence state after emitDanilo Krummrich
nouveau_fence_emit() can fail before and after initializing the dma-fence and hence before and after initializing the dma-fence' kref. In order to avoid nouveau_fence_emit() potentially failing before dma-fence initialization pass the channel to nouveau_fence_new() already and perform the required check before even allocating the fence. While at it, restore the original behavior of nouveau_fence_new() and add nouveau_fence_create() for separate (pre-)allocation instead. Always splitting up allocation end emit wasn't a good idea in the first place. Hence, limit it to the places where we actually need to pre-allocate. Fixes: 7f2a0b50b2b2 ("drm/nouveau: fence: separate fence alloc and emit") Signed-off-by: Danilo Krummrich <dakr@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230829223847.4406-1-dakr@redhat.com
2023-08-25Merge tag 'drm-misc-next-fixes-2023-08-24' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next Short summary of fixes pull: * gpuva: Cleanups * kunit: Documentation fixes * nouveau: * UAPI: Avoid implicit NO_PREFETCH flag * Scheduler fixes * Fix remap * ttm: Fix type conversion in tests Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230824181241.GA6386@linux-uq9g.hotspot.internet-for-guests.com
2023-08-24drm/nouveau: uapi: don't pass NO_PREFETCH flag implicitlyDanilo Krummrich
Currently, NO_PREFETCH is passed implicitly through drm_nouveau_gem_pushbuf_push::length and drm_nouveau_exec_push::va_len. Since this is a direct representation of how the HW is programmed it isn't really future proof for a uAPI. Hence, fix this up for the new uAPI and split up the va_len field of struct drm_nouveau_exec_push, such that we keep 32bit for va_len and 32bit for flags. For drm_nouveau_gem_pushbuf_push::length at least provide NOUVEAU_GEM_PUSHBUF_NO_PREFETCH to indicate the bit shift. While at it, fix up nv50_dma_push() as well, such that the caller doesn't need to encode the NO_PREFETCH flag into the length parameter. Signed-off-by: Danilo Krummrich <dakr@redhat.com> Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230823181746.3446-1-dakr@redhat.com
2023-08-24drm/nouveau: uvmm: fix unset region pointer on remapDanilo Krummrich
Transfer the region pointer of a uvma to the new uvma(s) on re-map to prevent potential shader faults when the re-mapped uvma(s) are unmapped. Signed-off-by: Danilo Krummrich <dakr@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230820222920.2344-1-dakr@redhat.com
2023-08-24drm/nouveau: sched: avoid job races between entitiesDanilo Krummrich
If a sched job depends on a dma-fence from a job from the same GPU scheduler instance, but a different scheduler entity, the GPU scheduler does only wait for the particular job to be scheduled, rather than for the job to fully complete. This is due to the GPU scheduler assuming that there is a scheduler instance per ring. However, the current implementation, in order to avoid arbitrary amounts of kthreads, has a single scheduler instance while scheduler entities represent rings. As a workaround, set the DRM_SCHED_FENCE_DONT_PIPELINE for all out-fences in order to force the scheduler to wait for full job completion for dependent jobs from different entities and same scheduler instance. There is some work in progress [1] to address the issues of firmware schedulers; once it is in-tree the scheduler topology in Nouveau should be re-worked accordingly. [1] https://lore.kernel.org/dri-devel/20230801205103.627779-1-matthew.brost@intel.com/ Signed-off-by: Danilo Krummrich <dakr@redhat.com> Reviewed-by: Faith Ekstrand <faith.ekstrand@collaboralcom> Link: https://patchwork.freedesktop.org/patch/msgid/20230811010632.2473-1-dakr@redhat.com
2023-08-24drm/nouveau: uapi: don't pass NO_PREFETCH flag implicitlyDanilo Krummrich
Currently, NO_PREFETCH is passed implicitly through drm_nouveau_gem_pushbuf_push::length and drm_nouveau_exec_push::va_len. Since this is a direct representation of how the HW is programmed it isn't really future proof for a uAPI. Hence, fix this up for the new uAPI and split up the va_len field of struct drm_nouveau_exec_push, such that we keep 32bit for va_len and 32bit for flags. For drm_nouveau_gem_pushbuf_push::length at least provide NOUVEAU_GEM_PUSHBUF_NO_PREFETCH to indicate the bit shift. While at it, fix up nv50_dma_push() as well, such that the caller doesn't need to encode the NO_PREFETCH flag into the length parameter. Signed-off-by: Danilo Krummrich <dakr@redhat.com> Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230823181746.3446-1-dakr@redhat.com
2023-08-24BackMerge tag 'v6.5-rc7' into drm-nextDave Airlie
Linux 6.5-rc7 This is needed for the CI stuff and the msm pull has fixes in it. Signed-off-by: Dave Airlie <airlied@redhat.com>
2023-08-22drm/nouveau: uvmm: fix unset region pointer on remapDanilo Krummrich
Transfer the region pointer of a uvma to the new uvma(s) on re-map to prevent potential shader faults when the re-mapped uvma(s) are unmapped. Signed-off-by: Danilo Krummrich <dakr@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230820222920.2344-1-dakr@redhat.com
2023-08-22drm/nouveau: sched: avoid job races between entitiesDanilo Krummrich
If a sched job depends on a dma-fence from a job from the same GPU scheduler instance, but a different scheduler entity, the GPU scheduler does only wait for the particular job to be scheduled, rather than for the job to fully complete. This is due to the GPU scheduler assuming that there is a scheduler instance per ring. However, the current implementation, in order to avoid arbitrary amounts of kthreads, has a single scheduler instance while scheduler entities represent rings. As a workaround, set the DRM_SCHED_FENCE_DONT_PIPELINE for all out-fences in order to force the scheduler to wait for full job completion for dependent jobs from different entities and same scheduler instance. There is some work in progress [1] to address the issues of firmware schedulers; once it is in-tree the scheduler topology in Nouveau should be re-worked accordingly. [1] https://lore.kernel.org/dri-devel/20230801205103.627779-1-matthew.brost@intel.com/ Signed-off-by: Danilo Krummrich <dakr@redhat.com> Reviewed-by: Faith Ekstrand <faith.ekstrand@collaboralcom> Link: https://patchwork.freedesktop.org/patch/msgid/20230811010632.2473-1-dakr@redhat.com
2023-08-16drm/nouveau/disp: fix use-after-free in error handling of ↵Karol Herbst
nouveau_connector_create We can't simply free the connector after calling drm_connector_init on it. We need to clean up the drm side first. It might not fix all regressions from commit 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts"), but at least it fixes a memory corruption in error handling related to that commit. Link: https://lore.kernel.org/lkml/20230806213107.GFZNARG6moWpFuSJ9W@fat_crate.local/ Fixes: 95983aea8003 ("drm/nouveau/disp: add connector class") Signed-off-by: Karol Herbst <kherbst@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230814144933.3956959-1-kherbst@redhat.com
2023-08-11nouveau/u_memcpya: use vmemdup_userDave Airlie
I think there are limit checks in place for most things but the new uAPI wants to not have them. Add a limit check and use the vmemdup_user helper instead. Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Danilo Krummrich <dakr@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230810185020.231135-1-airlied@gmail.com
2023-08-08drm/nouveau/disp: Revert a NULL check inside nouveau_connector_get_modesKarol Herbst
The original commit adding that check tried to protect the kenrel against a potential invalid NULL pointer access. However we call nouveau_connector_detect_depth once without a native_mode set on purpose for non LVDS connectors and this broke DP support in a few cases. Cc: Olaf Skibbe <news@kravcenko.com> Cc: Lyude Paul <lyude@redhat.com> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/238 Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/245 Fixes: 20a2ce87fbaf8 ("drm/nouveau/dp: check for NULL nv_connector->native_mode") Signed-off-by: Karol Herbst <kherbst@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230805101813.2603989-1-kherbst@redhat.com
2023-08-08drm/nouveau/sched: Don't pass user flags to drm_syncobj_find_fence()Faith Ekstrand
The flags field in drm_syncobj_find_fence() takes SYNCOBJ_WAIT flags from the syncobj UAPI whereas sync->flags is from the nouveau UAPI. What we actually want is 0 flags which tells it to just try to find the fence and then return without waiting. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Cc: Danilo Krummrich <dakr@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Reviewed-by: Danilo Krummrich <dakr@redhat.com> Signed-off-by: Faith Ekstrand <faith.ekstrand@collabora.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230807234210.175968-1-faith.ekstrand@collabora.com
2023-08-08drm/nouveau: uvmm: remove dedicated VM pointer from VMAsDanilo Krummrich
VMAs can find their corresponding VM through their embedded struct drm_gpuva which already carries a pointer to a struct drm_gpuva_manager which the VM is based on. Hence, remove the struct nouveau_uvmm pointer from struct nouveau_uvma to save a couple of bytes per mapping. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230807163238.2091-6-dakr@redhat.com
2023-08-08drm/nouveau: uvmm: remove incorrect calls to mas_unlock()Danilo Krummrich
Remove incorrect calls to mas_unlock() in the unwind path of __nouveau_uvma_region_insert(). The region maple tree uses an external lock instead, namely the global uvmm lock. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230807163238.2091-5-dakr@redhat.com
2023-08-08drm/nouveau: remove incorrect __user annotationsDanilo Krummrich
Fix copy-paste error causing EXEC and VM_BIND syscalls data pointers to carry incorrect __user annotations. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230807163238.2091-4-dakr@redhat.com
2023-08-08drm/nouveau: nvkm: vmm: silence warning from castDanilo Krummrich
Cast the integer to a pointer-sized type first to keep the compiler happy. Fixes: 6b252cf42281 ("drm/nouveau: nvkm/vmm: implement raw ops to manage uvmm") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230807163238.2091-3-dakr@redhat.com
2023-08-08nouveau/dmem: fix copy-paste error in nouveau_dmem_migrate_chunk()Danilo Krummrich
Fix call to nouveau_fence_emit() with wrong channel parameter. Fixes: 7f2a0b50b2b2 ("drm/nouveau: fence: separate fence alloc and emit") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230807163238.2091-2-dakr@redhat.com
2023-08-04drm/nouveau: debugfs: implement DRM GPU VA debugfsDanilo Krummrich
Provide the driver indirection iterating over all DRM GPU VA spaces to enable the common 'gpuvas' debugfs file for dumping DRM GPU VA spaces. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-13-dakr@redhat.com
2023-08-04drm/nouveau: implement new VM_BIND uAPIDanilo Krummrich
This commit provides the implementation for the new uapi motivated by the Vulkan API. It allows user mode drivers (UMDs) to: 1) Initialize a GPU virtual address (VA) space via the new DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion of VA space managed by the kernel and userspace, respectively. 2) Allocate and free a VA space region as well as bind and unbind memory to the GPUs VA space via the new DRM_IOCTL_NOUVEAU_VM_BIND ioctl. UMDs can request the named operations to be processed either synchronously or asynchronously. It supports DRM syncobjs (incl. timelines) as synchronization mechanism. The management of the GPU VA mappings is implemented with the DRM GPU VA manager. 3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl. The execution happens asynchronously. It supports DRM syncobj (incl. timelines) as synchronization mechanism. DRM GEM object locking is handled with drm_exec. Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, use the DRM GPU scheduler for the asynchronous paths. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-12-dakr@redhat.com
2023-08-04drm/nouveau: nvkm/vmm: implement raw ops to manage uvmmDanilo Krummrich
The new VM_BIND UAPI uses the DRM GPU VA manager to manage the VA space. Hence, we a need a way to manipulate the MMUs page tables without going through the internal range allocator implemented by nvkm/vmm. This patch adds a raw interface for nvkm/vmm to pass the resposibility for managing the address space and the corresponding map/unmap/sparse operations to the upper layers. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-11-dakr@redhat.com
2023-08-04drm/nouveau: chan: provide nouveau_channel_kill()Danilo Krummrich
The new VM_BIND UAPI implementation introduced in subsequent commits will allow asynchronous jobs processing push buffers and emitting fences. If a job times out, we need a way to recover from this situation. For now, simply kill the channel to unblock all hung up jobs and signal userspace that the device is dead on the next EXEC or VM_BIND ioctl. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-10-dakr@redhat.com
2023-08-04drm/nouveau: fence: fail to emit when fence context is killedDanilo Krummrich
The new VM_BIND UAPI implementation introduced in subsequent commits will allow asynchronous jobs processing push buffers and emitting fences. If a fence context is killed, e.g. due to a channel fault, jobs which are already queued for execution might still emit new fences. In such a case a job would hang forever. To fix that, fail to emit a new fence on a killed fence context with -ENODEV to unblock the job. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-9-dakr@redhat.com
2023-08-04drm/nouveau: fence: separate fence alloc and emitDanilo Krummrich
The new (VM_BIND) UAPI exports DMA fences through DRM syncobjs. Hence, in order to emit fences within DMA fence signalling critical sections (e.g. as typically done in the DRM GPU schedulers run_job() callback) we need to separate fence allocation and fence emitting. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-8-dakr@redhat.com
2023-08-04drm/nouveau: move usercopy helpers to nouveau_drv.hDanilo Krummrich
Move the usercopy helpers to a common driver header file to make it usable for the new API added in subsequent commits. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-7-dakr@redhat.com
2023-08-04drm/nouveau: bo: initialize GEM GPU VA interfaceDanilo Krummrich
Initialize the GEM's DRM GPU VA manager interface in preparation for the (u)vmm implementation, provided by subsequent commits, to make use of it. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-6-dakr@redhat.com
2023-08-04drm/nouveau: get vmm via nouveau_cli_vmm()Danilo Krummrich
Provide a getter function for the client's current vmm context. Since we'll add a new (u)vmm context for UMD bindings in subsequent commits, this will keep the code clean. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-5-dakr@redhat.com
2023-08-04drm/nouveau: fixup the uapi header file.Dave Airlie
nouveau > 10 years ago had a plan for new multiplexer inside a multiplexer API using nvif. It never fully reached fruition, fast forward 10 years, and the new vulkan driver is avoiding libdrm and calling ioctls, and these 3 ioctls, getparam, channel alloc + free don't seem to be things we'd want to use nvif for. Undeprecate and put them into the uapi header so we can just copy it into mesa later. v2: use uapi types. Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-3-dakr@redhat.com
2023-08-03drm/nouveau: remove unused tu102_gr_load() functionArnd Bergmann
tu102_gr_load() is completely unused and can be removed to address this warning: drivers/gpu/drm/nouveau/dispnv50/disp.c:2517:1: error: no previous prototype for 'nv50_display_create' Another patch was sent in the meantime to mark the function static but that would just cause a different warning about an unused function. Fixes: 1cd97b5490c8 ("drm/nouveau/gr/tu102-: use sw_veid_bundle_init from firmware") Link: https://lore.kernel.org/all/CACO55tuaNOYphHyB9+ygi9AnXVuF49etsW7x2X5K5iEtFNAAyw@mail.gmail.com/ Link: https://lore.kernel.org/all/20230417210310.2443152-1-arnd@kernel.org/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230803143358.13563-1-arnd@kernel.org
2023-08-03drm/nouveau/nvkm/dp: Add workaround to fix DP 1.3+ DPCD issuesLyude Paul
Currently we use the drm_dp_dpcd_read_caps() helper in the DRM side of nouveau in order to read the DPCD of a DP connector, which makes sure we do the right thing and also check for extended DPCD caps. However, it turns out we're not currently doing this on the nvkm side since we don't have access to the drm_dp_aux structure there - which means that the DRM side of the driver and the NVKM side can end up with different DPCD capabilities for the same connector. Ideally in order to fix this, we just want to use the drm_dp_read_dpcd_caps() helper in nouveau. That's not currently possible though, and is going to depend on having a bunch of the DP code moved out of nvkm and into the DRM side of things as part of the GSP enablement work. Until then however, let's workaround this problem by porting a copy of drm_dp_read_dpcd_caps() into NVKM - which should fix this issue. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/211 Link: https://patchwork.freedesktop.org/patch/msgid/20230728225858.350581-1-lyude@redhat.com (cherry picked from commit cc4adf3a7323212f303bc9ff0f96346c44fcba06 in drm-misc-next) Cc: <stable@vger.kernel.org> # 6.3+ Signed-off-by: Karol Herbst <kherbst@redhat.com>
2023-08-03drm/nouveau/gr: enable memory loads on helper invocation on all channelsKarol Herbst
We have a lurking bug where Fragment Shader Helper Invocations can't load from memory. But this is actually required in OpenGL and is causing random hangs or failures in random shaders. It is unknown how widespread this issue is, but shaders hitting this can end up with infinite loops. We enable those only on all Kepler and newer GPUs where we use our own Firmware. Nvidia's firmware provides a way to set a kernelspace controlled list of mmio registers in the gr space from push buffers via MME macros. v2: drop code for gm200 and newer. Cc: Ben Skeggs <bskeggs@redhat.com> Cc: David Airlie <airlied@gmail.com> Cc: nouveau@lists.freedesktop.org Cc: stable@vger.kernel.org # 4.19+ Signed-off-by: Karol Herbst <kherbst@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230622152017.2512101-1-kherbst@redhat.com
2023-07-28drm/nouveau/nvkm/dp: Add workaround to fix DP 1.3+ DPCD issuesLyude Paul
Currently we use the drm_dp_dpcd_read_caps() helper in the DRM side of nouveau in order to read the DPCD of a DP connector, which makes sure we do the right thing and also check for extended DPCD caps. However, it turns out we're not currently doing this on the nvkm side since we don't have access to the drm_dp_aux structure there - which means that the DRM side of the driver and the NVKM side can end up with different DPCD capabilities for the same connector. Ideally in order to fix this, we just want to use the drm_dp_read_dpcd_caps() helper in nouveau. That's not currently possible though, and is going to depend on having a bunch of the DP code moved out of nvkm and into the DRM side of things as part of the GSP enablement work. Until then however, let's workaround this problem by porting a copy of drm_dp_read_dpcd_caps() into NVKM - which should fix this issue. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/211 Link: https://patchwork.freedesktop.org/patch/msgid/20230728225858.350581-1-lyude@redhat.com
2023-07-19drm/nouveau/kms/nv50-: init hpd_irq_lock for PIOR DPBen Skeggs
Fixes OOPS on boards with ANX9805 DP encoders. Cc: stable@vger.kernel.org # 6.4+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230719044051.6975-3-skeggsb@gmail.com
2023-07-19drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interruptsBen Skeggs
Fixes crash on boards with ANX9805 TMDS/DP encoders. Cc: stable@vger.kernel.org # 6.4+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230719044051.6975-2-skeggsb@gmail.com
2023-07-19drm/nouveau/i2c: fix number of aux event slotsBen Skeggs
This was completely bogus before, using maximum DCB device index rather than maximum AUX ID to size the buffer that stores event refcounts. *Pretty* unlikely to have been an actual problem on most configurations, that is, unless you've got one of the rare boards that have off-chip DP. There, it'll likely crash. Cc: stable@vger.kernel.org # 6.4+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230719044051.6975-1-skeggsb@gmail.com
2023-07-17Merge tag 'drm-misc-next-2023-07-13' of ↵Daniel Vetter
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v6.6: UAPI Changes: * fbdev: * Make fbdev userspace interfaces optional; only leaves the framebuffer console active * prime: * Support dma-buf self-import for all drivers automatically: improves support for many userspace compositors Cross-subsystem Changes: * backlight: * Fix interaction with fbdev in several drivers * base: Convert struct platform.remove to return void; part of a larger, tree-wide effort * dma-buf: Acquire reservation lock for mmap() in exporters; part of an on-going effort to simplify locking around dma-bufs * fbdev: * Use Linux device instead of fbdev device in many places * Use deferred-I/O helper macros in various drivers * i2c: Convert struct i2c from .probe_new to .probe; part of a larger, tree-wide effort * video: * Avoid including <linux/screen_info.h> Core Changes: * atomic: * Improve logging * prime: * Remove struct drm_driver.gem_prime_mmap plus driver updates: all drivers now implement this callback with drm_gem_prime_mmap() * gem: * Support execution contexts: provides locking over multiple GEM objects * ttm: * Support init_on_free * Swapout fixes Driver Changes: * accel: * ivpu: MMU updates; Support debugfs * ast: * Improve device-model detection * Cleanups * bridge: * dw-hdmi: Improve support for YUV420 bus format * dw-mipi-dsi: Fix enable/disable of DSI controller * lt9611uxc: Use MODULE_FIRMWARE() * ps8640: Remove broken EDID code * samsung-dsim: Fix command transfer * tc358764: Handle HS/VS polarity; Use BIT() macro; Various cleanups * Cleanups * ingenic: * Kconfig REGMAP fixes * loongson: * Support display controller * mgag200: * Minor fixes * mxsfb: * Support disabling overlay planes * nouveau: * Improve VRAM detection * Various fixes and cleanups * panel: * panel-edp: Support AUO B116XAB01.4 * Support Visionox R66451 plus DT bindings * Cleanups * ssd130x: * Support per-controller default resolution plus DT bindings * Reduce memory-allocation overhead * Cleanups * tidss: * Support TI AM625 plus DT bindings * Implement new connector model plus driver updates * vkms * Improve write-back support * Documentation fixes Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230713090830.GA23281@linux-uq9g
2023-07-12drm/nouveau: bring back blit subchannel for pre nv50 GPUsKarol Herbst
1ba6113a90a0 removed a lot of the kernel GPU channel, but method 0x128 was important as otherwise the GPU spams us with `CACHE_ERROR` messages. We use the blit subchannel inside our vblank handling, so we should keep at least this part. v2: Only do it for NV11+ GPUs Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/201 Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") Signed-off-by: Karol Herbst <kherbst@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230526091052.2169044-1-kherbst@redhat.com
2023-07-12drm/nouveau/acr: Abort loading ACR if no firmware was foundKarol Herbst
This fixes a NULL pointer access inside nvkm_acr_oneinit in case necessary firmware files couldn't be loaded. Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/212 Fixes: 4b569ded09fd ("drm/nouveau/acr/ga102: initial support") Signed-off-by: Karol Herbst <kherbst@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230522201838.1496622-1-kherbst@redhat.com
2023-07-12drm/nouveau/disp/g94: enable HDMIKarol Herbst
Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Fixes: f530bc60a30b ("drm/nouveau/disp: move HDMI config into acquire + infoframe methods") Signed-off-by: Karol Herbst <kherbst@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230630160645.3984596-1-kherbst@redhat.com Signed-off-by: Karol Herbst <kherbst@redhat.com>
2023-07-12drm/nouveau/disp: fix HDMI on gt215+Karol Herbst
Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Fixes: f530bc60a30b ("drm/nouveau/disp: move HDMI config into acquire + infoframe methods") Signed-off-by: Karol Herbst <kherbst@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230628212248.3798605-1-kherbst@redhat.com Signed-off-by: Karol Herbst <kherbst@redhat.com>
2023-07-11Merge v6.5-rc1 into drm-misc-fixesMaxime Ripard
Boris needs 6.5-rc1 in drm-misc-fixes to prevent a conflict. Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-07-10drm/nouveau/disp: use drm_kms_helper_connector_hotplug_event()Simon Ser
This adds more information to the hotplug uevent and lets user-space know that it's about a particular connector only. Signed-off-by: Simon Ser <contact@emersion.fr> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: David Airlie <airlied@linux.ie> Cc: Karol Herbst <kherbst@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230620181547.272476-1-contact@emersion.fr
generated by cgit (git 2.34.1) at 2025-09-22 07:52:59 +0000