summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2025-12-04drm/xe/pf: fix VFIO link errorArnd Bergmann
The Makefile logic for building xe_sriov_vfio.o was added incorrectly, as setting CONFIG_XE_VFIO_PCI=m means it doesn't get included into a built-in xe driver: ERROR: modpost: "xe_sriov_vfio_stop_copy_enter" [drivers/vfio/pci/xe/xe-vfio-pci.ko] undefined! ERROR: modpost: "xe_sriov_vfio_stop_copy_exit" [drivers/vfio/pci/xe/xe-vfio-pci.ko] undefined! ERROR: modpost: "xe_sriov_vfio_suspend_device" [drivers/vfio/pci/xe/xe-vfio-pci.ko] undefined! ERROR: modpost: "xe_sriov_vfio_wait_flr_done" [drivers/vfio/pci/xe/xe-vfio-pci.ko] undefined! ERROR: modpost: "xe_sriov_vfio_error" [drivers/vfio/pci/xe/xe-vfio-pci.ko] undefined! ERROR: modpost: "xe_sriov_vfio_resume_data_enter" [drivers/vfio/pci/xe/xe-vfio-pci.ko] undefined! ERROR: modpost: "xe_sriov_vfio_resume_device" [drivers/vfio/pci/xe/xe-vfio-pci.ko] undefined! ERROR: modpost: "xe_sriov_vfio_resume_data_exit" [drivers/vfio/pci/xe/xe-vfio-pci.ko] undefined! ERROR: modpost: "xe_sriov_vfio_data_write" [drivers/vfio/pci/xe/xe-vfio-pci.ko] undefined! ERROR: modpost: "xe_sriov_vfio_migration_supported" [drivers/vfio/pci/xe/xe-vfio-pci.ko] undefined! WARNING: modpost: suppressed 3 unresolved symbol warnings because there were too many) Check for CONFIG_XE_VFIO_PCI being enabled in the Makefile to decide whether to include the object instead. Fixes: 17f22465c5a5 ("drm/xe/pf: Export helpers for VFIO") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251204094154.1029357-1-arnd@kernel.org
2025-12-04drm/ttm: Use dma_fence_check_and_signal()Philipp Stanner
The return code of dma_fence_signal() is not useful and shall be removed from the kernel. To do so, the few users who rely on the return code must be ported. Use dma_fence_check_and_signal() and mapp its boolean return code to dma_fence_signal()'s former value for already-signaled fences. Suggested-by: Christian König <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20251201105011.19386-8-phasta@kernel.org
2025-12-04drm/xe: Use dma_fence_check_and_signal_locked()Philipp Stanner
Xe is one of the few users utilizing the return code of dma_fence_signal() to check whether a fence had already been signaled by someone else. To clean up and simplify the dma_fence API, the few kernel users relying on that behavior shall be ported to an alternative function. Replace dma_fence_signal_locked() with dma_fence_check_and_signal_locked(). Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20251201105011.19386-6-phasta@kernel.org
2025-12-04amd/amdkfd: Use dma_fence_check_and_signal()Philipp Stanner
amdkfd is one of the few users which relies on the return code of dma_fence_signal(), which, so far, informs the caller whether the fence had already been signaled. As there are barely any users, dma_fence signaling functions shall get the return value void. To do so, the few users must be ported to a function which preserves the old behavior. Replace the call to dma_fence_signal() with one to dma_fence_check_and_signal(). Suggested-by: Christian König <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20251201105011.19386-5-phasta@kernel.org
2025-12-04drm/rcar-du: dsi: Handle both DRM_MODE_FLAG_N.SYNC and !DRM_MODE_FLAG_P.SYNCMarek Vasut
Since commit 94fe479fae96 ("drm/rcar-du: dsi: Clean up handling of DRM mode flags") the driver does not set TXVMVPRMSET0R_VSPOL_LOW and TXVMVPRMSET0R_HSPOL_LOW for modes which set neither DRM_MODE_FLAG_[PN].SYNC. The previous behavior was to assume that neither flag means DRM_MODE_FLAG_N.SYNC . Restore the previous behavior for maximum compatibility. The change of behavior is visible below, consider Vertical mode->flags for simplicity sake, although the same applies to Horizontal ones: Before 94fe479fae96 ("drm/rcar-du: dsi: Clean up handling of DRM mode flags") : - DRM_MODE_FLAG_PVSYNC => vprmset0r |= 0 - DRM_MODE_FLAG_NVSYNC => vprmset0r |= TXVMVPRMSET0R_VSPOL_LOW - Neither DRM_MODE_FLAG_[PN]VSYNC => vprmset0r |= TXVMVPRMSET0R_VSPOL_LOW After 94fe479fae96 ("drm/rcar-du: dsi: Clean up handling of DRM mode flags") : - DRM_MODE_FLAG_PVSYNC => vprmset0r |= 0 - DRM_MODE_FLAG_NVSYNC => vprmset0r |= TXVMVPRMSET0R_VSPOL_LOW - Neither DRM_MODE_FLAG_[PN]VSYNC => vprmset0r |= 0 <---------- This broke The "Neither" case behavior is different, because DRM_MODE_FLAG_N[HV]SYNC is really not equivalent !DRM_MODE_FLAG_P[HV]SYNC . Fixes: 94fe479fae96 ("drm/rcar-du: dsi: Clean up handling of DRM mode flags") Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patch.msgid.link/20251202181146.138365-1-marek.vasut+renesas@mailbox.org Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2025-12-04drm/i915/fbc: Apply Wa_14025769978Vinod Govindapillai
Disable cache read setting in the cacheability configuration register as per the wa recommendation Bspec: 79482, 74722, 68881 Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20251127115349.249120-4-vinod.govindapillai@intel.com
2025-12-04drm/i915/xe3p_lpd: Enable display use of system cache for FBCVinod Govindapillai
One of the FBC instances can utilize the reserved area of SoC level cache for the fbc transactions to benefit reduced memory system power especially in idle scenarios. Reserved area of the system cache can be assigned to an fbc instance by configuring the cacheability configuration register with offset of the compressed frame buffer in stolen memoty of that fbc. There is a limit to this reserved area which is programmable and for xe3p_lpd the limit is defined as 2MB. The first FBC instance enabled will utilize the system cache as of now. v2: - better to track fbc sys cache usage from intel_display level, sanitize the cacheability config register on probe (Matt) - limit this for integrated graphics solutions, confirmed that no default value set for cache range by hw (Gustavo) v3: - changes related to the use of fbc substruct in intel_display - use intel_de_write() instead of intel_rmw() by hardcoding the default value fields v4: - protect sys cache config accesses, sys cache usage status in debugfs per fbc instance (Jani) v5: - mutex_init and missing mutex_lock in sanitize call v6: - changes to commit message and some obvious comments removed Bspec: 68881, 74722 Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20251128113557.129192-1-vinod.govindapillai@intel.com Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
2025-12-04drm/xe/uapi: Add NO_COMPRESSION BO flag and query capabilitySanjay Yadav
Introduce DRM_XE_GEM_CREATE_FLAG_NO_COMPRESSION to let userspace opt out of CCS compression on a per-BO basis. When set, the driver maps this to XE_BO_FLAG_NO_COMPRESSION, skips CCS metadata allocation/clearing, and rejects compressed PAT indices at vm_bind. This avoids extra memory ops and manual CCS state handling for buffers. To allow userspace to detect at runtime whether the kernel supports this feature, add DRM_XE_QUERY_CONFIG_FLAG_HAS_NO_COMPRESSION_HINT and expose it via query_config() on Xe2+ platforms. Mesa PR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38425 IGT PR: https://patchwork.freedesktop.org/patch/685180/ v2 - Changed error code from -EINVAL to -EOPNOTSUPP for unsupported flag usage on pre-Xe2 platforms - Fixed checkpatch warning in xe_vm.c - Fixed kernel-doc formatting in xe_drm.h v3 - Rebase - Updated commit title and description - Added UAPI for DRM_XE_QUERY_CONFIG_FLAG_HAS_NO_COMPRESSION_HINT and exposed it via query_config() v4 - Rebase v5 - Included Mesa PR and IGT PR in the commit description - Used xe_pat_index_get_comp_en() to extract the compression v6 - Added XE_IOCTL_DBG() checks for argument validation Suggested-by: Matthew Auld <matthew.auld@intel.com> Suggested-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20251204040402.2692921-2-sanjay.kumar.yadav@intel.com
2025-12-04drm/i915/display: Use a sub-struct for fbc operations in intel_displayVinod Govindapillai
As FBC can utilize the system cache in xe3p_lpd onwards, we need a provision to track which fbc instance is utilizing this cache. A sub-struct at intel_display level to group all the fbc ops will make fbc handling much easier. Introduce a fbc sub-struct and move the fbc instance array into that. v2: changes in commit message Suggested-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20251127115349.249120-2-vinod.govindapillai@intel.com
2025-12-03drm/xe/xe3: Remove graphics IP 30.01 from Wa_18041344222 IP listHarish Chegondi
As per the updated WA database, Wa_18041344222 no longer applies to graphics IP version 30.01. Remove it. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Harish Chegondi <harish.chegondi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/280ab3e8dce8d7a40540ae634a5432694ac17ab0.1763762330.git.harish.chegondi@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-12-03Merge tag 'kbuild-6.19-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux Pull Kbuild updates from Nicolas Schier: - Enable -fms-extensions, allowing anonymous use of tagged struct or union in struct/union (tag kbuild-ms-extensions-6.19). An exemplary conversion patch is added here, too (btrfs). [ Editor's note: the core of this actually came in early through a shared branch and a few other trees - Linus ] - Introduce architecture-specific CC_CAN_LINK and flags for userprogs - Add new packaging target 'modules-cpio-pkg' for building a initramfs cpio w/ kmods - Handle included .c files in gen_compile_commands - Minor kbuild changes: - Use objtree for module signing key path, fixing oot kmod signing - Improve documentation of KBUILD_BUILD_TIMESTAMP - Reuse KBUILD_USERCFLAGS for UAPI, instead of defining twice - Rename scripts/Makefile.extrawarn to Makefile.warn - Drop obsolete types.h check from headers_check.pl - Remove outdated config leak ignore entries * tag 'kbuild-6.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux: kbuild: add target to build a cpio containing modules initramfs: add gen_init_cpio to hostprogs unconditionally kbuild: allow architectures to override CC_CAN_LINK init: deduplicate cc-can-link.sh invocations kbuild: don't enable CC_CAN_LINK if the dummy program generates warnings scripts: headers_install.sh: Remove two outdated config leak ignore entries scripts/clang-tools: Handle included .c files in gen_compile_commands kbuild: uapi: Drop types.h check from headers_check.pl kbuild: Rename Makefile.extrawarn to Makefile.warn MAINTAINERS, .mailmap: Update mail address for Nicolas Schier kbuild: uapi: reuse KBUILD_USERCFLAGS kbuild: doc: improve KBUILD_BUILD_TIMESTAMP documentation kbuild: Use objtree for module signing key path btrfs: send: make use of -fms-extensions for defining struct fs_path
2025-12-03drm/xe: Do not reference loop variable directlyMatthew Brost
Do not reference the loop variable job after the loop has exited. Instead, save the job from the last iteration of the loop. Fixes: 00937fe1921a ("drm/xe/vf: Start re-emission from first unsignaled job during VF migration") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202511291102.jnnKP6IB-lkp@intel.com/ Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patch.msgid.link/20251203011809.968893-1-matthew.brost@intel.com
2025-12-03Merge tag 'printk-for-6.19' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux Pull printk updates from Petr Mladek: - Allow creaing nbcon console drivers with an unsafe write_atomic() callback that can only be called by the final nbcon_atomic_flush_unsafe(). Otherwise, the driver would rely on the kthread. It is going to be used as the-best-effort approach for an experimental nbcon netconsole driver, see https://lore.kernel.org/r/20251121-nbcon-v1-2-503d17b2b4af@debian.org Note that a safe .write_atomic() callback is supposed to work in NMI context. But some networking drivers are not safe even in IRQ context: https://lore.kernel.org/r/oc46gdpmmlly5o44obvmoatfqo5bhpgv7pabpvb6sjuqioymcg@gjsma3ghoz35 In an ideal world, all networking drivers would be fixed first and the atomic flush would be blocked only in NMI context. But it brings the question how reliable networking drivers are when the system is in a bad state. They might block flushing more reliable serial consoles which are more suitable for serious debugging anyway. - Allow to use the last 4 bytes of the printk ring buffer. - Prevent queuing IRQ work and block printk kthreads when consoles are suspended. Otherwise, they create non-necessary churn or even block the suspend. - Release console_lock() between each record in the kthread used for legacy consoles on RT. It might significantly speed up the boot. - Release nbcon context between each record in the atomic flush. It prevents stalls of the related printk kthread after it has lost the ownership in the middle of a record - Add support for NBCON consoles into KDB - Add %ptsP modifier for printing struct timespec64 and use it where possible - Misc code clean up * tag 'printk-for-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux: (48 commits) printk: Use console_is_usable on console_unblank arch: um: kmsg_dump: Use console_is_usable drivers: serial: kgdboc: Drop checks for CON_ENABLED and CON_BOOT lib/vsprintf: Unify FORMAT_STATE_NUM handlers printk: Avoid irq_work for printk_deferred() on suspend printk: Avoid scheduling irq_work on suspend printk: Allow printk_trigger_flush() to flush all types tracing: Switch to use %ptSp scsi: snic: Switch to use %ptSp scsi: fnic: Switch to use %ptSp s390/dasd: Switch to use %ptSp ptp: ocp: Switch to use %ptSp pps: Switch to use %ptSp PCI: epf-test: Switch to use %ptSp net: dsa: sja1105: Switch to use %ptSp mmc: mmc_test: Switch to use %ptSp media: av7110: Switch to use %ptSp ipmi: Switch to use %ptSp igb: Switch to use %ptSp e1000e: Switch to use %ptSp ...
2025-12-03gpu/panel-edp: add AUO panel entry for B140HAN06.4Alexey Klimov
Add an eDP panel entry for AUO B140HAN06.4 that is also used in some variants of Lenovo Flex 5G with Qcom SC8180 SoC. The raw edid of the panel is: 00 ff ff ff ff ff ff 00 06 af 3d 64 00 00 00 00 2b 1d 01 04 a5 1f 11 78 03 b8 1a a6 54 4a 9b 26 0e 52 55 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 14 37 80 b8 70 38 24 40 10 10 3e 00 35 ae 10 00 00 18 10 2c 80 b8 70 38 24 40 10 10 3e 00 35 ae 10 00 00 18 00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 00 42 31 34 30 48 41 4e 30 36 2e 34 20 0a 00 eb I do not have access to the datasheet and but it is tested on above mentioned laptop for a few weeks and seems to work just fine with timing info of similar panels. Cc: Bjorn Andersson <andersson@kernel.org> Cc: Vinod Koul <vkoul@kernel.org> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20251203074555.690613-1-alexey.klimov@linaro.org
2025-12-03drm/xe/sync: Use for_each_tlb_inval() to calculate invalidation fencesMatt Roper
xe_sync_in_fence_get() uses the same kind of mismatched fence array allocation vs looping logic that was previously noted and changed by commit 0a4c2ddc711a ("drm/xe/vm: Use for_each_tlb_inval() to calculate invalidation fences"). As with that commit, the mismatch doesn't cause any problem at the moment since for_each_tlb_inval() loops the same number of times as XE_MAX_GT_PER_TILE (2). However we don't want to assume that these will always be the same in the future, so switch to using for_each_tlb_inval() in both places to future-proof the code. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251202222551.1858930-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-12-03drm/ttm: Tidy usage of local variables a little bitTvrtko Ursulin
At the moment the TTM code has a few places which exibit sub-optimal patterns regarding local variable usage: * Having a local with some object cached but not always using it. * Having a local for a single use object member access. * Failed opportunities to use a local to cache a pointer. Lets tidy this a little bit and apply some more consistency. It is mostly for consistency and redability but I have also checked that there are not negative code generation effects. In fact there are more positives: add/remove: 0/0 grow/shrink: 3/9 up/down: 12/-175 (-163) Function old new delta ttm_pool_restore_and_alloc 415 423 +8 ttm_bo_vunmap 147 149 +2 ttm_bo_evict 521 523 +2 ttm_bo_vm_fault_reserved 972 970 -2 ttm_bo_vm_dummy_page 155 152 -3 ttm_bo_vm_fault 203 196 -7 ttm_bo_populate 158 150 -8 ttm_bo_move_memcpy 600 592 -8 ttm_bo_kmap 667 644 -23 ttm_bo_shrink 333 305 -28 ttm_bo_release 750 720 -30 ttm_bo_swapout_cb 691 625 -66 Total: Before=42717, After=42554, chg -0.38% Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Link: https://lore.kernel.org/r/20250919131530.91247-5-tvrtko.ursulin@igalia.com Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> [tursulin: fixup conflict in ttm_bo_move_pipeline_evict]
2025-12-03drm/ttm: Tidy ttm_operation_ctx initializationTvrtko Ursulin
No need to initialize a subset of fields to zero. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Link: https://lore.kernel.org/r/20250919131530.91247-4-tvrtko.ursulin@igalia.com Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> [tursulin: fixup conflict in ttm_resource_manager_evict_all]
2025-12-03drm/ttm: Resource cannot be NULL in ttm_resource_intersectsTvrtko Ursulin
Function has a single caller and the resource cannot be NULL therefore remove the early return check. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250919131530.91247-3-tvrtko.ursulin@igalia.com
2025-12-03drm/ttm: Make ttm_bo_init_validate safe against ttm_operation_ctx re-orderingTvrtko Ursulin
Struct ttm_operation_ctx initializer in ttm_bo_init_validate assumes the order of the structure fields when it is configuring the interruptible flag. Fix it by using named initialization. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250919131530.91247-2-tvrtko.ursulin@igalia.com
2025-12-03drm/panthor: fix queue_reset_timeout_lockedChia-I Wu
queue_check_job_completion calls queue_reset_timeout_locked to reset the timeout when progress is made. We want the reset to happen when the timeout is running, not when it is suspended. Fixes: 345c5b7cc0f85 ("drm/panthor: Make the timeout per-queue instead of per-job") Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20251202174028.1600218-1-olvaffe@gmail.com
2025-12-03drm/panthor: Remove redundant call to disable the MCUAkash Goel
This commit removes the redundant call to disable the MCU firmware in the suspend path. Fixes: 514072549865 ("drm/panthor: Support GLB_REQ.STATE field for Mali-G1 GPUs") Signed-off-by: Akash Goel <akash.goel@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20251203091911.145623-1-akash.goel@arm.com
2025-12-03drm/panthor: Unlock the locked region before disabling an ASBoris Brezillon
An AS can be disabled in the middle of a VM operation (VM being evicted from an AS slot, for instance). In that case, we need the locked section to be unlocked before releasing the slot. v2: - Add an lockdep_assert_held() in panthor_mmu_as_disable() - Collect R-bs v3: - Don't reset the locked_region range in the as_disable() path Fixes: 6e2d3b3e8589 ("drm/panthor: Add support for atomic page table updates") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20251203121750.404340-4-boris.brezillon@collabora.com
2025-12-03drm/panthor: Make sure caches are flushed/invalidated when an AS is recycledBoris Brezillon
When we re-assign a slot to a different VM, we need to make sure the old VM caches are flushed before doing the switch. Specialize panthor_mmu_as_disable() so we can skip the slot programmation while still getting the cache flushing, and call this helper from panthor_vm_active() when an idle slot is recycled. v2: - Collect R-bs Fixes: 6e2d3b3e8589 ("drm/panthor: Add support for atomic page table updates") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20251203121750.404340-3-boris.brezillon@collabora.com
2025-12-03drm/panthor: Drop a WARN_ON() in group_free_queue()Boris Brezillon
It appears the timeout can still be enabled when we reach that point, because of the asynchronous progress check done on queues that resets the timer when jobs are still in-flight, but progress was made. We could add more checks to make sure the timer is not re-enabled when a group can't run anymore, but we don't have a group to pass to queue_check_job_completion() in some context. It's just as safe (we just want to be sure the timer is stopped before we destroy the queue) and simpler to drop the WARN_ON() in group_free_queue(). v2: - Collect R-bs Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20251203121750.404340-2-boris.brezillon@collabora.com
2025-12-03Merge drm/drm-next into drm-xe-nextThomas Hellström
Backmerging to bring in a needed dependency for the Xe VFIO driver variant. This should ideally have been done before we commited that, so we now have a small window in drm-xe-next where that driver doesn't compile. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512030331.I8CveRre-lkp@intel.com/ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-03drm/gem-shmem: revert the 8-byte alignment constraintLudovic Desroches
Using drm_mode_size_dumb() to compute the size of dumb buffers introduced an 8-byte alignment constraint on the pitch that wasn’t present before. Let’s remove this constraint, which isn’t necessarily required and may cause buffers to be allocated larger than needed. Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 4977dcecb931 ("drm/gem-shmem: Compute dumb-buffer sizes with drm_mode_size_dumb()") Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251126-lcd_pitch_alignment-v1-2-991610a1e369@microchip.com
2025-12-03drm/gem-dma: revert the 8-byte alignment constraintLudovic Desroches
Using drm_mode_size_dumb() to compute the size of dumb buffers introduced an 8-byte alignment constraint on the pitch that wasn’t present before. Let’s remove this constraint, which isn’t necessarily required and may cause buffers to be allocated larger than needed. Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: dcacfcd35cef ("drm/gem-dma: Compute dumb-buffer sizes with drm_mode_size_dumb()") Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251126-lcd_pitch_alignment-v1-1-991610a1e369@microchip.com
2025-12-03drm/i915/crtc: Expose sharpness only if num_scalers is >= 2Nemesa Garg
CASF requires the second scaler for sharpness. Do not expose the SHARPNESS_STRENGTH property if the CRTC has fewer than two scalers. v2: Modify header and commit message. [Ankit] Signed-off-by: Nemesa Garg <nemesa.garg@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Link: https://patch.msgid.link/20251126084152.3905905-1-nemesa.garg@intel.com
2025-12-03Merge tag 'amd-drm-next-6.19-2025-12-02' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.19-2025-12-02: amdgpu: - Unified MES fix - SMU 11 unbalanced irq fix - Fix for driver reloading on APUs - pp_table sysfs fix - Fix memory leak in fence handling - HDMI fix - DC cursor fixes - eDP panel parsing fix - Brightness fix - DC analog fixes - EDID retry fixes - UserQ fixes - RAS fixes - IP discovery fix - Add missing locking in amdgpu_ttm_access_memory_sdma() - Smart Power OLED fix - PRT and page fault fixes for GC 6-8 - VMID reservation fix - ACP platform device fix - Add missing vm fault handling for GC 11-12 - VPE fix amdkfd: - Partitioning fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20251202220101.2039347-1-alexander.deucher@amd.com
2025-12-02drm/i915/display: Use HAS_LT_PHY() for LT PHY AUX powerGustavo Sousa
Bspec states that the new AUX power enable/disable sequences are associated with the LT PHY. As such, use HAS_LT_PHY() instead of IP checks in those paths in the driver code. While at it, also move the comment that we can't use the power status flag to the "else" branch, since that comment is not applicable for the LT PHY. Bspec: 68967 Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Suggested-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20251202012306.9315-9-matthew.s.atwood@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-12-02drm/i915/display: Move HAS_LT_PHY() to intel_display_device.hGustavo Sousa
We will need to HAS_LT_PHY() that macro in code outside of LT PHY implementation. Move its definition to intel_display_device.h. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20251202012306.9315-8-matthew.s.atwood@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-12-02drm/i915/display: Use platform check in HAS_LT_PHY()Gustavo Sousa
NVL uses the Lake Tahoe PHY for display output and the driver recently added the macro HAS_LT_PHY() to allow selecting code paths specific for that type of PHY. While NVL uses Xe3p_LPD as display IP, the type of PHY is actually defined at the SoC level, so use a platform check instead of display version. Bspec: 74199 Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20251202012306.9315-7-matthew.s.atwood@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-12-02drm/i915/nvls: Add NVL-S display supportSai Teja Pottumuttu
Add platform description and PCI IDs for NVL-S. BSpec: 74201 Signed-off-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20251202012306.9315-6-matthew.s.atwood@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-12-02drm/i915/xe3p_lpd: Handle underrun debug bitsGustavo Sousa
Xe3p_LPD added several bits containing information that can be relevant to debugging FIFO underruns. Add the logic necessary to handle them when reporting underruns. This was adapted from the initial patch[1] from Sai Teja Pottumuttu. [1] https://lore.kernel.org/all/20251015-xe3p_lpd-basic-enabling-v1-12-d2d1e26520aa@intel.com/ v2: - Handle FBC-related bits in intel_fbc.c. (Ville) - Do not use intel_fbc_id_for_pipe (promoted from skl_fbc_id_for_pipe), but use pipe's primary plane to get the FBC instance. (Ville, Matt) - Improve code readability by moving logic specific to logging fields of UNDERRUN_DBG1 to a separate function. (Jani) v3: - Use crtc->base.primary instead of cycling through all crtcs Bspec: 69111, 69561, 74411, 74412 Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patch.msgid.link/20251202012306.9315-5-matthew.s.atwood@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-12-02drm/i915/display: Handle dedicated external ports in intel_encoder_is_tc()Gustavo Sousa
Starting with Xe3p_LPD, the VBT has a new field, called in the driver "dedicated_external", which tells that a Type-C capable port is physically connected to a PHY outside of the Type-C subsystem. When that's the case, the driver must not do the extra Type-C programming for that port. Update intel_encoder_is_tc() to check for that case. While at it, add a note to intel_phy_is_tc() to remind us that it is about whether the respective port is a Type-C capable port rather than the PHY itself. (Maybe it would be a nice idea to rename intel_phy_is_tc()?) Note that this was handled with a new bool member added to struct intel_digital_port instead of having querying the VBT directly because VBT memory is freed (intel_bios_driver_remove) before encoder cleanup (intel_ddi_encoder_destroy), which would cause an oops to happen when the latter calls intel_encoder_is_tc(). This could be fixed by keeping VBT data around longer, but that's left for a follow-up work, if deemed necessary. v2: - Drop printing info about dedicated external, now that we are doing it when parsing the VBT. (Jani) - Add a FIXME comment on the code explaining why we need to store dedicated_external in struct intel_digital_port. (Jani) v3: - Simplify the code by using NULL check for dig_port to avoid using intel_encoder_is_dig_port(). (Imre) Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Shekhar Chauhan <shekhar.chauhan@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251202012306.9315-4-matthew.s.atwood@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-12-02drm/i915/power: Use intel_encoder_is_tc()Gustavo Sousa
Starting with Xe3p_LPD, when intel_phy_is_tc() returns true, it does not necessarily mean that the port is connected to a PHY in the Type-C subsystem. The reason is that there is now a VBT field called dedicated_external that will indicate that a Type-C capable port is connected to a (most likely) combo/dedicated PHY. When that's the case, we must not do the extra programming required for Type-C connections. In an upcoming change, we will modify intel_encoder_is_tc() to take the VBT field dedicated_external into consideration. Update intel_display_power_well.c to use that function instead of intel_phy_is_tc(). Note that, even though icl_aux_power_well_{enable,disable} are not part of Xe3p_LPD's display paths, we modify them anyway for uniformity. v2: - Add and use icl_aux_pw_is_tc_phy() helper to avoid explicit encoder lookup. (Imre) Cc: Imre Deak <imre.deak@intel.com> Cc: Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> # v1 Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251202012306.9315-3-matthew.s.atwood@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-12-02drm/i915/vbt: Add fields dedicated_external and dyn_port_over_tcGustavo Sousa
VBT version 264 adds new fields associated to Xe3p_LPD's new ways of configuring SoC for TC ports and PHYs. Update the code to match the updates in VBT. The new field dedicated_external is used to represent TC ports that are connected to PHYs outside of the Type-C subsystem, meaning that they behave like dedicated ports and don't require the extra Type-C programming. In an upcoming change, we will update the driver to take this field into consideration when detecting the type of port. The new field dyn_port_over_tc is used to inform that the TC port can be dynamically allocated for a legacy connector in the Type-C subsystem, which is a new feature in Xe3p_LPD. In upcoming changes, we will use that field in order to handle the IOM resource management programming required for that. Note that, when dedicated_external is set, the fields dp_usb_type_c and tbt are tagged as "don't care" in the spec, so they should be ignored in that case, so also add a sanitization function to take care of forcing them to zero when dedicated_external is true. v2: - Use sanitization function to force dp_usb_type_c and tbt fields to be zero instead of adding a intel_bios_encoder_is_dedicated_external() check in each of their respective accessor functions. (Jani) - Print info about dedicated external ports in print_ddi_port(). (Jani) v3: - Also zero out field dyn_port_over_tc when dedicated_external is set. (Imre) - Use intel_bios_encoder_is_dedicated_external() directly instead of storing return value into variable in print_ddi_port(). (Imre) - Also print info for dyn_port_over_tc in print_ddi_port(). (Imre) Bspec: 20124, 68954, 74304 Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Shekhar Chauhan <shekhar.chauhan@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251202012306.9315-2-matthew.s.atwood@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-12-02Revert "drm/amd: Skip power ungate during suspend for VPE"Mario Limonciello (AMD)
Skipping power ungate exposed some scenarios that will fail like below: ``` amdgpu: Register(0) [regVPEC_QUEUE_RESET_REQ] failed to reach value 0x00000000 != 0x00000001n amdgpu 0000:c1:00.0: amdgpu: VPE queue reset failed ... amdgpu: [drm] *ERROR* wait_for_completion_timeout timeout! ``` The underlying s2idle issue that prompted this commit is going to be fixed in BIOS. This reverts commit 2a6c826cfeedd7714611ac115371a959ead55bda. Fixes: 2a6c826cfeed ("drm/amd: Skip power ungate during suspend for VPE") Cc: stable@vger.kernel.org Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reported-by: Konstantin <answer2019@yandex.ru> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220812 Reported-by: Matthew Schwartz <matthew.schwartz@linux.dev> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-12-02drm/amdgpu: use common defines for HUB faultsAlex Deucher
Use common definitions for the fault bits in the IH sourc data for the gmc9-12 memory hub faults Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-12-02drm/amdgpu/gmc12: add amdgpu_vm_handle_fault() handlingAlex Deucher
We need to call amdgpu_vm_handle_fault() on page fault on all gfx9 and newer parts to properly update the page tables, not just for recoverable page faults. Cc: stable@vger.kernel.org Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-12-02drm/amdgpu/gmc11: add amdgpu_vm_handle_fault() handlingAlex Deucher
We need to call amdgpu_vm_handle_fault() on page fault on all gfx9 and newer parts to properly update the page tables, not just for recoverable page faults. Cc: stable@vger.kernel.org Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-12-02drm/amdgpu: use static ids for ACP platform devsBrady Norander
mfd_add_hotplug_devices() assigns child platform devices with PLATFORM_DEVID_AUTO, but the ACP machine drivers expect the platform device names to never change. Use mfd_add_devices() instead and give each cell a unique id. Signed-off-by: Brady Norander <bradynorander@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-12-02drm/amdgpu/sdma6: Update SDMA 6.0.3 FW version to include UMQ ↵Srinivasan Shanmugam
protected-fence fix On GFX11.0.3, earlier SDMA firmware versions issue the PROTECTED_FENCE write from the user VMID (e.g. VMID 8) instead of VMID 0. This causes a GPU VM protection fault when SDMA tries to write the secure fence location, as seen in the UMQ SDMA test (cs-sdma-with-IP-DMA-UMQ) Fixes the below GPU page fault: [ 514.037189] amdgpu 0000:0b:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:40 vmid:8 pasid:32770) [ 514.037199] amdgpu 0000:0b:00.0: amdgpu: Process pid 0 thread pid 0 [ 514.037205] amdgpu 0000:0b:00.0: amdgpu: in page starting at address 0x00007fff00409000 from client 10 [ 514.037212] amdgpu 0000:0b:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00841A51 [ 514.037217] amdgpu 0000:0b:00.0: amdgpu: Faulty UTCL2 client ID: SDMA0 (0xd) [ 514.037223] amdgpu 0000:0b:00.0: amdgpu: MORE_FAULTS: 0x1 [ 514.037227] amdgpu 0000:0b:00.0: amdgpu: WALKER_ERROR: 0x0 [ 514.037232] amdgpu 0000:0b:00.0: amdgpu: PERMISSION_FAULTS: 0x5 [ 514.037236] amdgpu 0000:0b:00.0: amdgpu: MAPPING_ERROR: 0x0 [ 514.037241] amdgpu 0000:0b:00.0: amdgpu: RW: 0x1 v2: Updated commit message v3: s/gfx11.0.3/sdma 6.0.3/ in patch title (Alex) Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-12-02drm/amdgpu: Forward VMID reservation errorsNatalie Vock
Otherwise userspace may be fooled into believing it has a reserved VMID when in reality it doesn't, ultimately leading to GPU hangs when SPM is used. Fixes: 80e709ee6ecc ("drm/amdgpu: add option params to enforce process isolation between graphics and compute") Cc: stable@vger.kernel.org Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Natalie Vock <natalie.vock@gmx.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-12-02drm/amdgpu/gmc8: Delegate VM faults to soft IRQ handler ringTimur Kristóf
On old GPUs, it may be an issue that handling the interrupts from VM faults is too slow and the interrupt handler (IH) ring may overflow, which can cause an eventual hang. Delegate the processing of all VM faults to the soft IRQ handler ring. As a result, we spend much less time in the IRQ handler that interacts with the HW IH ring, which significantly reduces the chance of hangs/reboots. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-12-02drm/amdgpu/gmc7: Delegate VM faults to soft IRQ handler ringTimur Kristóf
On old GPUs, it may be an issue that handling the interrupts from VM faults is too slow and the interrupt handler (IH) ring may overflow, which can cause an eventual hang. Delegate the processing of all VM faults to the soft IRQ handler ring. As a result, we spend much less time in the IRQ handler that interacts with the HW IH ring, which significantly reduces the chance of hangs/reboots. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-12-02drm/amdgpu/gmc6: Delegate VM faults to soft IRQ handler ringTimur Kristóf
On old GPUs, it may be an issue that handling the interrupts from VM faults is too slow and the interrupt handler (IH) ring may overflow, which can cause an eventual hang. Delegate the processing of all VM faults to the soft IRQ handler ring. As a result, we spend much less time in the IRQ handler that interacts with the HW IH ring, which significantly reduces the chance of hangs/reboots. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-12-02drm/amdgpu/gmc6: Cache VM fault infoTimur Kristóf
Call amdgpu_vm_update_fault_cache on GMC v6 similarly to how we do in GMC v7-v8 so that VM fault info can be used later by userspace for debugging. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-12-02drm/amdgpu/gmc6: Don't print MC client as it's unknownTimur Kristóf
The VM_CONTEXT1_PROTECTION_FAULT_MCCLIENT register doesn't exist on GMC v6 so we can't print the MC client as a string like we do on GMC v7-v8. However, we still print the mc_id from VM_CONTEXT1_PROTECTION_FAULT_STATUS. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-12-02drm/amdgpu/cz_ih: Enable soft IRQ handler ringTimur Kristóf
We are going to use the soft IRQ handler ring on GMC v8 to process interrupts from VM faults. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.46.0) at 2026-05-15 06:08:55 +0000