Maxime Ripard [Thu, 5 Mar 2026 09:04:56 +0000 (10:04 +0100)]
drm/amdgpu: display: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:04:55 +0000 (10:04 +0100)]
drm/display: hdmi: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:04:54 +0000 (10:04 +0100)]
drm/edid: Convert to drm_output_color_format enum
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
The EDID parsing code initially introduced the DRM_COLOR_FORMAT_*
defines to represent the sink capabilities. Since a given sink could
support multiple formats, it was first defined as a bitmask.
However, the core and drivers have since leveraged those defines to
represent both the supported formats but also the current format being
used.
Considering the latter case, the more natural, and consistent, thing to
do would be to create an enum of all the possible formats, and then list
the supported formats using a bitmask of the individual enum values.
Let's create a new enum following that pattern, drm_output_color_format,
while maintaining the DRM_COLOR_FORMAT_* compatibility to make the
transition easier.
Alexandru Dadu [Mon, 23 Mar 2026 18:31:30 +0000 (20:31 +0200)]
drm/imagination: Implement handling of context reset notification
The firmware will send the context reset notification message as
part of handling hardware recovery (HWR) events deecoding the message
and printing via drm_info(). This eliminates the "Unknown FWCCB command"
message that was previously printed.
Alexandru Dadu [Mon, 23 Mar 2026 18:31:29 +0000 (20:31 +0200)]
drm/imagination: Switch reset_reason fields from enum to u32
Update the reset_reason fwif structure fields from enum to u32 to remove
any ambiguity from the interface (enum is not a fixed size thus is unfit
for the purpose of the data type).
Raag Jadav [Thu, 5 Mar 2026 13:06:49 +0000 (18:36 +0530)]
drm/xe: Send 'none' recovery method for XE_WEDGED_MODE_UPON_ANY_HANG_NO_RESET
XE_WEDGED_MODE_UPON_ANY_HANG_NO_RESET is intended for debugging hangs,
so wedge the device with 'none' recovery method and have it available
to the user for debugging.
Raag Jadav [Thu, 5 Mar 2026 13:06:47 +0000 (18:36 +0530)]
drm/doc: Update documentation for 'none' recovery method
Expand 'none' recovery method for wedged event to include debug cases
where driver wants to hint "no recovery" without resetting the device
from driver context.
Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260305130720.3685754-2-raag.jadav@intel.com
Wendy Liang [Mon, 23 Mar 2026 17:37:19 +0000 (10:37 -0700)]
accel/amdxdna: Return ERR_PTR on dma_alloc_noncoherent failure
dma_alloc_noncoherent() returns NULL on failure, but callers of
aie2_alloc_msg_buffer() check for IS_ERR(). Return ERR_PTR(-ENOMEM)
instead of NULL to match the amdxdna_iommu_alloc() path and the
caller's error checking convention.
Fixes: ece3e8980907 ("accel/amdxdna: Allow forcing IOVA-based DMA via module parameter") Signed-off-by: Wendy Liang <wendy.liang@amd.com> Reviewed-by: Karol Wachowski <karol.wachowski@linux.intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260323173719.2311474-1-lizhi.hou@amd.com
Brajesh Gupta [Fri, 13 Mar 2026 06:38:24 +0000 (06:38 +0000)]
drm/imagination: Improve firmware power off for layout_mars config
In layout_mars HW config, Firmware MCU moved from Sidekick to new Mars
domain so Firmware takes care of powering down Sidekick/Jones and SLC.
Skip checks for those from kernel and check idle bits for Firmware MCU
and system arbiter excluding SOCIF.
Chen-Yu Tsai [Wed, 11 Mar 2026 09:49:28 +0000 (17:49 +0800)]
drm/sun4i: Use backend/mixer as dedicated DMA device
The sun4i DRM driver deals with DMA constraints in a peculiar way.
Instead of using the actual DMA device in various helpers, it justs
reconfigures the DMA constraints of the virtual display device using
the DMA device's device tree node by calling of_dma_configure().
Turns out of_dma_configure() should only be called from bus code.
Lately this also triggers a big warning through of_iommu_configure()
and ultimately __iommu_probe_device():
late IOMMU probe at driver bind, something fishy here!
Now that the GEM DMA helpers have proper support for allocating
and mapping buffers with a dedicated DMA device, switch over to
it as the proper solution.
The mixer change was tested on a Pine H64 model B. The backend change
was only compile tested. Though I don't expect any issues, help testing
on an older device would be appreciated.
Chen-Yu Tsai [Wed, 11 Mar 2026 09:49:27 +0000 (17:49 +0800)]
drm/mediatek: Set dedicated DMA device and drop custom GEM callbacks
In commit 9b54a32c7c6a ("drm/mediatek: mtk_gem: Partial refactor and
use drm_gem_dma_object") the MediaTek DRM driver was refactored to use
drm_gem_dma_object, but custom callbacks were still needed to deal with
using the first device of the pipeline as the DMA device, instead of
the MMSYS device that the DRM driver binds to.
Turns out there is already partial support for dedicated DMA devices in
the DRM subsystem for PRIME imports. The preceding patches add support
for dedicated DMA devices to the GEM DMA helpers.
This allows us to just set the dedicated DMA device for the DRM device,
and drop all the custom GEM callbacks. Also drop the .dma_dev field
from the driver private data as it is no longer needed.
There are slight differences in the mmap helper: the VM_DONTDUMP and
VM_IO flags are no longer set. Both were lifted from drm_gem_mmap_obj().
VM_IO probably doesn't make sense since the buffer is allocated using
dma_alloc_attrs().
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20260311094929.3393338-4-wenst@chromium.org Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Chen-Yu Tsai [Wed, 11 Mar 2026 09:49:26 +0000 (17:49 +0800)]
drm/gem-dma: Support dedicated DMA device for allocation and mapping
Support for a dedicated DMA device for prime imports was added in commit 143ec8d3f939 ("drm/prime: Support dedicated DMA device for dma-buf imports").
This allowed the DRM driver to provide a dedicated DMA device when its
own underlying device was not capable of DMA, for example when it is a
USB device (the original target) or a virtual device. The latter case is
common on embedded SoCs, on which the display pipeline is composed of
various fixed function blocks, and the DRM device is simply a made-up
device, an address space managing the routing between the blocks, or
whichever block the implementor thought made sense at the time. The
point is that the chosen device is often not the actual device doing
the DMA. Various drivers have used workarounds or reimplemented the
GEM DMA helpers to get the DMA addresses and IOMMUs to work correctly.
Add support for the dedicated DMA device to the GEM DMA helpers.
No existing driver currently uses the GEM DMA helpers and calls
drm_dev_set_dma_dev() to set a dedicated DMA device, so no existing
users should be affected.
Chen-Yu Tsai [Wed, 11 Mar 2026 09:49:25 +0000 (17:49 +0800)]
drm/prime: Limit scatter list size with dedicated DMA device
If a dedicated DMA device is specified for the DRM device, then the
scatter list size limit should pertain to the DMA device.
Use the dedicated DMA device, if given, to limit the scatter list size.
This only applies to drivers that have called drm_dev_set_dma_dev() and
are using drm_prime_pages_to_sg() either directly or through the SHMEM
helpers. At the time of this writing, the former case only includes the
Rockchip DRM driver, while the latter case includes the gud, udl, and
the tiny appletbdrm and gm12u320 drivers.
Max Zhen [Fri, 20 Mar 2026 21:06:14 +0000 (14:06 -0700)]
accel/amdxdna: Refactor GEM BO handling and add helper APIs for address retrieval
Refactor amdxdna GEM buffer object (BO) handling to simplify address
management and unify BO type semantics.
Introduce helper APIs to retrieve commonly used BO addresses:
- User virtual address (UVA)
- Kernel virtual address (KVA)
- Device address (IOVA/PA)
These helpers centralize address lookup logic and avoid duplicating
BO-specific handling across submission and execution paths. This also
improves readability and reduces the risk of inconsistent address
handling in future changes.
As part of the refactor:
- Rename SHMEM BO type to SHARE to better reflect its usage.
- Merge CMD BO handling into SHARE, removing special-case logic for
command buffers.
- Consolidate BO type handling paths to reduce code duplication and
simplify maintenance.
No functional change is intended. The refactor prepares the driver for
future enhancements by providing a cleaner abstraction for BO address
management.
Luca Ceresoli [Tue, 10 Mar 2026 12:13:23 +0000 (13:13 +0100)]
drm/bridge: add drm_bridge_clear_and_put()
Drivers having a struct drm_bridge pointer pointing to a bridge in many
cases hold that reference until the owning device is removed. In those
cases the reference to the bridge can be put in the .remove callback
(possibly using devm actions) or in the .destroy func (possibly with the
help of struct drm_bridge::next_bridge). At those moments the driver should
not be operating anymore and won't dereference the bridge pointer after it
is put.
However there are cases when drivers need to stop holding a reference to a
bridge even when their device is not being removed. This is the case for
bridge hot-unplug, when a bridge is removed but the previous entity (bridge
or encoder) is staying. In such case the "previous entity" needs to put it
but cannot do it via devm or .destroy, because it is not being removed.
However this is risky because there is a time window between the two lines
where the reference is put, and thus the bridge could be deallocated, but
the pointer is still assigned. If other functions of the same driver were
invoked concurrently they might dereference my_priv->some_bridge during
that window, resulting in use-after-free.
A correct solution is to clear the pointer before putting the reference,
but that needs a temporary variable:
Thomas Hellström [Tue, 17 Mar 2026 14:18:55 +0000 (15:18 +0100)]
drm/ttm: Avoid invoking the OOM killer when reading back swapped content
In situations where the system is very short on RAM, the shmem
readback from swap-space may invoke the OOM killer.
However, since this might be a recoverable situation where the caller
is indicating this by setting
struct ttm_operation_ctx::gfp_retry_mayfail to true, adjust the gfp
value used by the allocation accordingly.
Thomas Hellström [Tue, 17 Mar 2026 14:18:54 +0000 (15:18 +0100)]
drm/ttm: Don't spam the log on buffer object backing store allocation failure
If the struct ttm_operation_ctx::gfp_retry_mayfail is true,
buffer object backing store allocation failures are expected to
silently fail with an error code to the caller. But currently an
elaborate warning is printed to the system log.
Maxime Ripard [Tue, 24 Feb 2026 16:10:29 +0000 (17:10 +0100)]
drm/atomic: Remove state argument to drm_atomic_private_obj_init
Now that all drm_private_objs users have been converted to use
atomic_create_state instead of the old ad-hoc initialization, we can
remove the state parameter from drm_private_obj_init and the fallback
code.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260224-drm-private-obj-reset-v5-4-5a72f8ec9934@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
Maxime Ripard [Tue, 24 Feb 2026 16:10:28 +0000 (17:10 +0100)]
drm/tegra: Switch private_obj initialization to atomic_create_state
The tegra driver relies on a drm_private_obj, that is initialized by
allocating and initializing a state, and then passing it to
drm_private_obj_init.
Since we're gradually moving away from that pattern to the more
established one relying on a atomic_create_state implementation, let's
migrate this instance to the new pattern.
Maxime Ripard [Tue, 24 Feb 2026 16:10:27 +0000 (17:10 +0100)]
drm/omapdrm: Switch private_obj initialization to atomic_create_state
The omapdrm driver relies on a drm_private_obj, that is initialized by
allocating and initializing a state, and then passing it to
drm_private_obj_init.
Since we're gradually moving away from that pattern to the more
established one relying on a atomic_create_state implementation, let's
migrate this instance to the new pattern.
Maxime Ripard [Tue, 24 Feb 2026 16:10:26 +0000 (17:10 +0100)]
drm/amdgpu: Switch private_obj initialization to atomic_create_state
The amdgpu driver relies on a drm_private_obj, that is initialized by
allocating and initializing a state, and then passing it to
drm_private_obj_init.
Since we're gradually moving away from that pattern to the more
established one relying on a atomic_create_state implementation, let's
migrate this instance to the new pattern.
Karol Wachowski [Wed, 18 Mar 2026 09:39:27 +0000 (10:39 +0100)]
accel/ivpu: Perform engine reset instead of device recovery on TDR
Replace full device recovery on TDR timeout with per-context abort,
allowing individual context handling instead of resetting the entire
device.
Extend ivpu_jsm_reset_engine() to return the list of contexts impacted
by the engine reset and use that information to abort only the affected
contexts.
Only check for potentially faulty contexts when the engine reset was not
triggered by an MMU fault or a job completion error status. This prevents
misidentifying non-guilty contexts that happened to be running at the
time of the fault.
Trigger full device recovery if no contexts were marked by engine reset
if triggered by job completion timeout, as there is no way to identify
guilty one.
Add engine reset counter to debugfs for engine resets bookkeeping
for debugging/testing purposes.
Make use of the BACKGROUND_COLOR CRTC property when filling the
background during blending. It already defaults to solid black.
Since the internal representation of the pixel color in VKMS relies on
16 bits of precision, use the newly introduced DRM_ARGB64_GET{R|G|B}()
helpers to access the individual components of the background color
property, which is compliant with DRM_FORMAT_ARGB16161616.
It's worth noting the alpha component is ignored, hence non-opaque
background colors are not supported.
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Diederik de Haas <diederik@cknow-tech.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260303-rk3588-bgcolor-v8-3-fee377037ad1@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
Some display controllers can be hardware programmed to show non-black
colors for pixels that are either not covered by any plane or are
exposed through transparent regions of higher planes. This feature can
help reduce memory bandwidth usage, e.g. in compositors managing a UI
with a solid background color while using smaller planes to render the
remaining content.
To support this capability, introduce the BACKGROUND_COLOR standard DRM
mode property, which can be attached to a CRTC through the
drm_crtc_attach_background_color_property() helper function.
Additionally, define a 64-bit ARGB format value to be built with the
help of a couple of dedicated DRM_ARGB64_PREP*() helpers. Individual
color components can be extracted with desired precision using the
corresponding DRM_ARGB64_GET*() macros.
Co-developed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Diederik de Haas <diederik@cknow-tech.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260303-rk3588-bgcolor-v8-2-fee377037ad1@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
Currently DIV_ROUND_CLOSEST() is only available for the kernel via
include/linux/math.h.
Expose it to userland as well by adding __KERNEL_DIV_ROUND_CLOSEST() as
a common definition in uapi.
Additionally, ensure it allows building ISO C applications by switching
from the 'typeof' GNU extension to the ISO-friendly __typeof__.
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Diederik de Haas <diederik@cknow-tech.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260303-rk3588-bgcolor-v8-1-fee377037ad1@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
Lizhi Hou [Tue, 17 Mar 2026 04:49:06 +0000 (21:49 -0700)]
accel/amdxdna: Support retrieving hardware context debug information
The firmware implements the GET_APP_HEALTH command to collect debug
information for a specific hardware context.
When a command times out, the driver issues this command to collect the
relevant debug information. User space tools can also retrieve this
information through the hardware context query IOCTL.
Ethan Tidmore [Sat, 7 Mar 2026 03:32:45 +0000 (21:32 -0600)]
drm/bridge: waveshare-dsi: Fix signedness bug
The function drm_of_get_data_lanes_count_ep() returns negative error
codes and dsi->lanes is an unsigned integer, so the check (dsi->lanes <
0) is always impossible.
Make the return value of drm_of_get_data_lanes_count_ep() be assigned to
ret, check for error, and then assign dsi->lanes to ret.
Detected by Smatch:
drivers/gpu/drm/bridge/waveshare-dsi.c:70 ws_bridge_attach_dsi() warn:
unsigned 'dsi->lanes' is never less than zero.
Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202603060341.hNj0pl9L-lkp@intel.com/ Fixes: fca11428425e9 ("drm/bridge: waveshare-dsi: Add support for 1..4 DSI data lanes") Signed-off-by: Ethan Tidmore <ethantidmore06@gmail.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://patch.msgid.link/20260307033245.71666-1-ethantidmore06@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
cpu_to_be32() returns a __be32 big-endian value, but the compound literals
passed to tilcdc_panel_update_prop() were typed as u32. This causes a
sparse type mismatch warning. Fix it by using __be32 as the compound
literal type to match the return type of cpu_to_be32().
drm/tilcdc: Remove tilcdc_panel driver reintroduced by a merge
The tilcdc_panel driver was removed by commit 8f1e1ab9c794 ("drm/tilcdc:
Remove tilcdc panel driver"), but was inadvertently reintroduced by the
merge commit 8b85987d3cf5 ("Merge drm/drm-next into drm-misc-next").
The regression went unnoticed because standard git commands such as
'git show' do not expose the change. It was only spotted via
'git show --stat':
drm/atomic: Add affected colorops with affected planes
When drm_atomic_add_affected_planes() adds a plane to the atomic
state, the associated colorops are not guaranteed to be included.
This can leave colorop state out of the transaction when planes
are pulled in implicitly (eg. during modeset or internal commits).
Also add affected colorops when adding affected planes to keep
plane and color pipeline state consistent within the atomic
transaction.
v2: Add affected colorops only when a pipeline is enabled
Fixes: 2afc3184f3b3 ("drm/plane: Add COLOR PIPELINE property") Cc: <stable@vger.kernel.org> #v6.19+ Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v1 Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260310113238.3495981-3-chaitanya.kumar.borah@intel.com
drm/colorop: Preserve bypass value in duplicate_state()
__drm_atomic_helper_colorop_duplicate_state() unconditionally
sets state->bypass = true after copying the existing state.
This override causes the new atomic state to no longer reflect
the currently committed hardware state. Since the bypass property
directly controls whether the colorop is active in hardware,
resetting it to true can inadvertently disable an active colorop
during a subsequent commit, particularly for internal driver commits
where userspace does not touch the property.
Drop the unconditional assignment and preserve the duplicated
bypass value.
Chen-Yu Tsai [Mon, 9 Mar 2026 16:56:33 +0000 (00:56 +0800)]
drm/sun4i: layers: Use drm_fb_dma_get_gem_addr() to get display memory
Commit 4636ce93d5b2 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()")
adds a new helper, which covers fetching a drm_framebuffer's GEM object
and calculating the buffer address for a given plane.
This patch uses this helper to replace our own open coded version of the
same function.
Maíra Canal [Fri, 6 Mar 2026 11:30:38 +0000 (08:30 -0300)]
drm/v3d: Remove dedicated fence_lock
Commit adefb2ccea1e ("drm/v3d: create a dedicated lock for dma fence")
split `fence_lock` from `queue_lock` because v3d_job_update_stats() was
taking `queue_lock` to protect `job->file_priv` during stats collection
in the IRQ handler. Using the same lock for both DMA fence signaling and
stats protection in a IRQ context caused issues on PREEMPT_RT.
Since then, the stats infrastructure has been reworked: v3d_stats is now
refcounted and jobs hold their own references to stats objects, so
v3d_job_update_stats() no longer takes `queue_lock` at all.
With the original reason for the split gone, merge `fence_lock` back
into `queue_lock` to simplify the locking scheme.
Tvrtko Ursulin [Fri, 6 Mar 2026 11:30:37 +0000 (08:30 -0300)]
drm/v3d: Attach per-fd reset counters to v3d_stats
To remove the file_priv NULL-ing dance needed to check if the file
descriptor is open, move the per-fd reset counter into v3d_stats, which
is heap-allocated and refcounted, outliving the fd as long as jobs
reference it.
This change allows the removal of the last `queue_lock` usage to protect
`job->file_priv` and avoids possible NULL ptr dereference issues due to
lifetime mismatches.
Also, to simplify locking, replace both the global and per-fd locked
reset counters with atomics.
Tvrtko Ursulin [Fri, 6 Mar 2026 11:30:36 +0000 (08:30 -0300)]
drm/v3d: Hold v3d_stats references in each job
Have each job hold its own references to the per-fd and global stats
objects. This eliminates the need for `queue_lock` protection in the
stats update path, since the job's stats pointers are guaranteed to
remain valid for the job's entire lifetime regardless of file descriptor
closure.
Tvrtko Ursulin [Fri, 6 Mar 2026 11:30:35 +0000 (08:30 -0300)]
drm/v3d: Refcount v3d_stats
Convert `v3d_stats` from embedded structs to heap-allocated, refcounted
objects. This decouples the stats lifetime from the containing
structures (this is, `v3d_queue_state` and `v3d_file_priv`), allowing
jobs to safely hold their own references to stats objects even after the
file descriptor is closed.
Tvrtko Ursulin [Fri, 6 Mar 2026 11:30:34 +0000 (08:30 -0300)]
drm/v3d: Use raw seqcount helpers instead of fighting with lockdep
The `v3d_stats` sequence counter uses regular seqcount helpers, which
carry lockdep annotations that expect a consistent IRQ context between
all writers. However, lockdep is unable to detect that v3d's readers
are never in IRQ or softirq context, and that for CPU job queues, even
the write side never is. This led to false positive that were previously
worked around by conditionally disabling local IRQs under
IS_ENABLED(CONFIG_LOCKDEP).
Switch to the raw seqcount helpers which skip lockdep tracking entirely.
This is safe because jobs are fully serialized per queue: the next job
can only be queued after the previous one has been signaled, so there is
no scope for the start and update paths to race on the same seqcount.
Maíra Canal [Fri, 6 Mar 2026 11:30:33 +0000 (08:30 -0300)]
drm/v3d: Handle error from drm_sched_entity_init()
drm_sched_entity_init() can fail but its return value is currently being
ignored in v3d_open(). Check the return value and properly unwind
on failure by destroying any already-initialized scheduler entities.
Harry Wentland [Thu, 12 Mar 2026 20:41:45 +0000 (16:41 -0400)]
drm/colorop: Fix blob property reference tracking in state lifecycle
The colorop state blob property handling had memory leaks during state
duplication, destruction, and reset operations. The implementation
failed to follow the established pattern from drm_crtc's handling of
DEGAMMA/GAMMA blob properties.
Issues fixed:
- drm_colorop_atomic_destroy_state() was freeing state memory without
releasing the blob reference, causing a leak
- drm_colorop_reset() was directly freeing old state with kfree()
instead of properly destroying it, leaking blob references
- drm_colorop_cleanup() had duplicate blob cleanup code
Changes:
- Add __drm_atomic_helper_colorop_destroy_state() helper to properly
release blob references before freeing state memory
- Update drm_colorop_atomic_destroy_state() to call the helper
- Fix drm_colorop_reset() to use drm_colorop_atomic_destroy_state()
for proper cleanup of old state
- Simplify drm_colorop_cleanup() to use the common destruction path
This matches the well-tested pattern used by drm_crtc since 2016 and
ensures proper reference counting throughout the state lifecycle.
Co-developed by Claude Sonnet 4.5.
Fixes: cfc27680ee20 ("drm/colorop: Introduce new drm_colorop mode object") Cc: Simon Ser <contact@emersion.fr> Cc: Alex Hung <alex.hung@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Stone <daniels@collabora.com> Cc: Melissa Wen <mwen@igalia.com> Cc: Sebastian Wick <sebastian.wick@redhat.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Louis Chauvet <louis.chauvet@bootlin.com> Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: <stable@vger.kernel.org> #v6.19+ Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Link: https://patch.msgid.link/20260312204145.829714-1-harry.wentland@amd.com
Chintan Patel [Thu, 5 Mar 2026 04:49:21 +0000 (20:49 -0800)]
drm/panel: novatek-nt36672a: Convert to mipi_dsi_*_multi() helpers
Convert the driver to use the non-deprecated mipi_dsi_*_multi() helpers and
mipi_dsi_msleep().
Switch DCS command sequences to the multi context API and
accumulate errors via struct mipi_dsi_multi_context. Replace
open-coded error handling with the multi helpers and convert
nt36672a_send_cmds() and power sequencing accordingly.
This patch is intended to functionally be a no-op, though there is one
slight change. Previously a failure in regulator_bulk_disable() would
have caused nt36672a_panel_unprepare() to return an error. Now it
won't. No other errors in nt36672a_panel_unprepare() were propagated,
so this makes things consistent.
Michael Tretter [Thu, 19 Feb 2026 11:32:58 +0000 (12:32 +0100)]
drm/imx: ipuv3-plane: support underlay plane
The IPUv3 overlay plane may be placed over or under the primary plane.
Set the zpos of the primary to an immutable position of 1 to have the
possibility to place the other plane underneath it.
Set the zpos of other planes (the overlay plane) to a mutable value
between 0 (the lowest possible value of a zpos) and directly above the
primary plane with the latter being the default.
Michael Tretter [Thu, 19 Feb 2026 11:32:57 +0000 (12:32 +0100)]
drm/imx: ipuv3-plane: decouple zpos from plane type
The overlay plane may be placed over or under the primary plane. Using
zpos to determine, if the plane is the primary or overlay plane is not
valid anymore.
Use the plane type for determining the name of the plane in the error
message.
drm/imx: parallel-display: add DRM_DISPLAY_HELPER for DRM_IMX_PARALLEL_DISPLAY
When I build for an old imx53 platform I see the same as the test robot
saw before:
arm-buildroot-linux-gnueabihf-ld: drivers/gpu/drm/imx/ipuv3/parallel-display.o: in function `imx_pd_bind':
parallel-display.c:(.text+0xb8): undefined reference to `drm_bridge_connector_init'
Selecting DRM_DISPLAY_HELPER for DRM_IMX_PARALLEL_DISPLAY fixes the build.
Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512241721.jZgcwRfr-lkp@intel.com/ Signed-off-by: Martin Kepplinger-Novakovic <martin.kepplinger-novakovic@ginzinger.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://patch.msgid.link/20260121102607.4087362-1-martin.kepplinger-novakovic@ginzinger.com
Marek Vasut [Sat, 10 Jan 2026 17:14:10 +0000 (18:14 +0100)]
drm/imx: parallel-display: Prefer bus format set via legacy "interface-pix-fmt" DT property
Prefer bus format set via legacy "interface-pix-fmt" DT property
over panel bus format. This is necessary to retain support for
DTs which configure the IPUv3 parallel output as 24bit DPI, but
connect 18bit DPI panels to it with hardware swizzling.
This used to work up to Linux 6.12, but stopped working in 6.13,
reinstate the behavior to support old DTs.
Cc: stable@vger.kernel.org Fixes: 5f6e56d3319d ("drm/imx: parallel-display: switch to drm_panel_bridge") Signed-off-by: Marek Vasut <marex@nabladev.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://patch.msgid.link/20260110171510.692666-1-marex@nabladev.com
Lizhi Hou [Mon, 26 Jan 2026 19:30:01 +0000 (11:30 -0800)]
accel/amdxdna: Allow forcing IOVA-based DMA via module parameter
The amdxdna driver normally performs DMA using userspace virtual address
plus PASID. For debugging and validation purposes, add a module parameter,
force_iova, to force DMA to go through IOMMU IOVA mapping.
When force_iova=1 is set, the driver will allocate and map DMA buffers
using IOVA.
drm/ttm/tests: add a test to exercise ttm_bo_swapout
Currently, ttm_bo_swapout is not exercised by the TTM KUnit tests.
It used to be exercised until commit 76689eb52667 ("drm/ttm: remove
ttm_bo_validate_swapout test"), but that test was removed as it was
unreliable due to requiring to allocate half of the system memory.
Calling ttm_bo_swapout directly with a single allocated BO, however, does
not suffer from that problem, and was able to detect a UAF introduced by
commit c06da4b3573a ("drm/ttm: Tidy usage of local variables a little
bit"), when built with KASAN.
When applying a fix to that UAF, the test passed without any issues.
Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260309-ttm_bo_swapout_test-v2-1-219f64046cfe@igalia.com
accel/amdxdna: Support sensors for column utilization
The AMD PMF driver provides realtime column utilization (npu_busy)
metrics for the NPU. Extend the DRM_IOCTL_AMDXDNA_GET_INFO sensor
query to expose these metrics to userspace.
Add AMDXDNA_SENSOR_TYPE_COLUMN_UTILIZATION to the sensor type enum
and update aie2_get_sensors() to return both the total power and up
to 8 column utilization sensors if the user buffer permits.
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
[lizhi: support legacy tool which uses small buffer. checkpatch cleanup] Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260311171842.473453-1-lizhi.hou@amd.com
Lizhi Hou [Sat, 28 Feb 2026 06:10:57 +0000 (00:10 -0600)]
accel/amdxdna: Add IOCTL to retrieve realtime NPU power estimate
The AMD PMF driver provides an interface to obtain realtime power
estimates for the NPU. Expose this information to userspace through a
new DRM_IOCTL_AMDXDNA_GET_INFO parameter, allowing applications to query
the current NPU power level.
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
(Update comment to indicate power and utilization) Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260228061109.361239-2-superm1@kernel.org
Linus Walleij [Tue, 10 Mar 2026 08:53:12 +0000 (09:53 +0100)]
dma-buf: heaps: Clear CMA highages using helper
Currently the CMA allocator clears highmem pages using
kmap()->clear_page()->kunmap(), but there is a helper
static inline in <linux/highmem.h> that does the same for
us so use clear_highpage() instead of open coding this.
Suggested-by: T.J. Mercier <tjmercier@google.com> Reviewed-by: T.J. Mercier <tjmercier@google.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260310-cma-heap-clear-pages-v2-2-ecbbed3d7e6d@kernel.org
Linus Walleij [Tue, 10 Mar 2026 08:53:11 +0000 (09:53 +0100)]
dma-buf: heaps: Clear CMA pages with clear_pages()
As of commit 62a9f5a85b98
"mm: introduce clear_pages() and clear_user_pages()" we can
clear a range of pages with a potentially assembly-optimized
call.
Instead of using a memset, use this helper to clear the whole
range of pages from the CMA allocation.
Boris Brezillon [Mon, 9 Mar 2026 12:43:18 +0000 (13:43 +0100)]
drm/panthor: Fix the "done_fence is initialized" detection logic
After commit 541c8f2468b9 ("dma-buf: detach fence ops on signal v3"),
dma_fence::ops == NULL can't be used to check if the fence is initialized.
Use dma_fence_was_initialized() instead.
v2:
- Use dma_fence_was_initialized() instead of open-coding it
Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Philipp Stanner <phasta@kernel.org> Cc: Christian König <christian.koenig@amd.com> Reported-by: Steven Price <steven.price@arm.com> Reported-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Christian König <christian.koenig@amd.com> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20260309124318.222902-1-boris.brezillon@collabora.com
Amin GATTOUT [Sun, 8 Mar 2026 10:15:57 +0000 (11:15 +0100)]
drm/loongson: use drm_gem_ttm_dumb_map_offset()
Replace the open-coded lsdc_dumb_map_offset() with the generic
drm_gem_ttm_dumb_map_offset() helper, which is functionally identical.
This removes unnecessary boilerplate and aligns with the DRM convention
for TTM-based drivers.
drm/gem-shmem: Track folio accessed/dirty status in vmap
On successful vmap, set the page_mark_accessed_on_put and _dirty_on_put
flags in the gem-shmem object. Signals that the contained pages require
LRU and dirty tracking when they are being released back to SHMEM. Clear
these flags on put, so that the buffer remains quiet until the next call
to vmap. There's no means of handling dirty status in vmap as there's no
write-only mapping available.
Both flags, _accessed_on_put and _dirty_on_put, have always been part of
the gem-shmem object, but never used much. So most drivers did not track
the page status correctly.
Only the v3d and imagination drivers make limited use of _dirty_on_put. In
the case of imagination, move the flag setting from init to cleanup. This
ensures writeback of modified pages but does not interfere with the
internal vmap/vunmap calls. V3d already implements this behaviour.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> # gem-shmem Acked-by: Frank Binns <frank.binns@imgtec.com> # imagination Tested-by: Frank Binns <frank.binns@imgtec.com> # imagination Link: https://patch.msgid.link/20260227114509.165572-7-tzimmermann@suse.de
drm/gem-shmem: Track folio accessed/dirty status in mmap
Invoke folio_mark_accessed() in mmap page faults to add the folio to
the memory manager's LRU list. Userspace invokes mmap to get the memory
for software rendering. Compositors do the same when creating the final
on-screen image, so keeping the pages in LRU makes sense. Avoids paging
out graphics buffers when under memory pressure.
In pfn_mkwrite, further invoke the folio_mark_dirty() to add the folio
for writeback should the underlying file be paged out from system memory.
This rarely happens in practice, yet it would corrupt the buffer content.
This has little effect on a system's hardware-accelerated rendering, which
only mmaps for an initial setup of textures, meshes, shaders, etc.
v4:
- test for VM_FAULT_NOPAGE before marking folio as accessed (Boris)
- test page-array bounds in mkwrite handler (Boris)
v3:
- rewrite for VM_PFNMAP
v2:
- adapt to changes in drm_gem_shmem_try_mmap_pmd()
The current mmap page-fault handler requires some changes before it
can track folio access.
Call to folio_test_pmd_mappable() into the mmap page-fault handler
before calling drm_gem_shmem_try_map_pmd(). The folio will become
useful for tracking the access status.
Also rename drm_gem_shmem_try_map_pmd() to _try_insert_pfn_pmd()
and only pass the page fault and page-frame number. The new name and
parameters make it similar to vmf_insert_pfn_pmd().
No functional changes. If PMD mapping fails or is not supported,
insert a regular PFN as before.
drm/gem-shmem: Return vm_fault_t from drm_gem_shmem_try_map_pmd()
Return the exact VM_FAULT_ mask from drm_gem_shmem_try_map_pmd(). Gives
the caller better insight into the result. Return 0 if nothing was done.
If the caller sees VM_FAULT_NOPAGE, drm_gem_shmem_try_map_pmd() added a
PMD entry to the page table. As before, return early from the page-fault
handler in that case.
drm/gem-shmem: Test for existence of page in mmap fault handler
Not having a page pointer in the mmap fault handler is an error. Test
for this situation and return VM_FAULT_SIGBUS if so. Also replace several
lookups of the page with a local variable.
Lukas Bulwahn [Wed, 11 Mar 2026 04:33:14 +0000 (05:33 +0100)]
MAINTAINERS: adjust file entry in GPU BUDDY ALLOCATOR
The commit 4a9671a03f2b ("gpu: Move DRM buddy allocator one level up (part
one)") and commit ba110db8e1bc ("gpu: Move DRM buddy allocator one level up
(part two)") split the majority of the file drivers/gpu/drm/drm_buddy.c
into drivers/gpu/buddy.c, with some pieces remaining in the original
location drivers/gpu/drm/drm_buddy.c.
The commits also adjust the file entries in the GPU BUDDY ALLOCATOR
section, but as part of that, change the file entry to the non-existing
file drivers/gpu/drm_buddy.c instead of keeping the reference to the
existing file drivers/gpu/drm/drm_buddy.c.
Make the file entry in GPU BUDDY ALLOCATOR refer to the intended existing
file. While at it, order the file entries in this section alphabetically.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com> Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Link: https://patch.msgid.link/20260311043314.265627-1-lukas.bulwahn@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
Dmitry Baryshkov [Wed, 11 Feb 2026 09:17:27 +0000 (11:17 +0200)]
drm: bridge: anx7625: correctly detect if PD can be disabled
During initial checks the ANX7625 bridge can be powered on before
setting up the Type-C port. At this point, when
anx7625_ocm_loading_check() checks if it can disable PD or not, it will
notice that typec_port is not set and disable PD, breaking orientation
and HPD handling. Unify the check between anx7625_ocm_loading_check()
anx7625_i2c_probe() and anx7625_typec_register() and check for the
presence of the "connector" node.
Loic Poulain [Sun, 15 Feb 2026 01:30:02 +0000 (03:30 +0200)]
drm: bridge: anx7625: don't crash if Type-C port is not used
The typec_set_*() functions do not tolerate being passed the NULL
typec_port instance. However, if CONFIG_TYPEC is enabled, but anx7625
DT node doesn't have the usb-c connector fwnode, then typec_port remains
NULL, crashing the kernel. Prevent calling typec_set_foo() functions by
checking that ctx->typec_port is not NULL in anx7625_typec_set_status().
When CONFIG_TYPEC is enabled, but USB_ROLE_SWITCH=m, the anx7625 driver
fails to link as built-in:
aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/anx7625.o: in function `anx7625_i2c_remove':
anx7625.c:(.text+0x6ec): undefined reference to `usb_role_switch_put'
aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/anx7625.o: in function `anx7625_typec_set_status':
anx7625.c:(.text+0x3080): undefined reference to `usb_role_switch_set_role'
aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/anx7625.o: in function `anx7625_i2c_probe':
anx7625.c:(.text+0x5368): undefined reference to `fwnode_usb_role_switch_get'
The problem is that both dependencies are optional in the sense of allowing
the anx7625 driver to call the exported interfaces to be used from a loadable
module, but cannot work for built-in drivers. It would be possible to handle
all nine combinations of the CONFIG_TYPEC and CONFIG_USB_ROLE_SWITCH tristate
options, but that does add a lot of complexity that seems unnecessary when
in reality any user of this driver would have both enabled anyway.
Turn both dependencies into hard 'depends on' here to only allow configurations
where it's possible to actually use them, and remove the misguided IS_REACHABLE()
check that did nothing here.
dt-bindings: display: panel: Align style of additionalProperties
For code readability the bindings are expected to follow order shown in
example-schema.yaml - put the additionalProperties/unevaluatedProperties
entry at the end, after listing all required properties and possible
"allOf:if:then:" conditions. Meaning of this style is to close the
schema, after listing what it contains, with final "nothing more is
allowed".
Move the code around adjusting it to coding style. No functional
impact.
dt-bindings: display: panel: Drop redundant properties
The purpose of common schemas, like panel-common.yaml, is to list
applicable properties. It can list common ABI, e.g. "label" property,
and pure hardware related properties like power supply or GPIOs. In the
second case it means that all panels have these supplies or GPIOs.
This is the only meaning when hardware property is allowed in common
schema, because bindings are precise and we do not define common schemas
for "possible" hardware configurations.
Following this, all panel bindings which reference common schema and use
"unevaluatedProperties: false" do not need to list these common parts.
Simplify such bindings to also reduce copy-paste code and review time
for new contributions.
This MIPI-DSI LCD panel must be connected to something. According to
scarce web data it supports two channels and it is already used like
this in DTS. Reported by dtbs_check:
rockchip/rk3399-gru-scarlet-inx.dtb: panel@0 (innolux,p097pfg): 'ports' does not match any of the regexes: '^pinctrl-[0-9]+$'
Svyatoslav Ryhel [Mon, 23 Feb 2026 06:46:30 +0000 (08:46 +0200)]
gpu/drm: panel: add support for DSI panel used in Motorola Atrix 4G and Droid X2
Add support for the DSI LCD panel module found in Motorola Atrix 4G or
Droid X2 smartphones. Exact panel vendor and model are unknown hence panel
uses generic compatible based on board where it is used. The panel has a
540x960 resolution with 24 bit RGB per pixel.
Atrix 4G and Droid X2 are based on a board called by Motorola "Mot" and
use the same 540x960 DSI video mode panel. Exact panel vendor and model
are unknown hence generic compatible based on board name "Mot" is used.
The Pixel 3a XL is code-named by Google as "bonito". The
google,bonito-tianma compatible represents a variant of the Pixel 3a XL
board with a Tianma/Novatek NT37700F panel. Document the google,bonito
board compatible and the google,bonito-tianma variant in the bindings.
dt-bindings: display: panel: Document the rotation property
The Jadard jd9365da-h3 driver already allows DRM to get the panel
orientation via the device tree rotation property (described in
panel-common.yaml), but it's currently not documented.
Describe it in the driver documentation to fix a dtbs_check error in
Xiaomi Mi Smart Clock x04g, where the panel is landscape-oriented.
While the panel is described as DPI panel, it is part of a larger unit
in non-removable metal casing, so the actual internal configuration is
not known. The panel is attached to "waveshare,dsi2dpi" bridge via DT.
It is likely that internally, this panel is an LVDS panel, connected to
ICN6211 DSI-to-DPI bridge and then another unknown DPI-to-LVDS bridge.
Current device link is at https://www.waveshare.com/13.3inch-dsi-lcd.htm
John Keeping [Tue, 3 Mar 2026 15:21:24 +0000 (15:21 +0000)]
drm/panel: ilitek-ili9882t: use gpiod_set_value_cansleep()
All of these GPIO calls are in process context where they can sleep.
Use the appropriate function call to allow use of this driver with GPIO
controllers that might sleep.
Langyan Ye [Sat, 14 Feb 2026 08:54:09 +0000 (16:54 +0800)]
drm/panel: panel-jadard-jd9365da-h3: support for taiguan-xti05101-01a MIPI-DSI panel
The taiguan-xti05101-01a is a 10.1" TFT panel. The MIPI controller on this
panel is the same as the other panels here, so add this panel to this
driver.
projects / thirdparty / linux.git / log
