Luca Ceresoli [Wed, 12 Nov 2025 16:34:35 +0000 (17:34 +0100)]
drm/bridge: ti-sn65dsi83: protect device resources on unplug
To support hot-unplug of this bridge we need to protect access to device
resources in case sn65dsi83_remove() happens concurrently to other code.
Some care is needed for the case when the unplug happens before
sn65dsi83_atomic_disable() has a chance to enter the critical section
(i.e. a successful drm_bridge_enter() call), which occurs whenever the
hardware is removed while the display is active. When that happens,
sn65dsi83_atomic_disable() in unable to release the resources taken by
sn65dsi83_atomic_pre_enable().
To ensure those resources are released exactly once on device removal:
* move the code to release them to a dedicated function
* register that function when the resources are taken in
sn65dsi83_atomic_pre_enable()
* if sn65dsi83_atomic_disable() happens before sn65dsi83_remove()
(typical non-hot-unplug case):
* sn65dsi83_atomic_disable() can enter the critical section
(drm_bridge_enter() returns 0) -> it releases and executes the
devres action
* if sn65dsi83_atomic_disable() happens after sn65dsi83_remove()
(typical hot-unplug case):
* sn65dsi83_remove() -> drm_bridge_unplug() prevents
sn65dsi83_atomic_disable() from entering the critical section
(drm_bridge_enter() returns nonzero), so sn65dsi83_atomic_disable()
cannot release and execute the devres action
* the devres action is executed at the end of sn65dsi83_remove()
Luca Ceresoli [Wed, 12 Nov 2025 16:34:34 +0000 (17:34 +0100)]
drm/bridge: add drm_bridge_unplug() and drm_bridge_enter/exit()
To allow DRM bridges to be removable, add synchronization functions
allowing to tell when a bridge hardware has been physically unplugged and
to mark a critical section that should not be entered after that.
This is inspired by the drm_dev_unplugged/enter/exit() functions for struct
drm_device.
Eslam Khafagy [Tue, 25 Nov 2025 19:38:45 +0000 (21:38 +0200)]
drm: pl111: replace dev_* print functions with drm_* variants
Update the PL111 CLCD driver to use DRM print macros drm_*() instead of
dev_*(). This change ensures consistency with DRM subsystem
logging conventions [1].
Lizhi Hou [Tue, 9 Dec 2025 21:16:39 +0000 (13:16 -0800)]
accel/amdxdna: Fix cu_idx being cleared by memset() during command setup
For one command type, cu_idx is assigned before calling memset() on the
command structure. This results in cu_idx being overwritten, causing the
firmware to receive an incomplete or invalid command and leading to
unexpected command failures.
Fix this by moving the memset() call before initializing cu_idx so that
all fields are populated in the correct order.
Lizhi Hou [Mon, 8 Dec 2025 16:53:56 +0000 (08:53 -0800)]
accel/amdxdna: Fix race condition when checking rpm_on
When autosuspend is triggered, driver rpm_on flag is set to indicate that
a suspend/resume is already in progress. However, when a userspace
application submits a command during this narrow window,
amdxdna_pm_resume_get() may incorrectly skip the resume operation because
the rpm_on flag is still set. This results in commands being submitted
while the device has not actually resumed, causing unexpected behavior.
The set_dpm() is called by suspend/resume, it relied on rpm_on flag to
avoid calling into rpm suspend/resume recursivly. So to fix this, remove
the use of the rpm_on flag entirely. Instead, introduce aie2_pm_set_dpm()
which explicitly resumes the device before invoking set_dpm(). With this
change, set_dpm() is called directly inside the suspend or resume execution
path. Otherwise, aie2_pm_set_dpm() is called.
Fixes: 063db451832b ("accel/amdxdna: Enhance runtime power management") Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Maciej Falkowski <maciej.falkowski@linux.intel.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20251208165356.1549237-1-lizhi.hou@amd.com
Faith Ekstrand [Mon, 8 Dec 2025 10:08:39 +0000 (11:08 +0100)]
drm/panfrost: Add flag to map GEM object Write-Back Cacheable
Will be used by the UMD to optimize CPU accesses to buffers
that are frequently read by the CPU, or on which the access
pattern makes non-cacheable mappings inefficient.
Mapping buffers CPU-cached implies taking care of the CPU
cache maintenance in the UMD, unless the GPU is IO coherent.
v2:
- Add more to the commit message
v3:
- No changes
v4:
- Fix the map_wc test in panfrost_ioctl_query_bo_info()
v5:
- Drop Steve's R-b (enough has changed to justify a new review)
Faith Ekstrand [Mon, 8 Dec 2025 10:08:37 +0000 (11:08 +0100)]
drm/panfrost: Add a PANFROST_SYNC_BO ioctl
This will be used by the UMD to synchronize CPU-cached mappings when
the UMD can't do it directly (no usermode cache maintenance instruction
on Arm32).
v2:
- Add more to the commit message
- Change the flags to better match the drm_gem_shmem_sync semantics
v3:
- Add Steve's R-b
v4:
- No changes
v5:
- Drop Steve's R-b (semantics changes requiring a new review)
v6:
- Bail out early in panfrost_ioctl_sync_bo() if op_count is zero
Boris Brezillon [Mon, 8 Dec 2025 10:08:35 +0000 (11:08 +0100)]
drm/panfrost: Provide a custom dma_buf implementation
Before we introduce cached CPU mappings, we want a dma_buf
implementation satisfying synchronization requests around CPU
accesses coming from a dma_buf exported by our driver. Let's
provide our own implementation relying on the default
gem_shmem_prime helpers designed for that purpose.
Loïc Molinari [Mon, 8 Dec 2025 10:08:33 +0000 (11:08 +0100)]
drm/panthor: Add flag to map GEM object Write-Back Cacheable
Will be used by the UMD to optimize CPU accesses to buffers
that are frequently read by the CPU, or on which the access
pattern makes non-cacheable mappings inefficient.
Mapping buffers CPU-cached implies taking care of the CPU
cache maintenance in the UMD, unless the GPU is IO coherent.
v2:
- Add more to the commit message
- Tweak the doc
- Make sure we sync the section of the BO pointing to the CS
syncobj before we read its seqno
v3:
- Fix formatting/spelling issues
v4:
- Add Steve's R-b
v5:
- Drop Steve's R-b (changes in the ioctl semantics requiring
new review)
v6:
- Fix the uAPI doc
- Fix inverted logic in some comment
Boris Brezillon [Mon, 8 Dec 2025 10:08:32 +0000 (11:08 +0100)]
drm/panthor: Add an ioctl to query BO flags
This is useful when importing BOs, so we can know about cacheability
and flush the caches when needed.
We can also know when the buffer comes from a different subsystem and
take proper actions (avoid CPU mappings, or do kernel-based syncs
instead of userland cache flushes).
Boris Brezillon [Mon, 8 Dec 2025 10:08:31 +0000 (11:08 +0100)]
drm/panthor: Add a PANTHOR_BO_SYNC ioctl
This will be used by the UMD to synchronize CPU-cached mappings when
the UMD can't do it directly (no usermode cache maintenance instruction
on Arm32).
v2:
- Change the flags so they better match the drm_gem_shmem_sync()
semantics
v3:
- Add Steve's R-b
v4:
- No changes
v5:
- Drop Steve's R-b (the semantics changes call for a new review)
v6:
- Drop ret initialization in panthor_ioctl_bo_sync()
- Bail out early in panthor_ioctl_bo_sync() if ops.count is zero
- Drop unused PANTHOR_BO_SYNC_OP_FLAGS definition
v7:
- Hand-roll the sync logic (was previously provided by gem_shmem)
Boris Brezillon [Mon, 8 Dec 2025 10:08:30 +0000 (11:08 +0100)]
drm/panthor: Expose the selected coherency protocol to the UMD
If we want to be able to skip CPU cache maintenance operations on
CPU-cached mappings, the UMD needs to know the kind of coherency
in place. Add a field to drm_panthor_gpu_info to do that. We can re-use
a padding field for that since this object is write-only from the
KMD perspective, and the UMD should just ignore it.
v2:
- New commit
v3:
- Make coherency protocol a real enum, not a bitmask
- Add BUILD_BUG_ON()s to make sure the values in panthor_regs.h and
those exposed through the uAPI match
Boris Brezillon [Mon, 8 Dec 2025 10:08:28 +0000 (11:08 +0100)]
drm/panthor: Provide a custom dma_buf implementation
Before we introduce cached CPU mappings, we want a dma_buf
implementation satisfying synchronization requests around CPU
accesses coming from a dma_buf exported by our driver. Let's
provide our own implementation relying on the default
gem_shmem_prime helpers designed for that purpose.
v5:
- New patch
v6:
- Collect R-b
v7:
- Hand-roll the dma_buf sync/import logic (was previously done by
generic prime/shmem helpers)
Val Packett [Sat, 6 Dec 2025 17:37:28 +0000 (14:37 -0300)]
drm/panel-edp: Add AUO B140QAX01.H panel
A 14-inch 2560x1600 60Hz matte touch panel, found on a Dell Latitude 7455
laptop (second-source with BOE NE14QDM), according to online sources it's
also found on the Latitude 7440 and some ASUS models.
Don't have datasheet access, but the same timing as for other panels from
the same manufacturer works fine.
Signed-off-by: Val Packett <val@packett.cool>
[dianders: Moved to the right location in the table] Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20251206173739.2222940-1-val@packett.cool
Lizhi Hou [Thu, 4 Dec 2025 18:16:03 +0000 (10:16 -0800)]
accel/amdxdna: Fix tail-pointer polling in mailbox_get_msg()
In mailbox_get_msg(), mailbox_reg_read_non_zero() is called to poll for a
non-zero tail pointer. This assumed that a zero value indicates an error.
However, certain corner cases legitimately produce a zero tail pointer.
To handle these cases, remove mailbox_reg_read_non_zero(). The zero tail
pointer will be treated as a valid rewind event.
Christian König [Fri, 19 Sep 2025 14:40:06 +0000 (16:40 +0200)]
dma-buf: improve sg_table debugging hack v4
This debugging hack is important to enforce the rule that importers
should *never* touch the underlying struct page of the exporter.
Instead of just mangling the page link create a copy of the sg_table
but only copy over the DMA addresses and not the pages.
This will cause a NULL pointer de-reference if the importer tries to
touch the struct page. Still quite a hack but this at least allows the
exporter to properly keeps it's sg_table intact while allowing the
DMA-buf maintainer to find and fix misbehaving importers and finally
switch over to using a different data structure in the future.
v2: improve the hack further by using a wrapper structure and explaining
the background a bit more in the commit message.
v3: fix some whitespace issues, use sg_assign_page().
v4: give the functions a better name
Loïc Molinari [Fri, 5 Dec 2025 18:22:31 +0000 (19:22 +0100)]
Documentation/gpu/drm-mm: Add THP paragraph to GEM mapping section
Add a paragraph to the GEM Objects Creation section about the
drm_gem_huge_mnt_create() helper and to the GEM objects mapping
section explaining how transparent huge pages are handled by GEM.
v4:
- fix wording after huge_pages handler removal
v6:
- fix wording after map_pages handler removal
v11:
- mention drm_gem_huge_mnt_create() helper
- add Boris and Maíra R-bs
Introduce the 'panfrost.transparent_hugepage' boolean module parameter
(false by default). When the parameter is set to true, a new tmpfs
mountpoint is created and mounted using the 'huge=within_size'
option. It's then used at GEM object creation instead of the default
'shm_mnt' mountpoint in order to enable Transparent Hugepage (THP) for
the object (without having to rely on a system wide parameter).
v3:
- use huge tmpfs mountpoint in drm_device
v4:
- fix builds with CONFIG_TRANSPARENT_HUGEPAGE=n
- clean up mountpoint creation error handling
- print negative error value
v5:
- use drm_gem_has_huge_tmp() helper
- get rid of CONFIG_TRANSPARENT_HUGEPAGE ifdefs
v9:
- replace drm_gem_has_huge_tmp() by drm_gem_get_huge_tmp()
v11:
- enable 'panfrost.transparent_hugepage' by default
Introduce the 'panthor.transparent_hugepage' boolean module parameter
(false by default). When the parameter is set to true, a new tmpfs
mountpoint is created and mounted using the 'huge=within_size'
option. It's then used at GEM object creation instead of the default
'shm_mnt' mountpoint in order to enable Transparent Hugepage (THP) for
the object (without having to rely on a system wide parameter).
v3:
- use huge tmpfs mountpoint in drm_device
v4:
- fix builds with CONFIG_TRANSPARENT_HUGEPAGE=n
- clean up mountpoint creation error handling
- print negative error value
v5:
- use drm_gem_has_huge_tmp() helper
- get rid of CONFIG_TRANSPARENT_HUGEPAGE ifdefs
v9:
- replace drm_gem_has_huge_tmp() by drm_gem_get_huge_tmp()
v11:
- enable 'panthor.transparent_hugepage' by default
Loïc Molinari [Fri, 5 Dec 2025 18:22:28 +0000 (19:22 +0100)]
drm/gem: Get rid of *_with_mnt helpers
drm_gem_object_init_with_mnt() and drm_gem_shmem_create_with_mnt() can
be removed now that the drivers use the new drm_gem_huge_mnt_create()
and drm_gem_get_huge_mnt() helpers.
v5:
- use drm_gem_has_huge_mnt() helper
- compile out shmem_file_setup_with_mnt() call in builds with
CONFIG_TRANSPARENT_HUGEPAGE=n
v9:
- replace drm_gem_has_huge_mnt() with drm_gem_get_huge_mnt()
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://patch.msgid.link/20251205182231.194072-8-loic.molinari@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Loïc Molinari [Fri, 5 Dec 2025 18:22:27 +0000 (19:22 +0100)]
drm/v3d: Use huge tmpfs mountpoint helpers
Make use of the new drm_gem_huge_mnt_create() and
drm_gem_get_huge_mnt() helpers to avoid code duplication. Now that
it's just a few lines long, the single function in v3d_gemfs.c is
moved into v3d_gem.c.
v3:
- use huge tmpfs mountpoint in drm_device
- move v3d_gemfs.c into v3d_gem.c
v4:
- clean up mountpoint creation error handling
v5:
- fix CONFIG_TRANSPARENT_HUGEPAGE check
- use drm_gem_has_huge_mnt() helper
v8:
- don't access huge_mnt field with CONFIG_TRANSPARENT_HUGEPAGE=n
v9:
- replace drm_gem_has_huge_mnt() by drm_gem_get_huge_mnt()
v10:
- get rid of CONFIG_TRANSPARENT_HUGEPAGE ifdefs
v11:
- remove superfluous comment
- add Maíra and Boris R-bs
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20251205182231.194072-7-loic.molinari@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Loïc Molinari [Fri, 5 Dec 2025 18:22:26 +0000 (19:22 +0100)]
drm/i915: Use huge tmpfs mountpoint helpers
Make use of the new drm_gem_huge_mnt_create() and
drm_gem_get_huge_mnt() helpers to avoid code duplication. Now that
it's just a few lines long, the single function in i915_gemfs.c is
moved into i915_gem_shmem.c.
v3:
- use huge tmpfs mountpoint in drm_device
- move i915_gemfs.c into i915_gem_shmem.c
v4:
- clean up mountpoint creation error handling
v5:
- use drm_gem_has_huge_mnt() helper
v7:
- include <drm/drm_print.h> in i915_gem_shmem.c
v8:
- keep logging notice message with CONFIG_TRANSPARENT_HUGEPAGE=n
- don't access huge_mnt field with CONFIG_TRANSPARENT_HUGEPAGE=n
v9:
- replace drm_gem_has_huge_mnt() by drm_gem_get_huge_mnt()
- remove useless ternary op test in selftests/huge_pages.c
v12:
- fix layering violation in selftests (Tvrtko)
- fix incorrect filename in commit message
Loïc Molinari [Fri, 5 Dec 2025 18:22:25 +0000 (19:22 +0100)]
drm/gem: Add huge tmpfs mountpoint helpers
Add the drm_gem_huge_mnt_create() and drm_gem_get_huge_mnt() helpers
to avoid code duplication in the i915, V3D, Panfrost and Panthor
drivers. The former creates and mounts a dedicated huge tmpfs
mountpoint, for the lifetime of a DRM device, used at GEM object
initialization. The latter retrieves the dedicated huge tmpfs
mountpoint used by a DRM device.
The next commits will port drivers to these helpers.
v3:
- store huge tmpfs mountpoint in drm_device
v4:
- return 0 in builds with CONFIG_TRANSPARENT_HUGEPAGE=n
- return 0 when huge_mnt already exists
- use new vfs_parse_fs_string() helper
v5:
- remove warning on !dev->huge_mnt and reset to NULL on free
- inline drm_gem_huge_mnt_create() to remove func from text and avoid
calls in builds with CONFIG_TRANSPARENT_HUGEPAGE=n
- compile out drm_device's huge_mnt field in builds with
CONFIG_TRANSPARENT_HUGEPAGE=n
- add drm_gem_has_huge_mnt() helper
v6:
- move huge_mnt doc into ifdef'd section
- either inline or export drm_gem_huge_mnt_create()
v7:
- include <drm/drm_device.h> in drm_gem.h
v9:
- replace drm_gem_has_huge_mnt() by drm_gem_get_huge_mnt()
v11:
- doc fixes
- add Boris and Maíra R-bs
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://patch.msgid.link/20251205182231.194072-5-loic.molinari@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
mmap() calls on the DRM file pointer currently always end up using
mm_get_unmapped_area() to get a free mapping region. On builds with
CONFIG_TRANSPARENT_HUGEPAGE enabled, this isn't ideal for GEM objects
backed by shmem buffers on mountpoints setting the 'huge=' option
because it can't correctly figure out the potentially huge address
alignment required.
This commit introduces the drm_gem_get_unmapped_area() function which
is meant to be used as a get_unmapped_area file operation on the DRM
file pointer to lookup GEM objects based on their fake offsets and get
a properly aligned region by calling shmem_get_unmapped_area() with
the right file pointer. If a GEM object isn't available at the given
offset or if the caller isn't granted access to it, the function falls
back to mm_get_unmapped_area().
This also makes drm_gem_get_unmapped_area() part of the default GEM
file operations so that all the DRM drivers can benefit from more
efficient mappings thanks to the huge page fault handler introduced in
previous commit 'drm/shmem-helper: Add huge page fault handler'.
The shmem_get_unmapped_area() function needs to be exported so that
it can be used from the DRM subsystem.
v3:
- include <linux/sched/mm.h> in drm_gem.c
- forward to shmem layer in builds with CONFIG_TRANSPARENT_HUGEPAGE=n
v6:
- use GPL variant to export drm_gem_get_unmapped_area()
- don't export shmem_get_unmapped_area() anymore (use f_op instead)
v11:
- rename drm_gem_object_lookup_from_offset() to
drm_gem_object_lookup_at_offset()
- add Boris R-b
Loïc Molinari [Fri, 5 Dec 2025 18:22:23 +0000 (19:22 +0100)]
drm/shmem-helper: Map huge pages in fault handler
Attempt a PMD sized PFN insertion into the VMA if the faulty address
of the fault handler is part of a huge page.
On builds with CONFIG_TRANSPARENT_HUGEPAGE enabled, if the mmap() user
address is PMD size aligned, if the GEM object is backed by shmem
buffers on mountpoints setting the 'huge=' option and if the shmem
backing store manages to allocate a huge folio, CPU mapping would then
benefit from significantly increased memcpy() performance. When these
conditions are met on a system with 2 MiB huge pages, an aligned copy
of 2 MiB would raise a single page fault instead of 4096.
v4:
- implement map_pages instead of huge_fault
v6:
- get rid of map_pages handler for now (keep it for another series
along with arm64 contpte support)
v11:
- remove page fault validity check helper
- rename drm_gem_shmem_map_pmd() to drm_gem_shmem_try_map_pmd()
- add Boris R-b
v12:
- move up ret var decl in fault handler to minimize diff
Ashley Smith [Thu, 27 Nov 2025 11:44:02 +0000 (11:44 +0000)]
drm/panthor: Enable timestamp propagation
Set the GLB_COUNTER_EN bit to enable coherent propagation of GPU
timestamp values to shader cores. This is a prerequisite for exposing
device-coherent timestamp queries.
Bump the version to 1.6 so userspace can detect support.
v2:
- GLB_COUNTER_EN is not a toggle bit move to panthor_fw_update_reqs
Philipp Stanner [Mon, 1 Dec 2025 10:50:10 +0000 (11:50 +0100)]
drm/ttm: Use dma_fence_check_and_signal()
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.
Philipp Stanner [Mon, 1 Dec 2025 10:50:09 +0000 (11:50 +0100)]
dma-buf: Don't misuse dma_fence_signal()
The return code of dma_fence_signal() is not really useful as there is
nothing reasonable to do if a fence was already signaled. That return
code shall be removed from the kernel.
Moreover, dma_fence_signal() should not be used to check whether fences
are signaled. That's what dma_fence_is_signaled() and
dma_fence_test_signaled_flag() exist for.
Replace the non-canonical usage of dma_fence_signal().
Philipp Stanner [Mon, 1 Dec 2025 10:50:08 +0000 (11:50 +0100)]
drm/xe: Use dma_fence_check_and_signal_locked()
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
Philipp Stanner [Mon, 1 Dec 2025 10:50:07 +0000 (11:50 +0100)]
amd/amdkfd: Use dma_fence_check_and_signal()
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
The overwhelming majority of users of dma_fence signaling functions
don't care about whether the fence had already been signaled by someone
else. Therefore, the return code shall be removed from those functions.
For the few users who rely on the check, a new, specialized function
shall be provided.
Add dma_fence_check_and_signal(), which signals a fence if it had not
yet been signaled, and informs the user about that.
Add a counter part, dma_fence_check_and_signal_locked(), which doesn't
take the spinlock.
The dma_fence framework checks at many places whether the signaled flag
of a fence is already set. The code can be simplified and made more
readable by providing a helper function for that.
Add dma_fence_test_signaled_flag(), which only checks whether a fence is
signaled. Use it internally.
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
drm/ttm: Tidy usage of local variables a little bit
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:
Chia-I Wu [Tue, 2 Dec 2025 17:40:28 +0000 (09:40 -0800)]
drm/panthor: fix queue_reset_timeout_locked
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.
Boris Brezillon [Wed, 3 Dec 2025 12:17:50 +0000 (13:17 +0100)]
drm/panthor: Unlock the locked region before disabling an AS
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
Boris Brezillon [Wed, 3 Dec 2025 12:17:49 +0000 (13:17 +0100)]
drm/panthor: Make sure caches are flushed/invalidated when an AS is recycled
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
Boris Brezillon [Wed, 3 Dec 2025 12:17:48 +0000 (13:17 +0100)]
drm/panthor: Drop a WARN_ON() in group_free_queue()
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().
Lizhi Hou [Tue, 2 Dec 2025 16:54:27 +0000 (08:54 -0800)]
accel/amdxdna: Poll MPNPU_PWAITMODE after requesting firmware suspend
After issuing a firmware suspend request, the driver must ensure that the
suspend operation has completed before proceeding. Add polling of the
MPNPU_PWAITMODE register to confirm that the firmware has fully entered
the suspended state. This prevents race conditions where subsequent
operations assume the firmware is idle before it has actually completed
its suspend sequence.
Philipp Stanner [Fri, 7 Nov 2025 13:57:01 +0000 (14:57 +0100)]
drm/todo: Add entry for unlocked drm/sched rq readers
Runqueues are currently almost everywhere being read unlocked in
drm/sched. At XDC 2025, the assembled developers were unsure whether
that's legal and whether it can be fixed. Someone should find out.
Add a todo entry for the unlocked runqueue reader problem.
Remove the debug_enter/debug_leave helpers, as there are no DRM
drivers supporting debugging with kgdb. Remove code to keep track
of existing fbdev-emulation state. None of this required any longer.
Also remove mode_set_base_atomic from struct drm_crtc_helper_funcs,
which has no callers or implementations.
drm/radeon: Do not implement mode_set_base_atomic callback
Remove the implementation of the CRTC helper mode_set_base_atomic
from radeon. It pretends to provide mode setting for kdb debugging,
but has been broken for some time.
Kdb output has been supported only for non-atomic mode setting since
commit 9c79e0b1d096 ("drm/fb-helper: Give up on kgdb for atomic drivers")
from 2017.
While radeon provides non-atomic mode setting, kdb assumes that the GEM
buffer object is at a fixed location in video memory. This assumption
currently blocks radeon from converting to generic fbdev emulation.
Fbdev-ttm helpers use a shadow buffer with a movable GEM buffer object.
Triggering kdb does therefore not update the display.
Another problem is that the current implementation does not handle
USB keyboard input. Therefore a serial terminal is required. Then when
continuing from the debugger, radeon fails with an error:
Support for kdb feels pretty much broken. Hence remove the whole kdb
support from radeon.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Simona Vetter <simona.vetter@ffwll.ch> Acked-by: Daniel Thompson (RISCstar) <danielt@kernel.org> Link: https://patch.msgid.link/20251125130634.1080966-4-tzimmermann@suse.de
drm/nouveau: Do not implement mode_set_base_atomic callback
Remove the implementation of the CRTC helper mode_set_base_atomic
from nouveau. It pretends to provide mode setting for kdb debugging,
but has been broken for some time.
Kdb output has been supported only for non-atomic mode setting since
commit 9c79e0b1d096 ("drm/fb-helper: Give up on kgdb for atomic drivers")
from 2017.
While nouveau provides non-atomic mode setting for some devices, kdb
assumes that the GEM buffer object is at a fixed location in video
memory. This has not been the case since
commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
from 2022. Fbdev-ttm helpers use a shadow buffer with a movable GEM
buffer object. Triggering kdb does therefore not update the display.
Hence remove the whole kdb support from nouveau.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Simona Vetter <simona.vetter@ffwll.ch> Acked-by: Daniel Thompson (RISCstar) <danielt@kernel.org> Link: https://patch.msgid.link/20251125130634.1080966-3-tzimmermann@suse.de
drm/amdgpu: Do not implement mode_set_base_atomic callback
Remove all implementations of the CRTC helper mode_set_base_atomic
from amdgpu. It pretends to provide mode setting for kdb debugging,
but has been broken for some time.
Kdb output has been supported only for non-atomic mode setting since
commit 9c79e0b1d096 ("drm/fb-helper: Give up on kgdb for atomic drivers")
from 2017.
While amdgpu provides non-atomic mode setting for some devices, kdb
assumes that the GEM buffer object is at a fixed location in video
memory. This has not been the case since commit 087451f372bf ("drm/amdgpu:
use generic fb helpers instead of setting up AMD own's.") from 2021.
Fbdev-ttm helpers use a shadow buffer with a movable GEM buffer object.
Triggering kdb does not update the display.
Hence remove the whole kdb support from amdgpu.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Simona Vetter <simona.vetter@ffwll.ch> Acked-by: Daniel Thompson (RISCstar) <danielt@kernel.org> Link: https://patch.msgid.link/20251125130634.1080966-2-tzimmermann@suse.de
drm/ast: Wrap cursor framebuffer access in drm_gem_fb_begin/end_cpu_access()
Call drm_gem_fb_begin_cpu_access() and drm_gem_fb_end_cpu_access()
around cursor image updates. Imported buffers might have to be
synchronized for CPU access before they can be used.
Ignore errors from drm_gem_fb_begin_cpu_access(). These errors can
often be transitory. The cursor image will be updated on the next
frame. Meanwhile display a white square where the cursor would be.
drm/ast: Support cursor buffers objects in I/O memory
Copy the ARGB4444 cursor buffer to system memory if it is located in
I/O memory. While this cannot happen with ast's native GEM objects, an
imported buffer object might be on the external device's I/O memory.
If the cursor buffer is located in system memory continue to use it
directly.
drm/ast: Move cursor format conversion into helper function
Move the format conversion of the cursor framebuffer into the new
helper ast_cursor_plane_get_argb4444(). It returns a buffer in system
memory, which the atomic_update handler copies to video memory.
The returned buffer is either the GEM buffer itself, or a temporary
copy within the plane in ARGB4444 format.
As a small change, list supported formats explicitly in the switch
statement. Do not assume ARGB8888 input by default. The cursor
framebuffer knows its format, so should we.
Tvrtko Ursulin [Thu, 27 Nov 2025 09:03:49 +0000 (09:03 +0000)]
drm/panic: Report invalid or unsupported panic modes
Currently the user can write anything into the drm.panic_screen modparam,
either at runtime via sysfs, or as a kernel boot time argument. Invalid
strings will be silently accepted and ignored at use time by defaulting to
the 'user' panic mode.
Let instead add some validation in order to have immediate feedback when
something has been mistyped, or not compiled in.
For example during kernel boot:
Booting kernel: `bsod' invalid for parameter `drm.panic_screen'
Change of behavior is that when invalid mode is attempted to be
configured, currently the code will default to the 'user' mode, while with
this change the code will ignore it, and default to the mode set at kernel
build time via CONFIG_DRM_PANIC_SCREEN.
While at it lets also fix the module parameter description to include all
compiled in modes.
Boris Brezillon [Fri, 28 Nov 2025 09:48:38 +0000 (10:48 +0100)]
drm/panthor: Make sure we resume the tick when new jobs are submitted
If the group is already assigned a slot but was idle before this job
submission, we need to make sure the priority rotation happens in the
future. Extract the existing logic living in group_schedule_locked()
and call this new sched_resume_tick() helper from the "group is
assigned a slot" path.
v2:
- Add R-b
v3:
- Re-use queue_mask to clear the bit
- Collect R-b
Boris Brezillon [Fri, 28 Nov 2025 09:48:37 +0000 (10:48 +0100)]
drm/panthor: Fix the logic that decides when to stop ticking
When we have multiple active groups with the same priority, we need to
keep ticking for the priority rotation to take place. If we don't do
that, we might starve slots with lower priorities.
It's annoying to deal with that in tick_ctx_update_resched_target(),
so let's add a ::stop_tick field to the tick context which is
initialized to true, and downgraded to false as soon as we detect
something that requires to tick to happen. This way we can complement
the current logic with extra conditions if needed.
v2:
- Add R-b
v3:
- Drop panthor_sched_tick_ctx::min_priority (no longer relevant)
- Collect R-b
Boris Brezillon [Fri, 28 Nov 2025 09:48:36 +0000 (10:48 +0100)]
drm/panthor: Fix immediate ticking on a disabled tick
We have a few paths where we schedule the tick work immediately without
changing the resched_target. If the tick was stopped, this would lead
to a remaining_jiffies that's always > 0, and it wouldn't force a full
tick in that case. Add extra checks to cover that case properly.
v2:
- Fix typo
- Simplify the code as suggested by Steve
Boris Brezillon [Fri, 28 Nov 2025 09:48:35 +0000 (10:48 +0100)]
drm/panthor: Fix the group priority rotation logic
When rotating group priorities, we want the group with the
highest priority to go back to the end of the queue, and all
other active groups to get their priority bumped, otherwise
some groups will never get a chance to run with the highest
priority. This implies moving the rotation itself to
tick_work(), and only dealing with old group ordering in
tick_ctx_insert_old_group().
v2:
- Add R-b
- Fix the commit message
v3:
- Drop the full_tick argument in tick_ctx_init()
- Collect R-b
Boris Brezillon [Fri, 28 Nov 2025 09:48:34 +0000 (10:48 +0100)]
drm/panthor: Fix the full_tick check
We have a full tick when the remaining time to the next tick is zero,
not the other way around. Declare a full_tick variable so we don't get
that test wrong in other places.
Boris Brezillon [Fri, 28 Nov 2025 09:48:33 +0000 (10:48 +0100)]
drm/panthor: Don't try to enable extract events
Not only this only works once, because of how extract events work
(event is enabled if the req and ack bit differ, and it's signalled
by the FW by setting identical req and ack, to re-enable the event,
we need to toggle the bit, which we never do). But more importantly,
we never do anything with this event, so we're better off dropping it
when programming the CS slot.
Boris Brezillon [Fri, 28 Nov 2025 09:48:32 +0000 (10:48 +0100)]
drm/panthor: Simplify group idleness tracking
csg_slot_sync_queues_state_locked() queries the queues state which can
then be used to determine if a group is idle or not. Let's base our
idleness detection logic solely on the {idle,blocked}_queues masks to
avoid inconsistencies between the group state and the state of its
subqueues.
Boris Brezillon [Fri, 28 Nov 2025 08:48:40 +0000 (09:48 +0100)]
drm/panthor: Relax a check in panthor_sched_pre_reset()
Groups are only moved out of the runnable lists when
panthor_group_stop() is called or when they run out of jobs.
What should not happen though is having one group added to one of
the runnable list after reset.in_progress has been set to true, but
that's not something we can easily check, so let's just drop the
WARN_ON() in panthor_sched_pre_reset().
Boris Brezillon [Fri, 28 Nov 2025 08:48:39 +0000 (09:48 +0100)]
drm/panthor: Make panthor_vm_[un]map_pages() more robust
There's no reason for panthor_vm_[un]map_pages() to fail unless the
drm_gpuvm state and the page table are out of sync, so let's reflect that
by making panthor_vm_unmap_pages() a void function and adding
WARN_ON()s in various places. We also try to recover from those
unexpected mismatch by checking for already unmapped ranges and skipping
them. But there's only so much we can do to try and cope with such
SW bugs, so when we see a mismatch, we flag the VM unusable and disable
the AS to avoid further GPU accesses to the memory.
It could be that the as_disable() call fails because the MMU unit is
stuck, in which case the whole GPU is frozen, and only a GPU reset can
unblock things. Ater the reset, the VM will be seen as unusable and
any attempt to re-use it will fail, so we should be covered for any
use-after-unmap issues.
Boris Brezillon [Fri, 28 Nov 2025 08:48:38 +0000 (09:48 +0100)]
drm/panthor: Add support for atomic page table updates
Move the lock/flush_mem operations around the gpuvm_sm_[un]map() calls
so we can implement true atomic page updates, where any access in the
locked range done by the GPU has to wait for the page table updates
to land before proceeding.
This is needed for vkQueueBindSparse(), so we can replace the dummy
page mapped over the entire object by actual BO backed pages in an atomic
way. But it's also useful to avoid "AS_ACTIVE bit stuck" failures in
the sm_[un]map() path, leading to gpuvm state inconsistencies.
v2:
- Adjust to match the two new preliminary patches
Boris Brezillon [Fri, 28 Nov 2025 08:48:37 +0000 (09:48 +0100)]
drm/panthor: Recover from panthor_gpu_flush_caches() failures
We have seen a few cases where the whole memory subsystem is blocked
and flush operations never complete. When that happens, we want to:
- schedule a reset, so we can recover from this situation
- in the reset path, we need to reset the pending_reqs so we can send
new commands after the reset
- if more panthor_gpu_flush_caches() operations are queued after
the timeout, we skip them and return -EIO directly to avoid needless
waits (the memory block won't miraculously work again)
Note that we drop the WARN_ON()s because these hangs can be triggered
with buggy GPU jobs created by the UMD, and there's no way we can
prevent it. We do keep the error messages though.
v2:
- New patch
v3:
- Collect R-b
- Explicitly mention the fact we dropped the WARN_ON()s in the commit
message
Boris Brezillon [Fri, 28 Nov 2025 08:48:36 +0000 (09:48 +0100)]
drm/panthor: Kill lock_region()
The meat in lock_region() is about packing a region range into a
single u64. The rest is just a regular reg write plus a
as_send_cmd_and_wait() call that can easily be inlined in
mmu_hw_do_operation_locked().
Boris Brezillon [Fri, 28 Nov 2025 08:48:35 +0000 (09:48 +0100)]
drm/panthor: Always wait after sending a command to an AS
There's currently no situation where we want to issue a command to an
AS and not wait for this command to complete. The wait is either
explicitly done (LOCK, UNLOCK) or it's missing (UPDATE). So let's
turn write_cmd() into as_send_cmd_and_wait() that has the wait after
a command is sent.
Suraj Kandpal [Wed, 19 Nov 2025 09:46:50 +0000 (15:16 +0530)]
drm/display/dp_mst: Add protection against 0 vcpi
When releasing a timeslot there is a slight chance we may end up
with the wrong payload mask due to overflow if the delayed_destroy_work
ends up coming into play after a DP 2.1 monitor gets disconnected
which causes vcpi to become 0 then we try to make the payload =
~BIT(vcpi - 1) which is a negative shift. VCPI id should never
really be 0 hence skip changing the payload mask if VCPI is 0.
Harry Wentland [Sat, 15 Nov 2025 00:02:12 +0000 (17:02 -0700)]
drm/amd/display: Add AMD color pipeline doc
Add kernel doc for AMD color pipeline.
Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-48-alex.hung@amd.com
Alex Hung [Sat, 15 Nov 2025 00:02:11 +0000 (17:02 -0700)]
drm/amd/display: add 3D LUT colorop
This adds support for a 3D LUT.
The color pipeline now consists of the following colorops:
1. 1D curve colorop
2. Multiplier
3. 3x4 CTM
4. 1D curve colorop
5. 1D LUT
6. 3D LUT
7. 1D curve colorop
8. 1D LUT
Alex Hung [Sat, 15 Nov 2025 00:02:10 +0000 (17:02 -0700)]
drm/colorop: Add 3D LUT support to color pipeline
It is to be used to enable HDR by allowing userpace to create and pass
3D LUTs to kernel and hardware.
new drm_colorop_type: DRM_COLOROP_3D_LUT.
Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-46-alex.hung@amd.com
Harry Wentland [Sat, 15 Nov 2025 00:02:09 +0000 (17:02 -0700)]
drm/colorop: allow non-bypass colorops
Not all HW will be able to do bypass on all color
operations. Introduce an 32 bits 'flags' for all colorop
init functions and DRM_COLOROP_FLAG_ALLOW_BYPASS for creating
the BYPASS property when it's true.
Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Simon Ser <contact@emersion.fr> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-45-alex.hung@amd.com
Harry Wentland [Sat, 15 Nov 2025 00:02:08 +0000 (17:02 -0700)]
drm/colorop: Define LUT_1D interpolation
We want to make sure userspace is aware of the 1D LUT
interpolation. While linear interpolation is common it
might not be supported on all HW. Give driver implementers
a way to specify their interpolation.
Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-44-alex.hung@amd.com
Alex Hung [Sat, 15 Nov 2025 00:02:05 +0000 (17:02 -0700)]
drm/colorop: Add multiplier type
This introduces a new drm_colorop_type: DRM_COLOROP_MULTIPLIER.
It's a simple multiplier to all pixel values. The value is
specified via a S31.32 fixed point provided via the
"MULTIPLIER" property.
Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-41-alex.hung@amd.com
Alex Hung [Sat, 15 Nov 2025 00:02:04 +0000 (17:02 -0700)]
drm/amd/display: add 3x4 matrix colorop
This adds support for a 3x4 color transformation matrix.
With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-ctm_3x4_50_desat
kms_colorop --run plane-XR30-XR30-ctm_3x4_overdrive
kms_colorop --run plane-XR30-XR30-ctm_3x4_oversaturate
kms_colorop --run plane-XR30-XR30-ctm_3x4_bt709_enc
kms_colorop --run plane-XR30-XR30-ctm_3x4_bt709_dec
The color pipeline now consists of the following colorops:
1. 1D curve colorop
2. 3x4 CTM
3. 1D curve colorop
4. 1D LUT
5. 1D curve colorop
6. 1D LUT
Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-40-alex.hung@amd.com
projects / thirdparty / kernel / linux.git / log
