linux-toradex.git/drivers/gpu/drm/bridge/synopsys, branch master

drm/bridge: dw-hdmi-qp: Use the common TMDS char rate constant

2026-05-21T09:45:52+00:00

Replace the driver local HDMI14_MAX_TMDSCLK define with the shared
constant defined in the  header.

The local define incorrectly referenced HDMI 1.4, but the 340 MHz
maximum TMDS character rate was actually introduced in HDMI 1.3.

Suggested-by: Maxime Ripard 
Reviewed-by: Neil Armstrong 
Reviewed-by: Heiko Stuebner 
Reviewed-by: Maxime Ripard 
Link: https://patch.msgid.link/20260520144424.1633354-4-javierm@redhat.com
Signed-off-by: Javier Martinez Canillas

drm/bridge: dw-hdmi: Use the common TMDS char rate constant

2026-05-21T09:45:52+00:00

Replace the driver local HDMI14_MAX_TMDSCLK define with the shared
constant defined in the  header.

The local define incorrectly referenced HDMI 1.4, but the 340 MHz
maximum TMDS character rate was actually introduced in HDMI 1.3.

Suggested-by: Maxime Ripard 
Reviewed-by: Heiko Stuebner 
Reviewed-by: Neil Armstrong 
Reviewed-by: Maxime Ripard 
Link: https://patch.msgid.link/20260520144424.1633354-3-javierm@redhat.com
Signed-off-by: Javier Martinez Canillas

Merge tag 'drm-misc-next-2026-04-20' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next

2026-05-06T00:12:25+00:00

drm-misc-next for v7.1-rc1:

UAPI Changes:
- Expose per-client BO memory usage via fdinfo in amdxdna. (Hou)
- Change the default priority of drm scheduler to fair. (Tvrtko)

Cross-subsystem Changes:
- Revert hugetlb support in udmabuf. (Gunthorpe)
- Fix error in udmabuf with CONFIG_DMA_API_DEBUG(/ _SG). (Gavrilov)
- Add Docbook for DRM_IOCTL_SYNCOBJ_EVENTFD, (Ser)
  clarify drm_bridge_get/put. (Tvrtko)
- Change signature of drm_connector_attach_hdr_output_metadata_property. (Canal)
- Use IOVA allocations in gpusvm and pagemap APIs. (Brost)
- Fix tracepoints vs dma-fence lifetime. (Tvrtko)
- Convert st-dma*.c tests to use kunit. (Gunthorpe)

Core Changes:
- Deduplicate counter and timestamp retrieval in vblank code. (Ville)
- Parse AMD VSDB v3 in CTA extension blocks, and use it in amdgpu. (Chen)
- Prevent bridge and encoder chain changes at inopportune times. (Ceresoli)
- Map the run queue 1:1 to the drm scheduler. (Tvrtko)

Driver Changes:
- Assorted bugfixes and (documentation) updates to rockchip, bridge/synopsis,
  panfrost, tidss, accel/qaic, tilcdc, vc4, ast, imagination, panthor,
  renesas, accel/amdxdna, msxfb, bridge/imx8mp, nouveau.
  bridge/analogix_dp, bridge/exynos_dp, omap.
- Add support for CSW PNB601LS1-2, LGD LP116WHA-SPB1, panels.
- Add support for a lot of waveshare panels (Baryshkov)
- Support for AIE4 devices in accel/wamdxdna. (Zhang)
- Enable support for GEM shrinking in panthor. (Goel/Brezillon)
- Runtime Power Management is added to v3d. (Canal)
- Allow panel probing and use the panel bridge helper in analogix_dp. (Ding)
- Support XRGB1555 and C8 in mgag and XRGB1555 in ast. (Zimmermann)

From: Maarten Lankhorst 
Link: https://patch.msgid.link/bf31b1a1-951b-4f60-b226-22e8c083697d@linux.intel.com
Signed-off-by: Dave Airlie

drm: Rename struct drm_atomic_state to drm_atomic_commit

2026-05-04T04:05:04+00:00

The KMS framework uses two slightly different definitions for the state
concept. For a given object (plane, CRTC, encoder, etc., so
drm_$OBJECT_state), the state is the entire state of that object.
However, at the device level, drm_atomic_state refers to a state update
for a limited number of objects.

Thus, drm_atomic_state isn't the entire device state, but only the full
state of some objects in that device. This has been an endless source of
confusion and thus bugs.

We can rename the drm_atomic_state structure to drm_atomic_commit to
make it less confusing.

This patch was created using:

rg -l drm_atomic_state | \
	xargs sed -i 's/drm_atomic_state/drm_atomic_commit/g; s/drm_atomic_commit_helper/drm_atomic_state_helper/g'
mv drivers/gpu/drm/tests/drm_atomic_state_test.c drivers/gpu/drm/tests/drm_atomic_commit_test.c

Acked-by: Simona Vetter 
Acked-by: Thomas Zimmermann 
Acked-by: Jani Nikula 
Reviewed-by: Luca Ceresoli 
Tested-by: Luca Ceresoli 
Signed-off-by: Maxime Ripard 
Signed-off-by: Dave Airlie 
Link: https://patch.msgid.link/20260427-drm-drm-atomic-update-v4-1-c0e713bfdf25@kernel.org

Merge tag 'drm-fixes-2026-04-24' of https://gitlab.freedesktop.org/drm/kernel

2026-04-24T18:44:52+00:00

Pull more drm fixes from Dave Airlie:
 "These are the regular fixes that have built up over last couple of
  weeks, all pretty minor and spread all over.

  atomic:
   - raise the vblank timeout to avoid it on virtual drivers
   - fix colorop duplication

  bridge:
   - stm_lvds: state check fix
   - dw-mipi-dsi: bridge reference leak fix

  panel:
   - visionx-rm69299: init fix

  dma-fence:
   - fix sparse warning

  dma-buf:
   - UAF fix

  panthor:
   - mapping fix

  arcgpu:
   - device_node reference leak fix

  nouveau:
   - memory leak in error path fix
   - overflow in reloc path for old hw fix

  hv:
   - Kconfig fix

  v3d:
   - infinite loop fix"

* tag 'drm-fixes-2026-04-24' of https://gitlab.freedesktop.org/drm/kernel:
  drm/nouveau: fix u32 overflow in pushbuf reloc bounds check
  MAINTAINERS: split hisilicon maintenance and add Yongbang Shi for hibmc-drm matainers
  drm/v3d: Reject empty multisync extension to prevent infinite loop
  drm/panel: visionox-rm69299: Make use of prepare_prev_first
  drm/drm_atomic: duplicate colorop states if plane color pipeline in use
  drm/nouveau: fix nvkm_device leak on aperture removal failure
  hv: Select CONFIG_SYSFB only for CONFIG_HYPERV_VMBUS
  dma-fence: Silence sparse warning in dma_fence_describe
  drm/bridge: dw-mipi-dsi: Fix bridge leak when host attach fails
  drm/arcpgu: fix device node leak
  drm/panthor: Fix outdated function documentation
  drm/panthor: Extend VM locked region for remap case to be a superset
  dma-buf: fix UAF in dma_buf_put() tracepoint
  drm/bridge: stm_lvds: Do not fail atomic_check on disabled connector
  drm/atomic: Increase timeout in drm_atomic_helper_wait_for_vblanks()

drm/bridge: dw-hdmi: move next_bridge lookup to attach time

2026-04-14T11:52:32+00:00

This driver looks up the next_bridge at probe time and stores it in
hdmi->bridge.next_bridge, but only uses the stored value when attaching,
and only in the DRM_BRIDGE_ATTACH_NO_CONNECTOR case.

This will be problematic with an upcoming change, adding an hdmi-connector
using a device tree overlay when not present. That change is in turn
necessary to migrate the i.MX LCDIF driver to the bridge-connector.

The problem is that, adding the hdmi-connector via an overlay, devlink
considers hdmi-connector a consumer of the dw-hdmi device, generating a
chicken-egg problem:

 * hdmi-connector probe won't be tried until dw-hdmi is probed (devlink)
 * dw-hdmi probe will defer until it finds the next_bridge (the
   hdmi-connector wrapper bridge)

In preparation for those changes, move the next_bridge lookup from probe to
attach, when it is actually used. This allows dw-hdmi to probe, so that the
hdmi-connector can probe as well.

Also avoid storing the pointer in hdmi->bridge.next_bridge: the value is
computed when needed, thus a local variable is enough.

Finally, this also allows to slightly improve the code by not doing any DT
lookup in the !DRM_BRIDGE_ATTACH_NO_CONNECTOR case.

Tested-by: Martyn Welch 
Tested-by: Alexander Stein  # TQMa8MPxL/MBa8MPxL
Acked-by: Liu Ying 
Tested-by: Damon Ding  # rk3399
Link: https://patch.msgid.link/20260407-drm-lcdif-dbanc-v4-7-247a16e61ef9@bootlin.com
Signed-off-by: Luca Ceresoli

drm/bridge: dw-hdmi: warn on unsupported attach combination

2026-04-14T11:52:32+00:00

dw-hdmi can operate in two different modes, depending on the platform data
as set by the driver:

 A. hdmi->plat_data->output_port = 0:
    the HDMI output (port@1) in device tree is not used

 B. hdmi->plat_data->output_port = 1:
    the HDMI output (port@1) is parsed to find the next bridge

Only case B is supported when the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is
passed to the attach callback. Emit a warning when this is violated. Also
return -EINVAL which would be returned by drm_bridge_attach() right after
anyway.

Reviewed-by: Liu Ying 
Tested-by: Martyn Welch 
Tested-by: Alexander Stein  # TQMa8MPxL/MBa8MPxL
Tested-by: Damon Ding  # rk3399
Link: https://patch.msgid.link/20260407-drm-lcdif-dbanc-v4-6-247a16e61ef9@bootlin.com
Signed-off-by: Luca Ceresoli

drm/bridge: dw-mipi-dsi: Fix bridge leak when host attach fails

2026-04-14T10:29:03+00:00

dw_mipi_dsi_host_attach() and dw_mipi_dsi2_host_attach() call
drm_bridge_add() before pdata->host_ops->attach(). If attach fails,
the bridge stayed registered without drm_bridge_remove(), leaking the
bridge reference and leaving the device on the global bridge list.

Fixes: 90910a651123 ("drm/bridge/synopsys: dsi: add ability to have glue-specific attach and detach")
Fixes: 0d6d86253fef ("drm/bridge/synopsys: Add MIPI DSI2 host controller bridge")
Signed-off-by: Osama Abdelkader 
Reviewed-by: Luca Ceresoli 
Link: https://patch.msgid.link/20260403145208.15890-1-osama.abdelkader@gmail.com
Signed-off-by: Luca Ceresoli

drm/bridge: synopsys: dw-dp: Drop useless memory allocation

2026-03-26T19:30:46+00:00

The bridge gets allocated and initialized implicitly via the
devm_drm_bridge_alloc() helper in dw_dp_bind().  However, this is
preceded by an explicit allocation for the same dw_dp struct, which is
never used anywhere as the return from devm_kzalloc() gets immediately
overwritten by the aforementioned helper.

Get rid of the unnecessary and confusing memory allocation.

Signed-off-by: Cristian Ciocaltea 
Signed-off-by: Heiko Stuebner 
Link: https://patch.msgid.link/20260310-drm-rk-fixes-v2-8-645ecfb43f49@collabora.com

drm/bridge: synopsys: dw-hdmi: Convert to drm_output_color_format

2026-03-24T12:54:33+00:00

Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.

The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.

The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.

Reviewed-by: Philipp Zabel 
Acked-by: Jani Nikula 
Reviewed-by: Dmitry Baryshkov 
Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-9-f3935f6db579@kernel.org
Signed-off-by: Maxime Ripard