Andy Yan [Fri, 6 Feb 2026 01:04:13 +0000 (09:04 +0800)]
drm/bridge: synopsys: dw-dp: Make i2s/spdif clk optional
The i2s/spdif clk are mandatory for rk3588, but not used
for the upcoming rk3576, so make it optional here.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260206010421.443605-4-andyshrk@163.com
Andy Yan [Fri, 6 Feb 2026 01:04:12 +0000 (09:04 +0800)]
drm/bridge: synopsys: dw-dp: Set pixel mode by platform data
In the implementation and integration of the SoC, the DW DisplayPort
hardware block can be configured to work in single, dual, quad pixel
mode on differnt platforms, so make the pixel mode set by plat_data
to support the upcoming rk3576 variant.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260206010421.443605-3-andyshrk@163.com
The DisplayPort found on RK3576 is very similar to that of RK3588,
but work in dual pixel mode. And itself does not depend on the I2S
clock or the SPDIF clock when transmit audio.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260206010421.443605-2-andyshrk@163.com
Hsieh Hung-En [Mon, 9 Feb 2026 16:16:21 +0000 (00:16 +0800)]
drm/rockchip: vop2: Use drm_err_ratelimited() for wait timeouts
Replace deprecated DRM_DEV_ERROR() with drm_err_ratelimited() in the VOP2
register wait timeout paths to align with current DRM logging helpers and
avoid flooding the kernel log when timeouts repeat.
Add fields and constants for coreboot framebuffer orientation. Set
corebootdrm's DRM connector state from the values. Not all firmware
provides orientation, so make it optional. Systems without, continue
to use unknown orientation.
v3:
- comment on _HAS_ORIENTATION semantics (Tzung-Bi)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Julius Werner <jwerner@chromium.org> Acked-by: Tzung-Bi Shih <tzungbi@kernel.org> # coreboot Link: https://patch.msgid.link/20260217155836.96267-13-tzimmermann@suse.de
drm/sysfb: corebootdrm: Add DRM driver for coreboot framebuffers
Add corebootdrm, a DRM driver for coreboot framebuffers. The driver
supports a pre-initialized framebuffer with various packed RGB formats.
The driver code is fairly small and uses the same logic as the other
sysfb drivers. Most of the implementation comes from existing sysfb
helpers.
Until now, coreboot relied on simpledrm or simplefb for boot-up graphics
output. Initialize the platform device for corebootdrm in the same place
in framebuffer_probe(). With a later commit, the simple-framebuffer should
be removed.
v4:
- sort include statements (Tzung-Bi)
v3:
- comment on _HAS_LFB semantics (Tzung-Bi)
- fix typo in commit description (Tzung-Bi)
- comment on simple-framebuffer being obsolete for coreboot
v2:
- reimplement as platform driver
- limit resources and mappings to known framebuffer memory; no
page alignment
- create corebootdrm device from coreboot framebuffer code
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Julius Werner <jwerner@chromium.org> Acked-by: Tzung-Bi Shih <tzungbi@kernel.org> # coreboot Link: https://patch.msgid.link/20260217155836.96267-12-tzimmermann@suse.de
Provide drm_sysfb_get_format(), a helper that finds a specific DRM
format from a list of pixel formats. The new function builds upon
drm_sysfb_get_format_si(), which finds the DRM format from a given
instance of struct screen_info. Now get the screen_info's pixel format
in the caller. Allows for matching pixel formats in drivers without
screen_info.
Convert the callers in efidrm and vesadrm to the new interface.
firmware: google: Pack structures for coreboot table entries
Pack the fields in the coreboot table entries. These entries are part of
the coreboot ABI, so they don't follow regular calling conventions. Fields
of type u64 are aligned to boundaries of 4 bytes instead of 8. [1]
So far this has not been a problem. In the future, padding bytes should
be added where explicit alignment is required.
firmware: google: Clean up include statements in coreboot_table.h
Include <linux/mod_devicetable.h> from source files and only forward-
declare struct coreboot_device_id in coreboot_table.h.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Tzung-Bi Shih <tzungbi@kernel.org> Acked-by: Julius Werner <jwerner@chromium.org> Link: https://patch.msgid.link/20260217155836.96267-8-tzimmermann@suse.de
firmware: google: Init coreboot bus with subsys_initcall()
Using module_init()/device_initcall() is too late to initialize
the coreboot bus, as there might already be drivers that depend
on it.
So far this hasn't been a problem, as coreboot controls all device
creation. Initializing the coreboot bus earlier in subsys_initcall()
will allow for external coreboot drivers to register themselves
with device_initcall(). Prepares coreboot to support additional
coreboot drivers from other subsystems.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Tzung-Bi Shih <tzungbi@kernel.org> Acked-by: Julius Werner <jwerner@chromium.org> Link: https://patch.msgid.link/20260217155836.96267-7-tzimmermann@suse.de
The framebuffer on the coreboot bus represents an entry in the
coreboot payload table; not the actual device. [1] Hence it must
not depend on any other driver setting.
firmware: google: framebuffer: Tie platform device to PCI hardware
Use the PCI device as parent of the system-framebuffer device instead
of the coreboot device. Prevents SIGBUS or SIGSEG after hot-unplug of
the PCI device while the framebuffer is active.
The simple-framebuffer device depends on the PCI hardware, so this
device needs to be its parent. The current coreboot parent is no
longer needed after the system-framebuffer device has been created.
On systems without PCI or if no PCI parent device could be found,
the platform device hangs on the platform bus directly.
The fix here is similar to code in sysfb, which contained that same
bug.
firmware: google: framebuffer: Init memory resource with helper macro
Initialize framebuffer memory resource with DEFINE_RES_MEM() instead
of open-coding the setup.
While at it, drop the resource name to make the kernel use the device
name of the simple-framebuffer device for the resource. The latter
includes a device number. While the meaning of the resource name is
somewhat fuzzy and varies across entries in /proc/iomem, showing the
device name seems more helpful than showing a fixed name.
firmware: google: framebuffer: Do not mark framebuffer as busy
Remove the flag IORESOURCE_BUSY flag from coreboot's framebuffer
resource. It prevents simpledrm from successfully requesting the
range for its own use; resulting in errors such as
[ 2.775430] simple-framebuffer simple-framebuffer.0: [drm] could not acquire memory region [mem 0x80000000-0x80407fff flags 0x80000200]
As with other uses of simple-framebuffer, the simple-framebuffer
device should only declare it's I/O resources, but not actively use
them.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 851b4c14532d ("firmware: coreboot: Add coreboot framebuffer driver") Acked-by: Tzung-Bi Shih <tzungbi@kernel.org> Acked-by: Julius Werner <jwerner@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Tzung-Bi Shih <tzungbi@kernel.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: chrome-platform@lists.linux.dev Cc: <stable@vger.kernel.org> # v4.18+ Link: https://patch.msgid.link/20260217155836.96267-3-tzimmermann@suse.de
firmware: google: framebuffer: Do not unregister platform device
The native driver takes over the framebuffer aperture by removing the
system- framebuffer platform device. Afterwards the pointer in drvdata
is dangling. Remove the entire logic around drvdata and let the kernel's
aperture helpers handle this. The platform device depends on the native
hardware device instead of the coreboot device anyway.
When commit 851b4c14532d ("firmware: coreboot: Add coreboot framebuffer
driver") added the coreboot framebuffer code, the kernel did not support
device-based aperture management. Instead native driviers only removed
the conflicting fbdev device. At that point, unregistering the framebuffer
device most likely worked correctly. It was definitely broken after
commit d9702b2a2171 ("fbdev/simplefb: Do not use struct
fb_info.apertures"). So take this commit for the Fixes tag. Earlier
releases might work depending on the native hardware driver.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: d9702b2a2171 ("fbdev/simplefb: Do not use struct fb_info.apertures") Acked-by: Tzung-Bi Shih <tzungbi@kernel.org> Acked-by: Julius Werner <jwerner@chromium.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Hans de Goede <hansg@kernel.org> Cc: linux-fbdev@vger.kernel.org Cc: <stable@vger.kernel.org> # v6.3+ Link: https://patch.msgid.link/20260217155836.96267-2-tzimmermann@suse.de
Jocelyn Falempe [Thu, 12 Feb 2026 10:05:54 +0000 (11:05 +0100)]
drm/panic: depends on PRINTK
drm_panic uses kmsg_dump_register() to register its panic handler, so
it won't work if CONFIG_PRINTK is not enabled.
Let's not pretend it could work without PRINTK, and depends
explicitly on it.
drm/vc4: hdmi: replace use of system_wq with system_percpu_wq
Currently if a user enqueues 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.
This patch continues the effort to refactor worqueue APIs, which has begun
with the change introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
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.
Timur Tabi [Mon, 9 Feb 2026 22:40:36 +0000 (16:40 -0600)]
drm/nouveau/gsp: add support for GA100
GA100 is a compute-only variant of GA102 that boots GSP-RM like a Turing.
Although architecturally like an Ampere, GA100 uses the same GSP-RM
firmware files as Turing, and therefore must boot it like Turing does.
In addition, as a compute-only part, GA100 has no display engine,
no VBIOS, and no graphics (GR) engine.
Since it doesn't have VBIOS, there is no FWSEC firmware, and so there is
no FRTS region that needs to be reserved or initialized.
Although Nouveau now supports GA100, there is currently no real support
for this GPU with either Clover or Rusticl/NVK, as both require a 3D
engine. This is in contrast with GH100, which does contain a GR engine
and is supported.
Also note that this patch partially reverts commit e8b3627bec35 ("nouveau:
don't attempt fwsec on sb on newer platforms."), which added fwsec
pointers to struct ga100_gsp erroneously.
Hongyang Zhao [Sat, 7 Feb 2026 07:32:55 +0000 (15:32 +0800)]
drm/bridge: lt9611: Add support for single Port B input
The LT9611 has two DSI input ports. The driver currently assumes Port A
is always used for single-port configurations. However, some boards
connect DSI to Port B only.
Update the driver to detect which ports are populated from devicetree
and configure the hardware accordingly:
- If only port@1 (Port B) is populated, configure port swap (0x8303
bit 6) and byte_clk source (0x8250 bit 3:2) for Port B operation
- If both ports are populated, use dual-port mode (Port A + B)
- If only port@0 (Port A) is populated, use single Port A (existing
behavior)
Hongyang Zhao [Sat, 7 Feb 2026 07:32:54 +0000 (15:32 +0800)]
dt-bindings: display: lt9611: Support single Port B input
The LT9611 has two DSI input ports (Port A and Port B). Update the
binding to clearly document the port mapping and allow using Port B
alone when DSI is physically connected to Port B only.
Changes:
- Clarify port@0 corresponds to DSI Port A input
- Clarify port@1 corresponds to DSI Port B input
- Change port requirement from mandatory port@0 to anyOf port@0/port@1,
allowing either port to be used independently
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Hongyang Zhao <hongyang.zhao@thundersoft.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Roger Shimizu <rosh@debian.org> Tested-by: Roger Shimizu <rosh@debian.org> Link: https://patch.msgid.link/20260207-rubikpi-next-20260116-v3-1-23b9aa189a3a@thundersoft.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Val Packett [Wed, 10 Dec 2025 15:39:23 +0000 (12:39 -0300)]
drm/virtio: Allow importing prime buffers when 3D is enabled
This functionality was added for using a KMS-only virtgpu with a physical
(or SR-IOV) headless GPU in passthrough, but it should not be restricted
to KMS-only mode. It can be used with cross-domain to pass guest memfds
to the host compositor with zero copies (using udmabuf on both sides).
Drop the check for the absence of virgl_3d to allow for more use cases.
Fixes: ca77f27a2665 ("drm/virtio: Import prime buffers from other devices as guest blobs") Signed-off-by: Val Packett <val@invisiblethingslab.com> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patch.msgid.link/20251210154755.1119861-2-val@invisiblethingslab.com
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.
projects / thirdparty / kernel / linux.git / log
