drm/tilcdc: Add support for DRM_BRIDGE_ATTACH_NO_CONNECTOR
Convert the driver to use the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag when
attaching bridges. This modernizes the driver by delegating connector
creation to the bridge subsystem through drm_bridge_connector_init()
instead of manually searching for connectors created by the bridge.
The custom tilcdc_encoder_find_connector() function is removed and
replaced with the standard drm_bridge_connector infrastructure, which
simplifies the code and aligns with current DRM bridge best practices.
This change is safe as there are now no in-tree devicetrees that
connect tilcdc to bridges which do not support the
DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
drm/bridge: tda998x: Add support for DRM_BRIDGE_ATTACH_NO_CONNECTOR
Add support for the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag to allow display
controller drivers to create their own connectors. This modernizes the
driver to work with the current DRM bridge framework.
The implementation includes:
- Refactoring detection and EDID reading into bridge-usable helpers
- Adding bridge operations: edid_read, detect, hpd_enable, hpd_disable
- Setting appropriate bridge ops (DRM_BRIDGE_OP_EDID, DRM_BRIDGE_OP_DETECT,
DRM_BRIDGE_OP_HPD) and connector type (HDMIA)
- Skipping connector creation when DRM_BRIDGE_ATTACH_NO_CONNECTOR is set
- Handling conditional connector cleanup in bridge_detach
The driver maintains backward compatibility by continuing to create its
own connector when the flag is not set.
drm/bridge: tda998x: Move tda998x_create/destroy into probe and remove
Now that tda998x_create and tda998x_destroy are called only in the probe
function, there is no need for separate functions.
Move the code into the tda998x_probe and tda998x_remove functions.
Rewrite the cleanup path using goto calls in probe and reorder it in the
remove function.
The tilcdc driver no longer uses the component framework to bind the
tda998x bridge driver. The component bind/unbind operations and the
encoder initialization code are now dead code and can be safely removed.
Replace drm_of_find_panel_or_bridge() with the newer
devm_drm_of_get_bridge() helper which simplifies the code by:
- Automatically handling both panel and bridge cases internally
- Managing the panel-to-bridge conversion when needed
- Using devres for resource management, eliminating manual cleanup
This removes the need for explicit panel-to-bridge conversion via
devm_drm_panel_bridge_add_typed() and the associated error handling path.
drm/tilcdc: Convert to drm_device-based logging helpers
Replace dev_* logging calls with their DRM equivalents.
This aligns with the DRM subsystem's logging infrastructure and provides
better integration with DRM debugging mechanisms. The drm_* helpers
automatically include device information and integrate with DRM's
debug category filtering.
Convert the tilcdc driver to use DRM managed resources (drmm_* APIs)
to eliminate resource lifetime issues, particularly in probe deferral
scenarios.
This conversion addresses potential use-after-free bugs by ensuring
proper cleanup ordering through the DRM managed resource framework.
The changes include:
- Replace drm_crtc_init_with_planes() with drmm_crtc_alloc_with_planes()
- Replace drm_universal_plane_init() with drmm_universal_plane_alloc()
- Replace drm_simple_encoder_init() with drmm_simple_encoder_alloc()
- Remove manual cleanup in tilcdc_crtc_destroy() and error paths
- Remove drm_encoder_cleanup() from encoder error handling paths
- Use drmm_add_action_or_reset() for remaining cleanup operations
This approach is recommended by the DRM subsystem for improved resource
lifetime management and is particularly important for drivers that may
experience probe deferral.
drm/tilcdc: Remove the use of drm_device private_data
The DRM core documentation recommends against using dev_private:
"Instead of using this pointer it is recommended that drivers use
embed the struct &drm_device in their larger per-device structure."
This patch refactors the tilcdc driver to follow this recommendation
by embedding struct drm_device within struct tilcdc_drm_private and
replacing all dev->dev_private accesses with the ddev_to_tilcdc_priv()
helper macro that uses container_of().
This change aligns the driver with modern DRM best practices.
drm/tilcdc: Modernize driver initialization and cleanup paths
Refactor the driver initialization to use modern DRM managed resource
APIs, simplifying the code.
The tilcdc_init and tilcdc_fini wrapper functions are removed since they
served no purpose after the component framework was eliminated. Their
logic is integrated directly into probe and remove.
Key changes:
- Use devm_drm_dev_alloc() instead of drm_dev_alloc().
- Use drmm_mode_config_init() instead of drm_mode_config_init().
- Align the remove path with the probe error path to ensure consistent
cleanup ordering in both success and failure cases.
- Adjust platform_set_drvdata() to store the private structure instead
of the drm_device, matching the new allocation pattern.
These changes reduce error-prone code while maintaining the same
functional behavior.
drm/tilcdc: Move tilcdc_init/fini closer to probe/remove
Move tilcdc_init/fini functions adjacent to the probe and remove functions
in preparation for cleanup and modernization. This improves readability
for subsequent commits that will refactor these functions.
drm/tilcdc: Use drm_module_platform_driver() helper
Use the drm_module_platform_driver() helper macro to simplify driver
registration. This macro handles both the platform driver registration
and the drm_firmware_drivers_only() check, making the custom init/exit
functions unnecessary.
drm/tilcdc: Remove the useless module list support
The tilcdc driver previously supported a sub-module system where
external display drivers (panels, encoders) could register themselves
through tilcdc_module_init() and be automatically initialized through
a module list. This infrastructure became unused after the component
framework support and panel driver was removed.
drm/tilcdc: Rename tilcdc_external to tilcdc_encoder
The tilcdc_external module describes the encoder part of the tilcdc
driver. Rename it to tilcdc_encoder for better clarity and to make
the naming more consistent with DRM subsystem conventions, where
encoder-related files typically use "encoder" in their names.
drm/tilcdc: Rename external_encoder and external_connector to encoder and connector
Remove the "external_" prefix from encoder and connector members in the
tilcdc driver. These are internal driver structures and the "external"
naming is misleading. The simpler names better reflect that these are
the primary encoder and connector managed by this driver.
Also rename tilcdc_attach_external_device() to tilcdc_encoder_create()
for consistency and to better describe the function's purpose.
drm/tilcdc: Remove redundant #endif/#ifdef in debugfs code
Remove the unnecessary #endif/#ifdef CONFIG_DEBUG_FS pair that splits
the debugfs code section. This keeps all debugfs-related code within a
single preprocessor conditional block, improving code readability.
Remove the tilcdc_panel_info structure and its associated helper
function as the structure contains only redundant or unused parameters.
Most panel configuration parameters in tilcdc_panel_info are either:
- Already represented by existing DRM mode flags (invert_pxl_clk,
sync_edge via DRM_BUS_FLAG_*), or
- Set to identical values across all instances (panel_info_default),
making them effectively constants
The removed fifo_th field is already handled by priv->fifo_th when set.
Other removed fields (tft_alt_mode, raster_order) were always set to 0
in the only instance (panel_info_default) and thus had no effect.
This simplifies the code by eliminating unnecessary abstraction while
preserving all functional behavior.
The tilcdc driver previously used the component framework to bind
external encoder subdrivers (specifically the TDA998x HDMI encoder).
With the removal of these subdrivers in previous commits, the component
framework is no longer needed.
This commit removes all component framework infrastructure including:
- Component master operations and bind/unbind callbacks
- The is_componentized flag and conditional code paths
- tilcdc_get_external_components() and tilcdc_add_component_encoder()
- TDA998x-specific panel configuration
The driver now uses a simplified initialization path that directly
attaches external devices via the DRM bridge API, eliminating the
complexity of dual code paths for componentized vs non-componentized
configurations.
This cleanup removes approximately 140 lines of code and makes the
driver initialization flow more straightforward.
The tilcdc panel subdriver is a legacy, non-standard driver that has been
replaced by the standard panel-dpi driver and panel-simple infrastructure.
With the device tree bindings removed and all in-tree users migrated to
use panel-dpi, this driver no longer has any associated device tree
bindings or users. The panel-dpi driver combined with DRM bus flags
provides equivalent functionality in a standard way that is compatible
with the broader DRM panel ecosystem.
This removal eliminates 400+ lines of redundant code and completes the
migration to standard panel handling.
drm/tilcdc: Convert legacy panel binding via DT overlay at boot time
To maintain backward compatibility while removing the deprecated
tilcdc_panel driver, add a tilcdc_panel_legacy subdriver that converts
the legacy "ti,tilcdc,panel" devicetree binding to the standard
panel-dpi binding at early boot.
The conversion uses an embedded device tree overlay that is applied and
modified during subsys_initcall. The process:
- Apply embedded overlay to create a tilcdc-panel-dpi node with
port/endpoint connections to the LCDC
- Copy all properties from the legacy panel node to the new
tilcdc-panel-dpi node
- Copy display-timings from the legacy panel
- Convert legacy panel-info properties (invert-pxl-clk, sync-edge) to
standard display timing properties (pixelclk-active, syncclk-active)
- Disable the legacy panel by removing its compatible property to
prevent the deprecated driver from binding
The result is a standard tilcdc-panel-dpi node with proper endpoints and
timing properties, allowing the DRM panel infrastructure to work with
legacy devicetrees without modification.
Other legacy panel-info properties are not migrated as they consistently
use default values across all mainline devicetrees and can be hardcoded
in the tilcdc driver.
This feature is optional via CONFIG_DRM_TILCDC_PANEL_LEGACY and should
only be enabled for systems with legacy devicetrees containing
"ti,tilcdc,panel" nodes.
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.
projects / thirdparty / kernel / linux.git / log
