drm/tilcdc: Add support for DRM bus flags and simplify panel config
Migrate CRTC mode configuration to use standard DRM bus flags in
preparation for removing the tilcdc_panel driver and its custom
tilcdc_panel_info structure.
Add support for DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE and
DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE flags to control pixel clock and sync
signal edge polarity, while maintaining backward compatibility with the
existing tilcdc panel info structure.
Simplify several hardware parameters by setting them to fixed defaults
based on common usage across existing device trees:
- DMA burst size: 16 (previously configurable via switch statement)
- AC bias frequency: 255 (previously panel-specific)
- FIFO DMA request delay: 128 (previously panel-specific)
These parameters show no variation in real-world usage, so hardcoding
them simplifies the driver without losing functionality.
Preserve FIFO threshold configurability by detecting the SoC type, as
this parameter varies between AM33xx (8) and DA850 (16) platforms.
The tilcdc hardware does not generate VESA-compliant sync signals. It
aligns the vertical sync (VS) on the second edge of the horizontal sync
(HS) instead of the first edge. To compensate for this hardware
behavior, the driver applies a timing adjustment in mode_fixup().
Previously, this adjustment was conditional based on the simulate_vesa_sync
flag, which was only set when using external encoders. This appears
problematic because:
1. The timing adjustment seems needed for the hardware behavior regardless
of whether an external encoder is used
2. The external encoder infrastructure is driver-specific and being
removed due to design issues
3. Boards using tilcdc without bridges (e.g., am335x-evm, am335x-evmsk)
may not be getting the necessary timing adjustments
Remove the simulate_vesa_sync flag and apply the VESA sync timing
adjustment unconditionally, ensuring consistent behavior across all
configurations. While it's unclear if the previous conditional behavior
was causing actual issues, the unconditional adjustment better reflects
the hardware's characteristics.
dt-bindings: display: tilcdc: Mark panel binding as deprecated
Mark the ti,tilcdc,panel binding as deprecated in the documentation.
This legacy binding should no longer be used for new designs. Users
should migrate to the standard DRM panel bindings instead.
Chintan Patel [Tue, 3 Feb 2026 04:46:04 +0000 (20:46 -0800)]
drm/panel: jdi-lt070me05000: Use MIPI DSI multi functions
Convert to the non-deprecated mipi_dsi_*_multi() helpers per the TODO
list. This reduces boilerplate error checking while providing proper
error accumulation.
Use mipi_dsi_msleep() and mipi_dsi_usleep_range() macros for delays.
Replace mdelay(10) and mdelay(20) with mipi_dsi_usleep_range() calls
using tighter slop (10-11ms and 20-21ms respectively) since these
functions aren't run often and don't need large timing windows.
In jdi_panel_off(), reset the error context between display_off and
enter_sleep_mode to preserve the original behavior of continuing power-down
even if display_off fails. This ensures enter_sleep_mode executes before
GPIO/regulator control, which is critical for proper power sequencing.
Matt Coster [Fri, 6 Feb 2026 16:02:12 +0000 (16:02 +0000)]
drm/imagination: Improve handling of unknown FWCCB commands
A couple small changes:
- Validate the magic value at the head of FWCCB commands, and
- Mask off the magic value before logging unknown command types to make
them easier to interpret on sight.
Maxime Ripard [Wed, 28 Jan 2026 12:43:58 +0000 (13:43 +0100)]
drm/vc4: Switch private_obj initialization to atomic_create_state
The vc4 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 [Wed, 28 Jan 2026 12:43:55 +0000 (13:43 +0100)]
drm/msm: dpu1: Switch private_obj initialization to atomic_create_state
The MSM dpu1 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 [Wed, 28 Jan 2026 12:43:54 +0000 (13:43 +0100)]
drm/msm: mdp5: Switch private_obj initialization to atomic_create_state
The MSM mdp5 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 [Wed, 28 Jan 2026 12:43:53 +0000 (13:43 +0100)]
drm/ingenic: Switch private_obj initialization to atomic_create_state
The ingenic driver relies on two drm_private_objs, that are 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 [Wed, 28 Jan 2026 12:43:52 +0000 (13:43 +0100)]
drm/arm: komeda: Switch private_obj initialization to atomic_create_state
The ARM komeda driver relies on a number of drm_private_objs, that are
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 [Wed, 28 Jan 2026 12:43:50 +0000 (13:43 +0100)]
drm/dp_tunnel: Switch private_obj initialization to atomic_create_state
The DP tunnel implementation 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 [Wed, 28 Jan 2026 12:43:49 +0000 (13:43 +0100)]
drm/dp_mst: Switch private_obj initialization to atomic_create_state
The DP MST implementation 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 [Wed, 28 Jan 2026 12:43:48 +0000 (13:43 +0100)]
drm/bridge: Switch private_obj initialization to atomic_create_state
The bridge implementation 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.
Now that we have an atomic_create_state callback for drm_private_objs,
we can provide a helper for it.
It's somewhat different from the other similar helpers though, because
we definitely expect drm_private_obj to be subclassed. It wouldn't make
sense for a driver to use it as-is.
So we can't provide a straight implementation of the atomic_create_state
callback, but rather we provide the parts that will deal with the
drm_private_obj initialization, and we will leave the allocation and
initialization of the subclass to drivers.
Maxime Ripard [Wed, 28 Jan 2026 12:43:46 +0000 (13:43 +0100)]
drm/atomic: Add new atomic_create_state callback to drm_private_obj
The drm_private_obj initialization was inconsistent with the rest of the
KMS objects. Indeed, it required to pass a preallocated state in
drm_private_obj_init(), while all the others objects would have a reset
callback that would be called later on to create the state.
However, reset really is meant to reset the hardware and software state.
That it creates an initial state is a side-effect that has been used in
all objects but drm_private_obj. This is made more complex since some
drm_private_obj, the DisplayPort ones in particular, need to be
persistent across and suspend/resume cycle, and such a cycle would call
drm_mode_config_reset().
Thus, we need to add a new callback to allocate a pristine state for a
given private object.
This discussion has also came up during the atomic state readout
discussion, so it might be introduced into the other objects later on.
Until all drivers are converted to that new allocation pattern, we will
only call it if the passed state is NULL. This will be removed
eventually.
drm/i915/color: Add failure handling in plane color pipeline init
The plane color pipeline initialization built up multiple colorop blocks
inline, but did not reliably clean up partially constructed pipelines
when an intermediate step failed. This could lead to leaked colorop
objects and fragile error handling as the pipeline grows.
Refactor the pipeline construction to use a common helper for adding
colorop blocks. This centralizes allocation, initialization, and
teardown logic, allowing the caller to reliably unwind all previously
created colorops on failure.
drm/colorop: Use destroy callback for color pipeline teardown
Switch drm_colorop_pipeline_destroy() to use the driver-provided
destroy callback instead of directly calling drm_colorop_cleanup()
and freeing the object.
This allows drivers that embed struct drm_colorop in driver-specific
objects to perform correct teardown.
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260202094202.2871478-9-chaitanya.kumar.borah@intel.com
i915 embeds struct drm_colorop inside struct intel_colorop, so the
default drm_colorop_destroy() helper cannot be used. Add an
intel_colorop_destroy() helper that performs common DRM cleanup and
frees intel_colorop object.
This ensures correct teardown of plane color pipeline objects.
drm: Allow driver-managed destruction of colorop objects
Some drivers might want to embed struct drm_colorop inside
driver-specific objects, similar to planes or CRTCs. In such
cases, freeing only the drm_colorop is incorrect.
Add a drm_colorop_funcs callback to allow drivers to provide a destroy
hook that cleans up the full enclosing object. Make changes in helper
functions to accept helper functions as argument. Pass NULL for now
to retain current behavior.
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260202094202.2871478-3-chaitanya.kumar.borah@intel.com
drm/colorop: Add destroy helper for colorop objects
Add a helper that performs common cleanup and frees the
associated object. This can be used by drivers if they do not
require any driver-specific teardown.
v2:
- Add function documentation only before definition (Jani)
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260202094202.2871478-2-chaitanya.kumar.borah@intel.com
Li Chen [Wed, 21 Jan 2026 11:36:44 +0000 (19:36 +0800)]
nouveau: pci: quiesce GPU on shutdown
Kexec reboot does not reset PCI devices.
Invoking the full DRM/TTM teardown from ->shutdown can trigger WARNs when
userspace still holds DRM file descriptors.
Quiesce the GPU through the suspend path and then power down the PCI
function so the next kernel can re-initialize the device from a consistent
state.
Tvrtko Ursulin [Mon, 16 Jun 2025 15:59:52 +0000 (16:59 +0100)]
dma-fence: Fix sparse warnings due __rcu annotations
__rcu annotations on the return types from dma_fence_driver_name() and
dma_fence_timeline_name() cause sparse to complain because both the
constant signaled strings, and the strings return by the dma_fence_ops are
not __rcu annotated.
For a simple fix it is easiest to cast them with __rcu added and undo the
smarts from the tracpoints side of things. There is no functional change
since the rest is left in place. Later we can consider changing the
dma_fence_ops return types too, and handle all the individual drivers
which define them.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: 506aa8b02a8d ("dma-fence: Add safe access helpers and document the rules") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506162214.1eA69hLe-lkp@intel.com/ Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250616155952.24259-1-tvrtko.ursulin@igalia.com Signed-off-by: Christian König <christian.koenig@amd.com>
Icenowy Zheng [Sat, 7 Feb 2026 01:32:55 +0000 (09:32 +0800)]
drm: verisilicon: suppress snprintf warning for pixel clock name
Although it's generally expected that the pixel clock ID will only have
one decimal digit, this isn't enforced in vs_dc.c source code, and the
compiler will argue about the buffer being not long enough.
Enlarge the snprintf() buffer for generating pixel clock name to be
enough for a UINT_MAX pixel clock ID in order to suppress the compiler
warning.
Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202602060154.ONBYvM9m-lkp@intel.com/ Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260207013255.2075294-1-zhengxingda@iscas.ac.cn
Marco Crivellari [Thu, 30 Oct 2025 16:20:43 +0000 (17:20 +0100)]
drm/self_refresh: replace use of system_wq with system_percpu_wq
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
system_wq should be the per-cpu workqueue, yet in this name nothing makes
that clear, so replace system_wq with system_percpu_wq.
The old wq (system_wq) will be kept for a few release cycles.
Marco Crivellari [Thu, 30 Oct 2025 16:20:42 +0000 (17:20 +0100)]
drm/probe-helper: replace use of system_wq with system_percpu_wq
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
system_wq should be the per-cpu workqueue, yet in this name nothing makes
that clear, so replace system_wq with system_percpu_wq.
The old wq (system_wq) will be kept for a few release cycles.
Marco Crivellari [Thu, 30 Oct 2025 16:20:41 +0000 (17:20 +0100)]
drm/atomic-helper: replace use of system_unbound_wq with system_dfl_wq
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
system_unbound_wq should be the default workqueue so as not to enforce
locality constraints for random work whenever it's not required.
Adding system_dfl_wq to encourage its use when unbound work should be used.
The old system_unbound_wq will be kept for a few release cycles.
drm/gem: Make drm_gem_objects_lookup() self-cleaning on failure v6
drm_gem_objects_lookup() can allocate the output array and take
references on GEM objects before it fails.
If an error happens part-way through, callers previously had to clean up
partially created results themselves. This relied on subtle and
undocumented behavior and was easy to get wrong.
Make drm_gem_objects_lookup() clean up on failure. The function now
drops any references it already took, frees the array, and sets
*objs_out to NULL before returning an error.
On success, behavior is unchanged. Existing callers remain correct and
their error cleanup paths simply do nothing when *objs_out is NULL.
v2/v3: Move partial-lookup cleanup into objects_lookup(), perform
reference dropping outside the lock, and remove reliance on __GFP_ZERO
or implicit NULL handling. (Christian)
v4: Use goto-style error handling in objects_lookup(), drop partial
references outside the lock, and simplify drm_gem_objects_lookup()
cleanup by routing failures through err_free_handles as suggested.
(Christian)
v5: Rebase on drm-misc-next, drop the ret local variable. (Christian)
v6: Drop superfluous initialization of handles. (Christian/Tvrtko)
Cc: Alex Deucher <alexander.deucher@amd.com> Suggested-by: Christian König <christian.koenig@amd.com> Suggested-by: Tvrtko Ursulin <tursulin@ursulin.net> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patch.msgid.link/20260206132141.1474191-1-srinivasan.shanmugam@amd.com
Dmitry Baryshkov [Wed, 21 Jan 2026 10:15:47 +0000 (12:15 +0200)]
drm: bridge: anx7625: implement message sending
Swapping the data role requires sending the message to the other USB-C
side. Implement sending these messages through the OCM. The code is
largely based on the anx7411.c USB-C driver.
Dmitry Baryshkov [Wed, 21 Jan 2026 10:15:46 +0000 (12:15 +0200)]
drm: bridge: anx7625: implement minimal Type-C support
ANX7625 can be used as a USB-C controller, handling USB and DP data
streams. Provide minimal Type-C support necessary for ANX7625 to
register the Type-C port device and properly respond to data / power
role events from the Type-C partner.
While ANX7625 provides TCPCI interface, using it would circumvent the
on-chip running firmware. Analogix recommended using the higher-level
interface instead of TCPCI.
ANX7625 can be used to mux converted video stream with the USB signals
on a Type-C connector. Describe the optional connector subnode, make it
exclusive with the AUX bus and port@1 as it is impossible to have both
eDP panel and USB-C connector.
Matt Coster [Fri, 23 Jan 2026 14:44:50 +0000 (14:44 +0000)]
drm/imagination: Use dev_pm_domain_attach_list()
This helper handles the attaching and linking of the entire list of power
domains. Besides making pvr_power_domains_init() simpler, this also lays
the groundwork to simplify supporting the varied power domain names used in
Volcanic GPU cores.
Note that we still need to create the links between power domains to ensure
they're brought up in a valid sequence.
drm/fbdev-emulation: Remove support for legacy emulation
Remove the internal DRM client from fbdev emulation. This has been
required when some DRM drivers provided their own fbdev emulation.
This is no longer the case with commit b55f3bbab891 ("drm/{i915, xe}:
Implement fbdev emulation as in-kernel client") from 2024. Now there's
only a single DRM client for fbdev-emulation that fills out the client
callback functions as required.
Joel Fernandes [Thu, 5 Feb 2026 22:52:38 +0000 (08:52 +1000)]
gpu: Move DRM buddy allocator one level up (part two)
Move the DRM buddy allocator one level up so that it can be used by GPU
drivers (example, nova-core) that have usecases other than DRM (such as
VFIO vGPU support). Modify the API, structures and Kconfigs to use
"gpu_buddy" terminology. Adapt the drivers and tests to use the new API.
The commit cannot be split due to bisectability, however no functional
change is intended. Verified by running K-UNIT tests and build tested
various configurations.
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com>
[airlied: I've split this into two so git can find copies easier.
I've also just nuked drm_random library, that stuff needs to be done
elsewhere and only the buddy tests seem to be using it]. Signed-off-by: Dave Airlie <airlied@redhat.com>
Joel Fernandes [Thu, 5 Feb 2026 22:52:38 +0000 (08:52 +1000)]
gpu: Move DRM buddy allocator one level up (part one)
Move the DRM buddy allocator one level up so that it can be used by GPU
drivers (example, nova-core) that have usecases other than DRM (such as
VFIO vGPU support). Modify the API, structures and Kconfigs to use
"gpu_buddy" terminology. Adapt the drivers and tests to use the new API.
The commit cannot be split due to bisectability, however no functional
change is intended. Verified by running K-UNIT tests and build tested
various configurations.
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com>
[airlied: I've split this into two so git can find copies easier.
I've also just nuked drm_random library, that stuff needs to be done
elsewhere and only the buddy tests seem to be using it]. Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/komeda: fix integer overflow in AFBC framebuffer size check
The AFBC framebuffer size validation calculates the minimum required
buffer size by adding the AFBC payload size to the framebuffer offset.
This addition is performed without checking for integer overflow.
If the addition oveflows, the size check may incorrectly succed and
allow userspace to provide an undersized drm_gem_object, potentially
leading to out-of-bounds memory access.
Add usage of check_add_overflow() to safely compute the minimum
required size and reject the framebuffer if an overflow is detected.
This makes the AFBC size validation more robust against malformed.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Christian König [Fri, 19 Dec 2025 10:41:54 +0000 (11:41 +0100)]
dma-buf: add dma_fence_was_initialized function v2
Some driver use fence->ops to test if a fence was initialized or not.
The problem is that this utilizes internal behavior of the dma_fence
implementation.
So better abstract that into a function.
v2: use a flag instead of testing fence->ops, rename the function, move
to the beginning of the patch set.
Icenowy Zheng [Thu, 29 Jan 2026 02:39:19 +0000 (10:39 +0800)]
drm/bridge: add a driver for T-Head TH1520 HDMI controller
T-Head TH1520 SoC contains a Synopsys DesignWare HDMI controller (paired
with DesignWare HDMI TX PHY Gen2) that takes the "DP" output from the
display controller.
Add a driver for this controller utilizing the common DesignWare HDMI
code in the kernel.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Tested-by: Han Gao <gaohan@iscas.ac.cn> Tested-by: Michal Wilczynski <m.wilczynski@samsung.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260129023922.1527729-6-zhengxingda@iscas.ac.cn
Icenowy Zheng [Thu, 29 Jan 2026 02:39:18 +0000 (10:39 +0800)]
dt-bindings: display/bridge: add binding for TH1520 HDMI controller
T-Head TH1520 SoC contains a Synopsys DesignWare HDMI controller paired
with DesignWare HDMI PHY, with an extra clock gate for HDMI pixel clock
and two reset controls.
Add a device tree binding to it.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260129023922.1527729-5-zhengxingda@iscas.ac.cn
Icenowy Zheng [Thu, 29 Jan 2026 02:39:17 +0000 (10:39 +0800)]
drm: verisilicon: add a driver for Verisilicon display controllers
This is a from-scratch driver targeting Verisilicon DC-series display
controllers, which feature self-identification functionality like their
GC-series GPUs.
Only DC8200 is being supported now, and only the main framebuffer is set
up (as the DRM primary plane). Support for more DC models and more
features is my further targets.
As the display controller is delivered to SoC vendors as a whole part,
this driver does not use component framework and extra bridges inside a
SoC is expected to be implemented as dedicated bridges (this driver
properly supports bridge chaining).
Signed-off-by: Icenowy Zheng <uwu@icenowy.me> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Tested-by: Han Gao <gaohan@iscas.ac.cn> Tested-by: Michal Wilczynski <m.wilczynski@samsung.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260129023922.1527729-4-zhengxingda@iscas.ac.cn
Icenowy Zheng [Thu, 29 Jan 2026 02:39:16 +0000 (10:39 +0800)]
dt-bindings: display: add verisilicon,dc
Verisilicon has a series of display controllers prefixed with DC and
with self-identification facility like their GC series GPUs.
Add a device tree binding for it.
Depends on the specific DC model, it can have either one or two display
outputs, and each display output could be set to DPI signal or "DP"
signal (which seems to be some plain parallel bus to HDMI controllers).
Damon Ding [Wed, 17 Dec 2025 09:33:06 +0000 (17:33 +0800)]
drm/bridge: analogix_dp: Move &drm_bridge_funcs.mode_set to &drm_bridge_funcs.atomic_enable
According to the include/drm/drm_bridge.h, the callback
&drm_bridge_funcs.mode_set is deprecated and it should be better to
include the mode setting in the &drm_bridge_funcs.atomic_enable instead.
Damon Ding [Wed, 17 Dec 2025 09:33:04 +0000 (17:33 +0800)]
drm/display: bridge_connector: Ensure last bridge determines EDID/modes detection capabilities
When multiple bridges are present, EDID detection capability
(DRM_BRIDGE_OP_EDID) takes precedence over modes detection
(DRM_BRIDGE_OP_MODES). To ensure the above two capabilities are
determined by the last bridge in the chain, we handle three cases:
Case 1: The later bridge declares only DRM_BRIDGE_OP_MODES
- If the previous bridge declares DRM_BRIDGE_OP_EDID, set
&drm_bridge_connector.bridge_edid to NULL and set
&drm_bridge_connector.bridge_modes to the later bridge.
- Ensure modes detection capability of the later bridge will not
be ignored.
Case 2: The later bridge declares only DRM_BRIDGE_OP_EDID
- If the previous bridge declares DRM_BRIDGE_OP_MODES, set
&drm_bridge_connector.bridge_modes to NULL and set
&drm_bridge_connector.bridge_edid to the later bridge.
- Although EDID detection capability has higher priority, this
operation is for balance and makes sense.
Case 3: the later bridge declares both of them
- Assign later bridge as &drm_bridge_connector.bridge_edid and
and &drm_bridge_connector.bridge_modes to this bridge.
- Just leave transfer of these two capabilities as before.
Robin Murphy [Fri, 23 Jan 2026 19:22:21 +0000 (19:22 +0000)]
drm/panel-edp: Move FriendlyELEC HD702E
FriendlyELEC's HD702E module is an eDP panel (in as much as it's some
LVDS LCD behind a Chrontel CH7511B eDP bridge), so move its data over
to the eDP driver, also resolving the warning about the missing bpc
value in the process.
The unfortunate combination of HPD not being wired up and the RK3399 eDP
controller's behaviour seems to result in the EDID not being readable
over DP-AUX without probing the panel first, thus the hard-coded mode is
still needed to get things going.
Maíra Canal [Tue, 27 Jan 2026 11:57:00 +0000 (08:57 -0300)]
drm/vc4: Replace IDR with XArray for perfmon tracking
The IDR interface is deprecated and the XArray API is the recommended
replacement. Replace the per-file IDR used to track perfmons with an
XArray. This allows us to remove the external mutex that protects the
IDR.
While at it, introduce the vc4_perfmon_delete() helper to consolidate
the perfmon cleanup logic used by both vc4_perfmon_close_file() and
vc4_perfmon_destroy_ioctl(). Also, remove the redundant assignment of
vc4file->dev to itself in vc4_perfmon_open_file().
Maíra Canal [Tue, 27 Jan 2026 11:56:59 +0000 (08:56 -0300)]
drm/v3d: Replace IDR with XArray for perfmon tracking
The IDR interface is deprecated and the XArray API is the recommended
replacement. Replace the per-file IDR used to track perfmons with an
XArray. This allows us to remove the external mutex that protects the
IDR.
While here, introduce the v3d_perfmon_delete() helper to consolidate
the perfmon cleanup logic used by both v3d_perfmon_close_file() and
v3d_perfmon_destroy_ioctl().
Dave Airlie [Mon, 2 Feb 2026 01:17:06 +0000 (11:17 +1000)]
Merge tag 'exynos-drm-next-for-v6.20' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
Fix three regressions
. Fix a regression where vidi_connection_ioctl() used the wrong device
to look up the vidi context. It stores the vidi device in exynos_drm_private
and uses it in ioctl(), preventing invalid pointer access and related bugs.
. Fix a security regression where vidi_connection_ioctl() directly dereferenced
a user pointer for EDID data. It copies EDID from user space
with copy_from_user() into kernel memory before use, preventing arbitrary
kernel memory access.
. Fix a concurrency regression where vidi_context members related
to EDID memory were accessed without locking. It protects alloc/free and
state updates with ctx->lock, preventing race conditions and use-after-free bugs.
Jeongjun Park [Mon, 19 Jan 2026 08:25:52 +0000 (17:25 +0900)]
drm/exynos: vidi: fix to avoid directly dereferencing user pointer
In vidi_connection_ioctl(), vidi->edid(user pointer) is directly
dereferenced in the kernel.
This allows arbitrary kernel memory access from the user space, so instead
of directly accessing the user pointer in the kernel, we should modify it
to copy edid to kernel memory using copy_from_user() and use it.
Cc: <stable@vger.kernel.org> Signed-off-by: Jeongjun Park <aha310510@gmail.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
Jeongjun Park [Mon, 19 Jan 2026 08:25:51 +0000 (17:25 +0900)]
drm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl()
vidi_connection_ioctl() retrieves the driver_data from drm_dev->dev to
obtain a struct vidi_context pointer. However, drm_dev->dev is the
exynos-drm master device, and the driver_data contained therein is not
the vidi component device, but a completely different device.
This can lead to various bugs, ranging from null pointer dereferences and
garbage value accesses to, in unlucky cases, out-of-bounds errors,
use-after-free errors, and more.
To resolve this issue, we need to store/delete the vidi device pointer in
exynos_drm_private->vidi_dev during bind/unbind, and then read this
exynos_drm_private->vidi_dev within ioctl() to obtain the correct
struct vidi_context pointer.
Cc: <stable@vger.kernel.org> Signed-off-by: Jeongjun Park <aha310510@gmail.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
Make use of the recently introduced dw_hdmi_qp_write_infoframe() helper
to simplify the writing of the Audio InfoFrame packet header and body
registers.
Additionally, discard the redundant static values identifying the frame
version and length.
Moreover, since now having dedicated callbacks per InfoFrame type, move
the implementation to dw_hdmi_qp_bridge_write_audio_infoframe() and
drop dw_hdmi_qp_config_audio_infoframe().
Make use of the recently introduced dw_hdmi_qp_write_infoframe() helper
to simplify the writing of the Dynamic Range and Mastering (DRM)
InfoFrame packet header and body registers.
Moreover, since now having dedicated callbacks per InfoFrame type, move
the implementation to dw_hdmi_qp_bridge_write_hdr_drm_infoframe() and
drop dw_hdmi_qp_config_drm_infoframe().
While at it, also discard the unnecessary infoframe size verification,
as well as the redundant disabling of the packet transmission (already
done by the explicit call to the clear callback).
drm/bridge: dw-hdmi-qp: Rework AVI InfoFrame handler
Make use of the recently introduced dw_hdmi_qp_write_infoframe() helper
to simplify the writing of the Auxiliary Video InfoFrame (AVI) packet
header and body registers.
Moreover, since now having dedicated callbacks per InfoFrame type, move
the implementation to dw_hdmi_qp_bridge_write_avi_infoframe() and drop
dw_hdmi_qp_config_avi_infoframe().
While at it, also discard the superfluous infoframe size verification.
drm/bridge: dw-hdmi-qp: Provide HDMI Vendor Specific InfoFrame
Since commit b626b1a1c9cc ("drm/bridge: refactor HDMI InfoFrame
callbacks"), the following warning is generated:
[ 13.654149] rockchip-drm display-subsystem: [drm] HDMI VSI not supported
Add the missing support for sending HDMI Vendor-Specific Infoframes.
Additionally, introduce dw_hdmi_qp_write_{pkt|infoframe}() helpers, as a
prerequisite to rework all dw_hdmi_qp_bridge_write_*_infoframe()
callbacks and get rid of some boilerplate code.
Dave Airlie [Fri, 30 Jan 2026 02:54:03 +0000 (12:54 +1000)]
Merge tag 'drm-misc-next-fixes-2026-01-29' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next
Two fixes for NULL pointer dereference in imx8 following the bridge
refcounting conversions, and one for the bridge connector following the
HDMI audio reworks.
Luca Ceresoli [Wed, 7 Jan 2026 09:56:28 +0000 (10:56 +0100)]
drm/bridge: imx8qxp-pixel-link: imx8qxp_pixel_link_find_next_bridge: return int, not ERR_PTR
In preparation for using bridge->next_bridge, we need to ensure that it
will never contain anything but NULL or a valid bridge pointer. Current
code stores an ERR_PTR when imx8qxp_pixel_link_find_next_bridge() errors
out. Instead of fixing that after the facts in the caller, change the
function to internally set pl->next_bridge and just return an int error
value.
Luca Ceresoli [Wed, 7 Jan 2026 09:56:27 +0000 (10:56 +0100)]
drm/bridge: imx8qxp-pixel-link: simplify freeing of the remote device_node
The main loop in imx8qxp_pixel_link_find_next_bridge() requires calling
of_node_put() in multiple places, complicating code flow. Simplify it by
using a cleanup action and making the 'remote' variable scope local to the
loop.
Luca Ceresoli [Wed, 7 Jan 2026 09:56:26 +0000 (10:56 +0100)]
drm/bridge: imx8qxp-pixel-link: simplify logic to find next bridge
imx8qxp_pixel_link_find_next_bridge() uses a sophisticated logic to find
the preferred next bridge, using an array with two supporting index
variables. This is more sophisticated than required because we only ever
need a pointer to the "current" bridge and to the "best so far" bridge.
Additionally this logic is going to make the addition of proper refcounting
quite complex.
Rewrite the logic using two drm_bridge pointers, which is by itself
slightly simpler and is a preparation step for introducing bridge
refcounting in a later commit.
Lang Yu [Mon, 26 Jan 2026 02:08:25 +0000 (10:08 +0800)]
drm/amdgpu: Add a helper macro to align mqd size
MES FW uses address(mqd_addr + sizeof(struct mqd) + 3*sizeof(uint32_t))
as fence address and writes a 32 bit fence value to this address. Driver
needs to allocate some extra memory(at least 4 DWs) in addition to
sizeof(struct mqd) as mqd memory(limited to gfx/compute/sdma queue).
For gfx11/12, sizeof(struct mqd) < PAGE_SIZE, KGD allocates mqd memory with
PAGE_SIZE aligned works. For gfx12.1, sizeof(struct mqd) == PAGE_SIZE,
it doesn't work.
KFD mqd manager hardcodes mqd size to PAGE_SIZE/MQD_SIZE across different
IP versions to solve this issue.
To avoid hardcoding in differnet places and across different IP versions.
Let's use AMDGPU_MQD_SIZE_ALIGN instead. It is used in two places.
1. mqd memory alloction
2. mqd stride handling for multi xcc config
v2: Use AMDGPU_GPU_PAGE_ALIGN. (Mukul)
Signed-off-by: Lang Yu <lang.yu@amd.com> Reviewed-by: David Belanger <david.belanger@amd.com> (v1) Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Jesse.Zhang [Wed, 28 Jan 2026 03:35:57 +0000 (11:35 +0800)]
drm/amdgpu: validate user queue size constraints
Add validation to ensure user queue sizes meet hardware requirements:
- Size must be a power of two for efficient ring buffer wrapping
- Size must be at least AMDGPU_GPU_PAGE_SIZE to prevent undersized allocations
This prevents invalid configurations that could lead to GPU faults or
unexpected behavior.
Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Caterina Shablia [Wed, 28 Jan 2026 18:40:57 +0000 (18:40 +0000)]
drm: add ARM interleaved 64k modifier
This modifier is primarily intended to be used by panvk to implement
sparse partially-resident images with better map and unmap
performance, and no worse access performance, compared to
implementing them in terms of U-interleaved.
With this modifier, the plane is divided into 64k byte 1:1 or 2:1
-sided tiles. The 64k tiles are laid out linearly. Each 64k tile
is divided into blocks of 16x16 texel blocks each, which themselves
are laid out linearly within a 64k tile. Then within each such
16x16 block, texel blocks are laid out according to U order,
similar to 16X16_BLOCK_U_INTERLEAVED.
Unlike 16X16_BLOCK_U_INTERLEAVED, the layout does not depend on
whether a format is compressed or not.
The hardware features corresponding to this modifier are available
starting with v10 (second gen Valhall.)
The corresponding panvk MR can be found at:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38986
Alex Deucher [Tue, 27 Jan 2026 04:44:45 +0000 (23:44 -0500)]
drm/amdgpu: Fix cond_exec handling in amdgpu_ib_schedule()
The EXEC_COUNT field must be > 0. In the gfx shadow
handling we always emit a cond_exec packet after the gfx_shadow
packet, but the EXEC_COUNT never gets patched. This leads
to a hang when we try and reset queues on gfx11 APUs.
Jay Cornwall [Wed, 21 Jan 2026 21:25:09 +0000 (15:25 -0600)]
drm/amdkfd: gfx12.1 trap handler instruction fixup for VOP3PX
A trap may occur in the middle of VOP3PX instruction co-issue.
The PC would be restored incorrectly if left unmodified.
Identify this case by examining the instruction opcode and
rewind the PC 8 bytes if it occurs.
Signed-off-by: Jay Cornwall <jay.cornwall@amd.com> Reviewed-by: Lancelot Six <lancelot.six@amd.com> Reviewed-by: Vladimir Indic <vladimir.indic@amd.com> Cc: Shweta Khatri <shweta.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dave Airlie [Wed, 28 Jan 2026 03:35:17 +0000 (13:35 +1000)]
Merge tag 'drm-rust-next-2026-01-26' of https://gitlab.freedesktop.org/drm/rust/kernel into drm-next
DRM Rust changes for v7.0-rc1
DRM:
- Fix documentation for Registration constructors.
- Use pin_init::zeroed() for fops initialization.
- Annotate DRM helpers with __rust_helper.
- Improve safety documentation for gem::Object::new().
- Update AlwaysRefCounted imports.
MM:
- Prevent integer overflow in page_align().
Nova (Core):
- Prepare for Turing support. This includes parsing and handling
Turing-specific firmware headers and sections as well as a Turing
Falcon HAL implementation.
- Get rid of the Result<impl PinInit<T, E>> anti-pattern.
- Relocate initializer-specific code into the appropriate initializer.
- Use CStr::from_bytes_until_nul() to remove custom helpers.
- Improve handling of unexpected firmware values.
- Clean up redundant debug prints.
- Replace c_str!() with native Rust C-string literals.
- Update nova-core task list.
Nova (DRM):
- Align GEM object size to system page size.
Tyr:
- Use generated uAPI bindings for GpuInfo.
- Replace manual sleeps with read_poll_timeout().
- Replace c_str!() with native Rust C-string literals.
- Suppress warnings for unread fields.
- Fix incorrect register name in print statement. Signed-off-by: Dave Airlie <airlied@redhat.com>
From: "Danilo Krummrich" <dakr@kernel.org> Link: https://patch.msgid.link/DFYW1WV6DUCG.3K8V2DAVD1Q4A@kernel.org
Fabio Estevam [Tue, 20 Jan 2026 23:19:30 +0000 (20:19 -0300)]
drm/bridge: fsl-ldb: Allow the termination resistor to be enabled
The LVDS Control Register (LVDS_CTRL) register has an HS_EN bit that allows
the 100 Ohm termination resistor in the chip to be enabled.
Add support to setting the HS_EN bit when the optional property
"nxp,enable-termination-resistor" is present.
The motivation for introducing this property was a custom i.MX8MP board
that was showing visual artifacts. After enabling the 100 Ohm termination
resistor the LVDS signal quality improved causing the artifacts to
disappear.
Document the optional nxp,enable-termination-resistor property for the
i.MX LVDS display bridge.
This boolean property indicates that the built-in 100 Ohm termination
resistor on the LVDS output is enabled. It is controlled via the HS_EN
bit in the LVDS_CTRL register. Enabling the resistor can improve LVDS
signal quality and may prevent visual artifacts on some boards, but
increases the power consumption.
Dave Airlie [Wed, 28 Jan 2026 03:06:37 +0000 (13:06 +1000)]
Merge tag 'drm-msm-next-2026-01-23' of https://gitlab.freedesktop.org/drm/msm into drm-next
Changes for v6.20
GPU:
- Document a612/RGMU dt bindings
- UBWC 6.0 support (for A840 / Kaanapali)
- a225 support
- Fixes
DPU:
- Switched to use virtual planes by default
- Fixed DSI CMD panels on DPU 3.x
- Rewrote format handling to remove intermediate representation
- Fixed watchdog on DPU 8.x+
- Fixed TE / Vsync source setting on DPU 8.x+
- Added 3D_Mux on SC7280
- Kaanapali platform support
- Fixed UBWC register programming
- Made RM reserve DSPP-enabled mixers for CRTCs with LMs.
- Gamma correction support
DP:
- Enabled support for eDP 1.4+ link rate tables
- Fixed MDSS1 DP indices on SA8775P, making them to work
- Fixed msm_dp_ctrl_config_msa() to work with LLVM 20
DSI:
- Documented QCS8300 as compatible with SA8775P
- Kaanapali platform support
DSI PHY:
- switched to divider_determine_rate()
MDP5:
- Dropped support for MSM8998, SDM660 and SDM630 (switched over
to DPU)
MDSS:
- Kaanapali platform support
- Fixed UBWC register programming
projects / thirdparty / kernel / linux.git / log
