linux-stable.git/drivers/gpu/drm/bridge, branch linux-6.17.y Linux kernel stable tree drm/bridge: sii902x: Fix HDMI detection with DRM_BRIDGE_ATTACH_NO_CONNECTOR 2025-12-06T21:27:31+00:00 Devarsh Thakkar devarsht@ti.com 2025-10-30T15:16:35+00:00 3074e7a366eae686275e9210fb55a127d9e0bbd4 [ Upstream commit d6732ef4ab252e5753be7acad87b0a91cfd06953 ] The sii902x driver was caching HDMI detection state in a sink_is_hdmi field and checking it in mode_set() to determine whether to set HDMI or DVI output mode. This approach had two problems: 1. With DRM_BRIDGE_ATTACH_NO_CONNECTOR (used by modern display drivers like TIDSS), the bridge's get_modes() is never called. Instead, the drm_bridge_connector helper calls the bridge's edid_read() and updates the connector itself. This meant sink_is_hdmi was never populated, causing the driver to default to DVI mode and breaking HDMI audio. 2. The mode_set() callback doesn't receive atomic state or connector pointer, making it impossible to check connector->display_info.is_hdmi directly at that point. Fix this by moving the HDMI vs DVI decision from mode_set() to atomic_enable(), where we can access the connector via drm_atomic_get_new_connector_for_encoder(). This works for both connector models: - With DRM_BRIDGE_ATTACH_NO_CONNECTOR: Returns the drm_bridge_connector created by the display driver, which has already been updated by the helper's call to drm_edid_connector_update() - Without DRM_BRIDGE_ATTACH_NO_CONNECTOR (legacy): Returns the connector embedded in sii902x struct, which gets updated by the bridge's own get_modes() Fixes: 3de47e1309c2 ("drm/bridge: sii902x: use display info is_hdmi") Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251030151635.3019864-1-devarsht@ti.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit d6732ef4ab252e5753be7acad87b0a91cfd06953 ]

The sii902x driver was caching HDMI detection state in a sink_is_hdmi field
and checking it in mode_set() to determine whether to set HDMI or DVI
output mode. This approach had two problems:

1. With DRM_BRIDGE_ATTACH_NO_CONNECTOR (used by modern display drivers like
TIDSS), the bridge's get_modes() is never called. Instead, the
drm_bridge_connector helper calls the bridge's edid_read() and updates the
connector itself. This meant sink_is_hdmi was never populated, causing the
driver to default to DVI mode and breaking HDMI audio.

2. The mode_set() callback doesn't receive atomic state or connector
pointer, making it impossible to check connector->display_info.is_hdmi
directly at that point.

Fix this by moving the HDMI vs DVI decision from mode_set() to
atomic_enable(), where we can access the connector via
drm_atomic_get_new_connector_for_encoder(). This works for both connector
models:

- With DRM_BRIDGE_ATTACH_NO_CONNECTOR: Returns the drm_bridge_connector
  created by the display driver, which has already been updated by the
helper's call to drm_edid_connector_update()

- Without DRM_BRIDGE_ATTACH_NO_CONNECTOR (legacy): Returns the connector
  embedded in sii902x struct, which gets updated by the bridge's own
get_modes()

Fixes: 3de47e1309c2 ("drm/bridge: sii902x: use display info is_hdmi")
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20251030151635.3019864-1-devarsht@ti.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/bridge: write full Audio InfoFrame 2025-11-13T20:37:17+00:00 Dmitry Baryshkov dmitry.baryshkov@oss.qualcomm.com 2025-09-03T16:21:29+00:00 a0ae4b35633512159a2e2cb07c82ef1544794978 [ Upstream commit f0e7f358e72b10b01361787134ebcbd9e9aa72d9 ] Instead of writing the first byte of the infoframe (and hoping that the rest is default / zeroes), hook Audio InfoFrame support into the write_infoframe / clear_infoframes callbacks and use drm_atomic_helper_connector_hdmi_update_audio_infoframe() to write the frame. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250903-adv7511-audio-infoframe-v1-2-05b24459b9a4@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit f0e7f358e72b10b01361787134ebcbd9e9aa72d9 ]

Instead of writing the first byte of the infoframe (and hoping that the
rest is default / zeroes), hook Audio InfoFrame support into the
write_infoframe / clear_infoframes callbacks and use
drm_atomic_helper_connector_hdmi_update_audio_infoframe() to write the
frame.

Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20250903-adv7511-audio-infoframe-v1-2-05b24459b9a4@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/bridge: display-connector: don't set OP_DETECT for DisplayPorts 2025-11-13T20:37:02+00:00 Dmitry Baryshkov dmitry.baryshkov@oss.qualcomm.com 2025-08-02T10:40:35+00:00 de68849113b988a54ee994263ebf736840c05129 [ Upstream commit cb640b2ca54617f4a9d4d6efd5ff2afd6be11f19 ] Detecting the monitor for DisplayPort targets is more complicated than just reading the HPD pin level: it requires reading the DPCD in order to check what kind of device is attached to the port and whether there is an actual display attached. In order to let DRM framework handle such configurations, disable DRM_BRIDGE_OP_DETECT for dp-connector devices, letting the actual DP driver perform detection. This still keeps DRM_BRIDGE_OP_HPD enabled, so it is valid for the bridge to report HPD events. Currently inside the kernel there are only two targets which list hpd-gpios for dp-connector devices: arm64/qcom/qcs6490-rb3gen2 and arm64/qcom/sa8295p-adp. Both should be fine with this change. Cc: Bjorn Andersson <andersson@kernel.org> Cc: Konrad Dybcio <konradybcio@kernel.org> Cc: linux-arm-msm@vger.kernel.org Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250802-dp-conn-no-detect-v1-1-2748c2b946da@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit cb640b2ca54617f4a9d4d6efd5ff2afd6be11f19 ]

Detecting the monitor for DisplayPort targets is more complicated than
just reading the HPD pin level: it requires reading the DPCD in order to
check what kind of device is attached to the port and whether there is
an actual display attached.

In order to let DRM framework handle such configurations, disable
DRM_BRIDGE_OP_DETECT for dp-connector devices, letting the actual DP
driver perform detection. This still keeps DRM_BRIDGE_OP_HPD enabled, so
it is valid for the bridge to report HPD events.

Currently inside the kernel there are only two targets which list
hpd-gpios for dp-connector devices: arm64/qcom/qcs6490-rb3gen2 and
arm64/qcom/sa8295p-adp. Both should be fine with this change.

Cc: Bjorn Andersson <andersson@kernel.org>
Cc: Konrad Dybcio <konradybcio@kernel.org>
Cc: linux-arm-msm@vger.kernel.org
Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://lore.kernel.org/r/20250802-dp-conn-no-detect-v1-1-2748c2b946da@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/bridge: cdns-dsi: Don't fail on MIPI_DSI_MODE_VIDEO_BURST 2025-11-13T20:37:00+00:00 Tomi Valkeinen tomi.valkeinen@ideasonboard.com 2025-07-23T10:05:21+00:00 333776ae37102975f9980cbfcf8105703d6af7d1 [ Upstream commit 7070f55f294745c5a3c033623b76309f3512be67 ] While the cdns-dsi does not support DSI burst mode, the burst mode is essentially DSI event mode with more versatile clocking and timings. Thus cdns-dsi doesn't need to fail if the DSI peripheral driver requests MIPI_DSI_MODE_VIDEO_BURST. In my particular use case, this allows the use of ti-sn65dsi83 driver. Tested-by: Parth Pancholi <parth.pancholi@toradex.com> Tested-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-15-e61cc06074c2@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 7070f55f294745c5a3c033623b76309f3512be67 ]

While the cdns-dsi does not support DSI burst mode, the burst mode is
essentially DSI event mode with more versatile clocking and timings.
Thus cdns-dsi doesn't need to fail if the DSI peripheral driver requests
MIPI_DSI_MODE_VIDEO_BURST.

In my particular use case, this allows the use of ti-sn65dsi83 driver.

Tested-by: Parth Pancholi <parth.pancholi@toradex.com>
Tested-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-15-e61cc06074c2@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/bridge: cdns-dsi: Fix REG_WAKEUP_TIME value 2025-11-13T20:37:00+00:00 Tomi Valkeinen tomi.valkeinen@ideasonboard.com 2025-07-23T10:05:17+00:00 74d25a79f2e2e29f2bc057f5c262fb3b3a460190 [ Upstream commit eea4f89b6461294ed6bea1d3285bb3f79c09a041 ] The driver tries to calculate the value for REG_WAKEUP_TIME. However, the calculation itself is not correct, and to add on it, the resulting value is almost always larger than the field's size, so the actual result is more or less random. According to the docs, figuring out the value for REG_WAKEUP_TIME requires HW characterization and there's no way to have a generic algorithm to come up with the value. That doesn't help at all... However, we know that the value must be smaller than the line time, and, at least in my understanding, the proper value for it is quite small. Testing shows that setting it to 1/10 of the line time seems to work well. All video modes from my HDMI monitor work with this algorithm. Hopefully we'll get more information on how to calculate the value, and we can then update this. Tested-by: Parth Pancholi <parth.pancholi@toradex.com> Tested-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-11-e61cc06074c2@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit eea4f89b6461294ed6bea1d3285bb3f79c09a041 ]

The driver tries to calculate the value for REG_WAKEUP_TIME. However,
the calculation itself is not correct, and to add on it, the resulting
value is almost always larger than the field's size, so the actual
result is more or less random.

According to the docs, figuring out the value for REG_WAKEUP_TIME
requires HW characterization and there's no way to have a generic
algorithm to come up with the value. That doesn't help at all...

However, we know that the value must be smaller than the line time, and,
at least in my understanding, the proper value for it is quite small.
Testing shows that setting it to 1/10 of the line time seems to work
well. All video modes from my HDMI monitor work with this algorithm.

Hopefully we'll get more information on how to calculate the value, and
we can then update this.

Tested-by: Parth Pancholi <parth.pancholi@toradex.com>
Tested-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-11-e61cc06074c2@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/bridge: lt9211: Drop check for last nibble of version register 2025-10-23T14:24:32+00:00 Marek Vasut marek.vasut@mailbox.org 2025-10-11T10:59:53+00:00 295f35cd6cc69225855f1d1f3b927a0c351b0c91 [ Upstream commit db74b04edce1bc86b9a5acc724c7ca06f427ab60 ] There is now a new LT9211 rev. U5, which reports chip ID 0x18 0x01 0xe4 . The previous LT9211 reported chip ID 0x18 0x01 0xe3 , which is what the driver checks for right now. Since there is a possibility there will be yet another revision of the LT9211 in the future, drop the last version nibble check to allow all future revisions of the chip to work with this driver. This fix makes LT9211 rev. U5 work with this driver. Fixes: 8ce4129e3de4 ("drm/bridge: lt9211: Add Lontium LT9211 bridge driver") Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251011110017.12521-1-marek.vasut@mailbox.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit db74b04edce1bc86b9a5acc724c7ca06f427ab60 ]

There is now a new LT9211 rev. U5, which reports chip ID 0x18 0x01 0xe4 .
The previous LT9211 reported chip ID 0x18 0x01 0xe3 , which is what the
driver checks for right now. Since there is a possibility there will be
yet another revision of the LT9211 in the future, drop the last version
nibble check to allow all future revisions of the chip to work with this
driver.

This fix makes LT9211 rev. U5 work with this driver.

Fixes: 8ce4129e3de4 ("drm/bridge: lt9211: Add Lontium LT9211 bridge driver")
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20251011110017.12521-1-marek.vasut@mailbox.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/bridge: cdns-dsi: Fix the _atomic_check() 2025-10-15T10:03:42+00:00 Aradhya Bhatia aradhya.bhatia@linux.dev 2025-07-23T10:05:07+00:00 0be34e72e2f4887599685f1a88d4212f540d6dfc [ Upstream commit 04864af849d9ae0dd020798f5b3632d9cf26fa03 ] Use the "adjusted_mode" for the dsi configuration check, as that is the more appropriate display_mode for validation, and later bridge enable. Also, fix the mode_valid_check parameter from false to true, as the dsi configuration check is taking place during the check-phase, and the crtc_* mode values are not expected to be populated yet. Fixes: a53d987756ea ("drm/bridge: cdns-dsi: Move DSI mode check to _atomic_check()") Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-1-e61cc06074c2@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 04864af849d9ae0dd020798f5b3632d9cf26fa03 ]

Use the "adjusted_mode" for the dsi configuration check, as that is the
more appropriate display_mode for validation, and later bridge enable.

Also, fix the mode_valid_check parameter from false to true, as the dsi
configuration check is taking place during the check-phase, and the
crtc_* mode values are not expected to be populated yet.

Fixes: a53d987756ea ("drm/bridge: cdns-dsi: Move DSI mode check to _atomic_check()")
Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Tested-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-1-e61cc06074c2@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/bridge: it6505: select REGMAP_I2C 2025-10-15T10:03:41+00:00 Chia-I Wu olvaffe@gmail.com 2025-06-10T23:58:25+00:00 f24dd254bde1252220fa2c1c008f7f2b6d081f9a [ Upstream commit 21b137f651cf9d981e22d2c60a2a8105f50a6361 ] Fix aarch64-linux-gnu-ld: drivers/gpu/drm/bridge/ite-it6505.o: in function `it6505_i2c_probe': ite-it6505.c:(.text+0x754): undefined reference to `__devm_regmap_init_i2c' Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver") Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://patch.msgid.link/20250610235825.3113075-1-olvaffe@gmail.com Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 21b137f651cf9d981e22d2c60a2a8105f50a6361 ]

Fix

  aarch64-linux-gnu-ld: drivers/gpu/drm/bridge/ite-it6505.o: in function `it6505_i2c_probe':
  ite-it6505.c:(.text+0x754): undefined reference to `__devm_regmap_init_i2c'

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://patch.msgid.link/20250610235825.3113075-1-olvaffe@gmail.com
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm: bridge: cdns-mhdp8546: Fix missing mutex unlock on error path 2025-09-16T13:42:35+00:00 Qi Xi xiqi2@huawei.com 2025-09-04T03:44:47+00:00 288dac9fb6084330d968459c750c838fd06e10e6 Add missing mutex unlock before returning from the error path in cdns_mhdp_atomic_enable(). Fixes: 935a92a1c400 ("drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Qi Xi <xiqi2@huawei.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20250904034447.665427-1-xiqi2@huawei.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> 
Add missing mutex unlock before returning from the error path in
cdns_mhdp_atomic_enable().

Fixes: 935a92a1c400 ("drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Qi Xi <xiqi2@huawei.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250904034447.665427-1-xiqi2@huawei.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ 2025-09-15T18:44:42+00:00 Loic Poulain loic.poulain@oss.qualcomm.com 2025-07-09T08:54:38+00:00 a10f910c77f280327b481e77eab909934ec508f0 If the interrupt occurs before resource initialization is complete, the interrupt handler/worker may access uninitialized data such as the I2C tcpc_client device, potentially leading to NULL pointer dereference. Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Fixes: 8bdfc5dae4e3 ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250709085438.56188-1-loic.poulain@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 
If the interrupt occurs before resource initialization is complete, the
interrupt handler/worker may access uninitialized data such as the I2C
tcpc_client device, potentially leading to NULL pointer dereference.

Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Fixes: 8bdfc5dae4e3 ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250709085438.56188-1-loic.poulain@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>