- 21 Feb, 2024 1 commit
-
-
Javier Martinez Canillas authored
Commit 55bffc81 ("fbdev: Split frame buffer support in FB and FB_CORE symbols") added a new FB_CORE Kconfig symbol, that can be enabled to only have fbcon/VT and DRM fbdev emulation, but without support for any legacy fbdev driver. Unfortunately, it missed to change the CONFIG_FB in arch/sparc makefiles, which leads to the following linking error in some sparc64 configurations: sparc64-linux-ld: drivers/video/fbdev/core/fbcon.o: in function `fbcon_fb_registered': >> fbcon.c:(.text+0x4f60): undefined reference to `fb_is_primary_device' Fixes: 55bffc81 ("fbdev: Split frame buffer support in FB and FB_CORE symbols") Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202401290306.IV8rhJ02-lkp@intel.com/Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Arnd Bergmann <arnd@arndb.de> Cc: <stable@vger.kernel.org> # v6.6+ Signed-off-by:
-
- 20 Feb, 2024 1 commit
-
-
Andrzej Kacprowski authored
There is no point in requesting 1 tile on VPU40xx as the FW will probably need more tiles to run workloads, so it will have to reconfigure PLL anyway. Don't enable any tiles and allow the FW to perform initial tile configuration. This improves NPU boot stability as the tiles are always enabled only by the FW from the same initial state. Fixes: 79cdc56c ("accel/ivpu: Add initial support for VPU 4") Cc: stable@vger.kernel.org Signed-off-by:
Andrzej Kacprowski <Andrzej.Kacprowski@intel.com> Signed-off-by:
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Reviewed-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220131624.1447813-1-jacek.lawrynowicz@linux.intel.com
-
- 19 Feb, 2024 2 commits
-
-
Matthew Auld authored
Doesn't seem to compile on 32b, presumably due to u64 mod/division. Simplest is to just switch over to u32 here. Also make print modifiers consistent with that. Fixes: a64056bb ("drm/tests/drm_buddy: add alloc_contiguous test") Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Maxime Ripard <mripard@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240215174431.285069-7-matthew.auld@intel.comSigned-off-by:
Christian König <christian.koenig@amd.com>
-
Martin Blumenstingl authored
Stop calling drm_bridge_remove() for bridges allocated/managed by other drivers in the remove paths of meson_encoder_{cvbs,dsi,hdmi}. drm_bridge_remove() unregisters the bridge so it cannot be used anymore. Doing so for bridges we don't own can lead to the video pipeline not being able to come up after -EPROBE_DEFER of the VPU because we're unregistering a bridge that's managed by another driver. The other driver doesn't know that we have unregistered it's bridge and on subsequent .probe() we're not able to find those bridges anymore (since nobody re-creates them). This fixes probe errors on Meson8b boards with the CVBS outputs enabled. Fixes: 09847723 ("drm/meson: remove drm bridges at aggregate driver unbind time") Fixes: 42dcf15f ("drm/meson: add DSI encoder") Cc: <stable@vger.kernel.org> Reported-by:Steve Morvai <stevemorvai@hotmail.com> Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Tested-by:
-
- 16 Feb, 2024 3 commits
-
-
Dan Carpenter authored
If gf100_bar_new_() fails then "bar" is not initialized. Fixes: 5bf02571 ("drm/nouveau/mmu/r535: initial support") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by:
Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/dab21df7-4d90-4479-97d8-97e5d228c714@moroto.mountain
-
Arnd Bergmann authored
clang-16 warns about casting between incompatible function types: drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c:161:10: error: cast from 'void (*)(const struct firmware *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict] 161 | .fini = (void(*)(void *))release_firmware, This one was done to use the generic shadow_fw_release() function as a callback for struct nvbios_source. Change it to use the same prototype as the other five instances, with a trivial helper function that actually calls release_firmware. Fixes: 70c0f263 ("drm/nouveau/bios: pull in basic vbios subdev, more to come later") Signed-off-by:
-
Arunpravin Paneer Selvam authored
Remove the duplicate list_splice_tail call when the total_allocated < size condition is true. Cc: <stable@vger.kernel.org> # 6.7+ Fixes: 8746c6c9 ("drm/buddy: Fix alloc_range() error handling code") Reported-by:
Bert Karwatzki <spasswolf@web.de> Signed-off-by:
Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Reviewed-by:
-
- 14 Feb, 2024 2 commits
-
-
Matthew Auld authored
Sanity check DRM_BUDDY_CONTIGUOUS_ALLOCATION. v2: Fix checkpatch warnings. Signed-off-by:
-
Arunpravin Paneer Selvam authored
Few users have observed display corruption when they boot the machine to KDE Plasma or playing games. We have root caused the problem that whenever alloc_range() couldn't find the required memory blocks the function was returning SUCCESS in some of the corner cases. The right approach would be if the total allocated size is less than the required size, the function should return -ENOSPC. Cc: <stable@vger.kernel.org> # 6.7+ Fixes: 0a1844bf ("drm/buddy: Improve contiguous memory allocation") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3097Tested-by:
Mario Limonciello <mario.limonciello@amd.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240207174456.341121-1-Arunpravin.PaneerSelvam@amd.com/Acked-by:
-
- 13 Feb, 2024 3 commits
-
-
Harshit Mogalapalli authored
Unlock before returning on the error path. Fixes: 5a028e8f ("drm/rockchip: vop2: Add support for rk3588") Signed-off-by:
Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Reviewed-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240119190841.1619443-1-harshit.m.mogalapalli@oracle.com
-
Rob Clark authored
DRM_MODESET_LOCK_ALL_BEGIN() has a hidden trap-door (aka retry loop), which means we can't rely too much on variable initializers. Fixes: 6e455f5d ("drm/crtc: fix uninitialized variable use") Signed-off-by:
Rob Clark <robdclark@chromium.org> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # sc7180, sdm845 Link: https://patchwork.freedesktop.org/patch/msgid/20240212215534.190682-1-robdclark@gmail.comSigned-off-by:
-
Philip Yang authored
Without unsigned long typecast, the size is passed in as zero if page array size >= 4GB, nr_pages >= 0x100000, then sg list converted will have the first and the last chunk lost. Signed-off-by:
Philip Yang <Philip.Yang@amd.com> Acked-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
-
- 12 Feb, 2024 4 commits
-
-
Arnd Bergmann authored
The conversion to kvcalloc() mixed up the object size and count arguments, causing a warning: drivers/gpu/drm/nouveau/nouveau_svm.c: In function 'nouveau_svm_fault_buffer_ctor': drivers/gpu/drm/nouveau/nouveau_svm.c:1010:40: error: 'kvcalloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] 1010 | buffer->fault = kvcalloc(sizeof(*buffer->fault), buffer->entries, GFP_KERNEL); | ^ drivers/gpu/drm/nouveau/nouveau_svm.c:1010:40: note: earlier argument should specify number of elements, later size of each element The behavior is still correct aside from the warning, but fixing it avoids the warnings and can help the compiler track the individual objects better. Fixes: 71e4bbca ("nouveau/svm: Use kvcalloc() instead of kvzalloc()") Signed-off-by: -
Danilo Krummrich authored
Omit to create scheduler instances when using the legacy uAPI. When using the legacy NOUVEAU_GEM_PUSHBUF ioctl no scheduler instance is required, hence omit creating scheduler instances in nouveau_abi16_ioctl_channel_alloc(). Tested-by:
Timur Tabi <ttabi@nvidia.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Danilo Krummrich authored
nouveau_abi16_ioctl_channel_alloc() and nouveau_cli_init() simply call their corresponding *_fini() counterpart. This can lead to nouveau_sched_fini() being called without struct nouveau_sched ever being initialized in the first place. Instead of embedding struct nouveau_sched into struct nouveau_cli and struct nouveau_chan_abi16, allocate struct nouveau_sched separately, such that we can check for the corresponding pointer to be NULL in the particular *_fini() functions. It makes sense to allocate struct nouveau_sched separately anyway, since in a subsequent commit we can also avoid to allocate a struct nouveau_sched in nouveau_abi16_ioctl_channel_alloc() at all, if the VM_BIND uAPI has been disabled due to the legacy uAPI being used. Fixes: 5f03a507 ("drm/nouveau: implement 1:1 scheduler - entity relationship") Reported-by:
-
Jacek Lawrynowicz authored
Issue IP reset before shutdown in order to complete all upstream requests to the SOC. Without this DevTLB is complaining about incomplete transactions and NPU cannot resume from suspend. This problem is only happening on recent IFWI releases. IP reset in rare corner cases can mess up PCI configuration, so save it before the reset. After this happens it is also impossible to issue PLL requests and D0->D3->D0 cycle is needed to recover the NPU. Add WP 0 request on power up, so the PUNIT is always notified about NPU reset. Use D0/D3 cycle for recovery as it can recover from failed IP reset and FLR cannot. Fixes: 3f7c0634 ("accel/ivpu/37xx: Fix hangs related to MMIO reset") Signed-off-by:
-
- 06 Feb, 2024 6 commits
-
-
Grzegorz Trzebiatowski authored
Add DRM_IVPU_JOB_STATUS_ABORTED to indicate that the job was aborted by the driver due to e.g. TDR or user context MMU faults. This will help UMD and tests distinguish if job was aborted by the FW or the driver. Signed-off-by:
Grzegorz Trzebiatowski <grzegorz.trzebiatowski@intel.com> Signed-off-by:
-
Krystian Pradzynski authored
This parameter was never used by the 40xx FW. Signed-off-by:
Krystian Pradzynski <krystian.pradzynski@intel.com> Signed-off-by:
-
Krystian Pradzynski authored
All recent 40xx firmware already supports D0i3 entry message and this WA is no longer needed. Signed-off-by:
-
Jacek Lawrynowicz authored
NPU does not require this delay regardless of the generation. All generations are integrated into the SOC. Signed-off-by:
-
Wachowski, Karol authored
Do not use kernel CIRC_SPACE and CIRC_CNT that incorrectly return space of a queue when wrap bit was set. Use correct implementation that compares producer, consumer and wrap bit values. Without this fix it was possible to lose events in case when event queue was full. Signed-off-by:
Wachowski, Karol <karol.wachowski@intel.com> Signed-off-by:
-
Wachowski, Karol authored
Set AW_SNOOP_OVERRIDE bit in VPU_37/40XX_HOST_IF_TCU_PTW_OVERRIDES to force snooping for MMU write accesses (setting event queue events). MMU event queue buffer is the only buffer written by MMU and mapped as write-back which break cache coherency. Force write transactions to be snooped solving the problem. Signed-off-by:
-
- 05 Feb, 2024 4 commits
-
-
Timur Tabi authored
Function nvkm_gsp_radix3_sg() uses nvkm_gsp_mem objects to allocate the radix3 tables, but it unnecessarily creates those objects manually instead of using the standard nvkm_gsp_mem_ctor() function like the rest of the code does. Signed-off-by:
-
Timur Tabi authored
Nouveau manages GSP-RM DMA buffers with nvkm_gsp_mem objects. Several of these buffers are never dealloced. Some of them can be deallocated right after GSP-RM is initialized, but the rest need to stay until the driver unloads. Also futher bullet-proof these objects by poisoning the buffer and clearing the nvkm_gsp_mem object when it is deallocated. Poisoning the buffer should trigger an error (or crash) from GSP-RM if it tries to access the buffer after we've deallocated it, because we were wrong about when it is safe to deallocate. Finally, change the mem->size field to a size_t because that's the same type that dma_alloc_coherent expects. Cc: <stable@vger.kernel.org> # v6.7 Fixes: 176fdcbd ("drm/nouveau/gsp/r535: add support for booting GSP-RM") Signed-off-by:
-
Dave Airlie authored
Timur pointed this out before, and it just slipped my mind, but this might help some things work better, around pcie power management. Cc: <stable@vger.kernel.org> # v6.7 Fixes: 8d55b0a9 ("nouveau/gsp: add some basic registry entries.") Signed-off-by:
-
Maxime Ripard authored
Merge the last drm-misc-next-fixes tag that fell through the cracks. Signed-off-by:Maxime Ripard <mripard@kernel.org>
-
- 31 Jan, 2024 1 commit
-
-
T.J. Mercier authored
DMA buffers allocated from the CMA dma-buf heap get counted under RssFile for processes that map them and trigger page faults. In addition to the incorrect accounting reported to userspace, reclaim behavior was influenced by the MM_FILEPAGES counter until linux 6.8, but this memory is not reclaimable. [1] Change the CMA dma-buf heap to set VM_PFNMAP on the VMA so MM does not poke at the memory managed by this dma-buf heap, and use vmf_insert_pfn to correct the RSS accounting. The system dma-buf heap does not suffer from this issue since remap_pfn_range is used during the mmap of the buffer, which also sets VM_PFNMAP on the VMA. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/mm/vmscan.c?id=fb46e22a9e3863e08aef8815df9f17d0f4b9aede Fixes: b61614ec ("dma-buf: heaps: Add CMA heap to dmabuf heaps") Signed-off-by:
T.J. Mercier <tjmercier@google.com> Acked-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240117181141.286383-1-tjmercier@google.com
-
- 29 Jan, 2024 1 commit
-
-
Sebastian Ott authored
Set the segment size of the virtio_gpu device to the value used by the drm helpers when allocating sg lists to fix the following complaint from DMA_API debug code: DMA-API: virtio-pci 0000:07:00.0: mapping sg segment longer than device claims to support [len=262144] [max=65536] Cc: stable@vger.kernel.org Tested-by:
Zhenyu Zhang <zhenyzha@redhat.com> Acked-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
Sebastian Ott <sebott@redhat.com> Signed-off-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/7258a4cc-da16-5c34-a042-2a23ee396d56@redhat.com
-
- 25 Jan, 2024 3 commits
-
-
Jacek Lawrynowicz authored
- Synchronize job submission with reset/recovery using reset_lock - Always print recovery reason and call diagnose_failure() - Don't allow for autosupend during recovery - Prevent immediate autosuspend after reset/recovery - Prevent force_recovery for issuing TDR when device is suspended - Reset VPU instead triggering recovery after changing debugfs params Signed-off-by:
-
Jacek Lawrynowicz authored
- Wake up the device as late as possible - Remove job reference counting in order to simplify the code - Don't put jobs that are not fully submitted on submitted_jobs_xa in order to avoid potential races with reset/recovery Signed-off-by:
-
Jacek Lawrynowicz authored
- Add context_list_lock to synchronize user context addition/removal - Use drm_dev_enter() to prevent unbinding the device during ivpu_open() and vpu address allocation Signed-off-by:
-
- 24 Jan, 2024 1 commit
-
-
Thomas Zimmermann authored
This reverts commit 60aebc95. Commit 60aebc95 ("drivers/firmware: Move sysfb_init() from device_initcall to subsys_initcall_sync") messes up initialization order of the graphics drivers and leads to blank displays on some systems. So revert the commit. To make the display drivers fully independent from initialization order requires to track framebuffer memory by device and independently from the loaded drivers. The kernel currently lacks the infrastructure to do so. Reported-by:
Jaak Ristioja <jaak@ristioja.ee> Closes: https://lore.kernel.org/dri-devel/ZUnNi3q3yB3zZfTl@P70.localdomain/T/#tReported-by:
Huacai Chen <chenhuacai@loongson.cn> Closes: https://lore.kernel.org/dri-devel/20231108024613.2898921-1-chenhuacai@loongson.cn/ Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10133Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240123120937.27736-1-tzimmermann@suse.de
-
- 22 Jan, 2024 8 commits
-
-
Bagas Sanjaya authored
Stephen Rothwell reported htmldocs warnings when merging drm-intel tree: Documentation/gpu/drm-kms-helpers:296: drivers/gpu/drm/display/drm_dp_mst_topology.c:5484: ERROR: Unexpected indentation. Documentation/gpu/drm-kms-helpers:296: drivers/gpu/drm/display/drm_dp_mst_topology.c:5488: WARNING: Block quote ends without a blank line; unexpected unindent. Separate @failing_port return value list by surrounding it with a blank line to fix above warnings. Fixes: 1cd0a5ea ("drm/dp_mst: Factor out a helper to check the atomic state of a topology manager") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/linux-next/20231114141715.6f435118@canb.auug.org.au/Signed-off-by:
Bagas Sanjaya <bagasdotme@gmail.com> Reviewed-by:
-
Hsin-Yi Wang authored
Similar to commit 26db46bc ("drm/bridge: parade-ps8640: Ensure bridge is suspended in .post_disable()"). Add a mutex to ensure that aux transfer won't race with atomic_disable by holding the PM reference and prevent the bridge from suspend. Also we need to use pm_runtime_put_sync_suspend() to suspend the bridge instead of idle with pm_runtime_put_sync(). Fixes: 3203e497 ("drm/bridge: anx7625: Synchronously run runtime suspend.") Fixes: adca62ec ("drm/bridge: anx7625: Support reading edid through aux channel") Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Tested-by:
Xuxin Xiong <xuxinxiong@huaqin.corp-partner.google.com> Reviewed-by:
Pin-yen Lin <treapking@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Jacek Lawrynowicz authored
IP reset has to followed by ivpu_pll_disable() to properly enter reset state. Fixes: 828d6304 ("accel/ivpu: Don't enter d0i3 during FLR") Signed-off-by:
Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Signed-off-by:
-
Wachowski, Karol authored
DRM_IVPU_PARAM_CONTEXT_PRIORITY has been deprecated because it has been replaced with DRM_IVPU_JOB_PRIORITY levels set with submit IOCTL and was unused anyway. Signed-off-by:
-
Jacek Lawrynowicz authored
Make debug logs more readable and consistent: - don't print handle as it is not always available for all buffers - use hashed ivpu_bo ptr as main buffer identifier - remove unused fields from ivpu_bo_print_info() Signed-off-by:
-
Jacek Lawrynowicz authored
This was not supported properly. A buffer was imported to another VPU context as a separate buffer object with duplicated sgt. Both exported and imported buffers could be DMA mapped causing a double mapping on the same device. Buffers imported from another VPU context will now just increase reference count, leaving only a single sgt, fixing the problem above. Buffers still can't be shared among VPU contexts because each has its own MMU mapping and ivpu_bo only supports single MMU mappings. The solution would be to use a mapping list as in panfrost or etnaviv drivers and it will be implemented in future if required. Signed-off-by:
Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240115134434.493839-8-jacek.lawrynowicz@linux.intel.com
-
Jacek Lawrynowicz authored
Call dma_unmap() on all buffers before the VPU is unbinded to avoid "device driver has pending DMA allocations while released from device" warning when DMA-API debug is enabled. Signed-off-by:
-
Jacek Lawrynowicz authored
drm_gem_shmem_vmap/vunmap requires dma resv lock to be held. This was missed during conversion to shmem helper. Fixes: 8d88e4cd ("accel/ivpu: Use GEM shmem helper for all buffers") Signed-off-by:
-
