kernel/git/next/linux-next.git/drivers/gpu/drm/bridge, branch master

Merge branch 'for-linux-next' of https://gitlab.freedesktop.org/drm/misc/kernel.git

2026-09-10T15:06:13+00:00

drm/bridge: ti-sn65dsi83: Support LVDS Channel B on SN65DSI84

2026-09-09T17:29:29+00:00

Add support for using SN65DSI84 in single-link mode with output to LVDS Channel B. Reviewed-by: Luca Ceresoli Tested-by: Luca Ceresoli Signed-off-by: Esben Haabendal Link: https://patch.msgid.link/20260831-ti-sn65dsi83-fixes-v5-2-e712765d6c4f@geanix.com Signed-off-by: Luca Ceresoli

drm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work()

2026-09-09T15:07:54+00:00

The error handling of sn65dsi83_reset_pipe() in sn65dsi83_reset_work() has seen a couple of changes that seems to cause a bit of confusion. While sn65dsi83_reset_work() has implemented an early exit if sn65dsi83_reset_pipe() fails since it was added, when a commit from Maxime Ripard switched to use drm_bridge_helper_reset_crtc() [1] the sn65dsi83_reset_pipe() function would no longer return an error code, so the early exit was then a no-op, and even on sn65dsi83_reset_pipe() failure, enable_irq() has been called. When drm_bridge_enter()/drm_bridge_exit() resource protection was added, the drm_bridge_exit() incidentally was always called, which is the correct approach. But only because the early exit in sn65dsi83_reset_pipe() was never hit because sn65dsi83_reset_pipe() always returns 0. In order get back to a situation where enable_irq() is not called on sn65dsi83_reset_pipe() failure, which should help protect against irq storms, we need to reintroduce a non-zero return value from sn65dsi83_reset_pipe() on error, and fix sn65dsi83_reset_work() so that we always exit the DRM bridge critical section with drm_bridge_exit(). [1] commit e17fadff7ab9 ("drm/bridge: ti-sn65dsi83: Switch to drm_bridge_helper_reset_crtc") [2] commit d2e8d1bc840b ("drm/bridge: ti-sn65dsi83: protect device resources on unplug") Fixes: e17fadff7ab9 ("drm/bridge: ti-sn65dsi83: Switch to drm_bridge_helper_reset_crtc") Cc: stable@vger.kernel.org Signed-off-by: Esben Haabendal Reviewed-by: Herve Codina Reviewed-by: Luca Ceresoli Tested-by: Luca Ceresoli Link: https://patch.msgid.link/20260831-ti-sn65dsi83-fixes-v5-1-e712765d6c4f@geanix.com Signed-off-by: Luca Ceresoli

drm/bridge: analogix_dp: Add support for optional data-lanes mapping

2026-09-09T13:36:12+00:00

Parse the optional 'data-lanes' device tree property to support custom physical lane mapping configuration. If no valid configuration is found, fall back to the default lane map (0, 1, 2, 3) automatically and keep the driver running. Lane mapping is mainly used for below scenarios: 1. Correct PCB lane swap and differential line routing crossover without hardware changes; 2. Adapt mismatched lane pin definitions between SoC and eDP panel; 3. Support multiple panel hardware variants on the same board by configuring data-lanes in device tree only. Reviewed-by: Sebastian Reichel Signed-off-by: Damon Ding Reviewed-by: Luca Ceresoli Link: https://patch.msgid.link/20260828065153.590802-6-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli

drm/bridge: analogix_dp: Add validation for samsung,lane-count property

2026-09-09T13:36:12+00:00

Add validity check for samsung,lane-count to ensure DT-provided lane count values are specification-compliant. Suggested-by: Luca Ceresoli Reviewed-by: Luca Ceresoli Signed-off-by: Damon Ding Link: https://patch.msgid.link/20260828065153.590802-5-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli

drm/bridge: analogix_dp: Restore mandatory samsung DP DT properties

2026-09-09T13:36:12+00:00

Revert the change that made samsung,link-rate and samsung,lane-count optional for Exynos DP. Add error checking to fail probe early if the required DT properties are missing. If these properties are missing, video_info->max_link_rate and video_info->max_lane_count remain zero, and so do link_train.link_rate and link_train.lane_count used in the subsequent link training flow, resulting in link training failure. There is no way at all a device can work without these properties. Here is the code flow when either max_link_rate or max_lane_count is 0: analogix_dp_commit() -> analogix_dp_full_link_train(dp, max_lanes = 0, max_rate = 0) analogix_dp_full_link_train(max_lanes, max_rate): // Read sink capabilities via DPCD and sanitize them link_rate = read_dpcd(DP_MAX_LINK_RATE); // >= 0x06 after fixup lane_count = read_dpcd(DP_MAX_LANE_COUNT); // >= 1 after fixup // Clamp by the limits from DT if (link_rate > max_rate) // 0x06 > 0, always true link_rate = max_rate; // link_rate = 0 if (lane_count > max_lanes) // 1 > 0, always true lane_count = max_lanes; // lane_count = 0 // Configure TX with the zeroed values set_link_bandwidth(link_rate = 0) // writel() is only executed for bwtype == 0x06/0x0a, // so LINK_BW_SET is never written and stays at // reset value; phy_configure() gets link_rate = 0. set_lane_count(lane_count = 0) // writel(0, ANALOGIX_DP_LANE_COUNT_SET) enables 0 lanes; // phy_configure() is called with lanes = 0. // Program sink for link training drm_dp_dpcd_write(DP_LINK_BW_SET, {link_rate = 0/lane_count = 0}) // DP spec requires link rate in {0x06, 0x0a, 0x14} and // lane count in {1, 2, 4}. Writing zeros is illegal, so // the sink cannot enter the training state. // Training loop for (lane = 0; lane < lane_count /* 0 */; lane++) // loop body never executes; training_lane[] stays // uninitialized and no training register is programmed Since the sanitized sink values are always non-zero (link_rate >= 0x06, lane_count >= 1), the clamping with a zero maximum unconditionally forces the training parameters to zero. Clock recovery can never be achieved, so link training fails deterministically. Consequently, making these properties mandatory again cannot break any existing device: a DT without them could never have worked in the first place. Failing probe early with a clear error message is more helpful than a silent link training failure at runtime. Fixes: 0d0abd894ead ("drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288") Cc: stable@vger.kernel.org Reviewed-by: Luca Ceresoli Signed-off-by: Damon Ding Link: https://patch.msgid.link/20260828065153.590802-4-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli

drm/bridge: lontium: Drop redundant vendor prefix from I2C device name

2026-09-09T09:16:19+00:00

Device names for i2c_device_id are not OF compatibles and have a meaning only for in-tree users (which there are no except the driver itself), thus vendor prefix in this name is completely redundant. It is actually a discouraged pattern because for OF platforms it allows matching driver by I2C bus, instead of OF, thus hiding incomplete way of obtaining driver match data (lack of i2c_get_match_data() usage). Signed-off-by: Krzysztof Kozlowski Reviewed-by: Luca Ceresoli Link: https://patch.msgid.link/20260825143921.512966-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Luca Ceresoli

drm/bridge: tc358768: Enforce input bus flags via atomic_check

2026-09-09T09:03:46+00:00

The tc358768 declares static bridge timings requiring pixel data to be sampled on the positive clock edge. However, the DRM core default propagation simply copies the output-side bus flags, coming from the next bridge, connector or panel, to the input side. If the propagated flags are incompatible with the bridge ones, the data is wrongly sampled, typically resulting in visual artifacts on the panel. Implement the atomic_check hook, replacing the mutually exclusive mode_fixup, and set the bridge state input bus flags to the ones required by the tc358768. The sync polarity defaulting previously done in mode_fixup is carried over into atomic_check unchanged. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Cc: stable@vger.kernel.org Signed-off-by: Leonardo Costa Reviewed-by: Francesco Dolcini Reviewed-by: Swamil Jain Reviewed-by: Luca Ceresoli Link: https://patch.msgid.link/20260706132440.1594239-1-leoreis.costa@gmail.com Signed-off-by: Luca Ceresoli

drm/bridge: dw-hdmi-qp: use drm_hdmi_acr_get_n_cts() helper for audio N/CTS

2026-09-03T15:48:54+00:00

dw_hdmi_qp_set_sample_rate() open-coded its own N and CTS lookup tables and search/compute helpers, but it lacked the out-of-table CTS fallback needed by strict HDMI sinks at TMDS rates not in the table. The original LG G3 OLED audio mute (linux-rockchip 070633) was caused by dw_hdmi_qp_find_cts() returning 0 at 185.625 MHz, leaving AUDPKT_ACR_CTS_OVR_EN clear and falling back to the controller's internal CTS auto-measurement, which produces incorrect timing on the wire at out-of-table rates. The shared drm_hdmi_acr_get_n_cts() helper in drivers/gpu/drm/display/drm_hdmi_helper.c already implements the correct behaviour: it has the HDMI 1.4b spec N/CTS tables, and for TMDS rates not in the table it computes CTS = (TMDS * N) / (128 * Fs) inline (the canonical HDMI spec formula). It is already used by drivers/gpu/drm/msm/hdmi/hdmi_audio.c. Convert dw_hdmi_qp_set_sample_rate() to call the helper. This removes ~200 lines of open-coded tables and search functions (dw_hdmi_qp_find_n, _compute_n, _find_cts, _audio_math_diff, _match_tmds_n_table, common_tmds_n_table[], common_tmds_cts_table[]) and fixes the strict-sink audio mute as a side effect of using the helper's complete N+CTS path. Tested on R76S (RK3576) running Linux 7.0.1, against the LG G3 OLED (the sink that originally reported the mute in linux-rockchip 070633) at four TMDS rates spanning HDMI 1.4 and HDMI 2.0: TMDS Mode Audio with v3 148.5 MHz 1080p60 8-bit plays 185.625 MHz 1080p60 10-bit plays 297 MHz 1080p100 8-bit plays 594 MHz 3840p60 8-bit plays Without this change, the LG G3 mutes audio at 185.625, 297, and 594 MHz (every rate outside dw-hdmi-qp's open-coded CTS table, which contained only 148.5 MHz and below). With this change, drm_hdmi_acr_get_n_cts() supplies the correct CTS at every rate -- table-canonical at 148.5 / 297 / 594 MHz, and computed via the HDMI 1.4b formula at 185.625 MHz. The 148.5 MHz row is a regression check confirming the in-table path is unchanged. The Kogan KALED43XU9210STA (a permissive HDMI 2.0 sink that plays audio at all rates with or without this change) was used as a no-regression control: audio plays at 594 MHz with v3 loaded. The open-coded N table in dw-hdmi-qp included optimised N values for some TMDS rates that are not in the helper's table (e.g. various non-CEA rates between 28-162 MHz). For those rates the helper's fallback returns N = 128 * Fs / 1000, which is the same value dw_hdmi_qp_compute_n() returned when no table optimisation was needed; no audio regression has been observed at the rates tested above. Reported-by: Simon Wright Closes: https://lore.kernel.org/linux-rockchip/ME3P282MB21960D9D68BFF520316BDFCEA83E2@ME3P282MB2196.AUSP282.PROD.OUTLOOK.COM/ Suggested-by: Cristian Ciocaltea Suggested-by: Jonas Karlman Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Simon Wright Tested-by: Igor Paunovic # RK3588 Orange Pi 5 Plus, both HDMI controllers Tested-by: Christian Hewitt Reviewed-by: Cristian Ciocaltea Tested-by: Cristian Ciocaltea Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/86fcf349-0a7a-4618-9001-612371b0f71b@symple.nz

drm/bridge: parade-ps8640: select DRM_PANEL_BRIDGE, not DRM_PANEL

2026-09-02T17:02:50+00:00

This driver does not use the drm_panel APIs at all, so no need to select DRM_PANEL. But it uses devm_drm_of_get_bridge(), which is enabled by DRM_PANEL_BRIDGE. Cc: Douglas Anderson Cc: Jitao Shi Cc: CK Hu Cc: Enric Balletbo i Serra Cc: Pin-yen Lin Reviewed-by: Douglas Anderson Link: https://patch.msgid.link/20260831-drm-bridge-drm_panel-cleanup-v3-8-50efd8168b3e@bootlin.com Signed-off-by: Luca Ceresoli