<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/gpu/drm/bridge, branch linux-6.12.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.12.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.12.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2026-03-04T12:21:47Z</updated>
<entry>
<title>drm/bridge: anx7625: Fix invalid EDID size</title>
<updated>2026-03-04T12:21:47Z</updated>
<author>
<name>Loic Poulain</name>
<email>loic.poulain@oss.qualcomm.com</email>
</author>
<published>2025-12-18T15:13:07Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=96775be9f12f6a97d1ac16979439dc35b7555b67'/>
<id>urn:sha1:96775be9f12f6a97d1ac16979439dc35b7555b67</id>
<content type='text'>
[ Upstream commit 1d5362145de96b5d00d590605cc94cdfa572b405 ]

DRM checks EDID block count against allocated size in drm_edid_valid
function. We have to allocate the right EDID size instead of the max
size to prevent the EDID to be reported as invalid.

Cc: stable@kernel.org
Fixes: 7c585f9a71aa ("drm/bridge: anx7625: use struct drm_edid more")
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Signed-off-by: Loic Poulain &lt;loic.poulain@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20251218151307.95491-1-loic.poulain@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: display-connector: don't set OP_DETECT for DisplayPorts</title>
<updated>2025-11-13T20:34:13Z</updated>
<author>
<name>Dmitry Baryshkov</name>
<email>dmitry.baryshkov@oss.qualcomm.com</email>
</author>
<published>2025-08-02T10:40:35Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ac5a106c6da6e922a8c71b7505c2084ab6d45728'/>
<id>urn:sha1:ac5a106c6da6e922a8c71b7505c2084ab6d45728</id>
<content type='text'>
[ 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 &lt;andersson@kernel.org&gt;
Cc: Konrad Dybcio &lt;konradybcio@kernel.org&gt;
Cc: linux-arm-msm@vger.kernel.org
Acked-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Link: https://lore.kernel.org/r/20250802-dp-conn-no-detect-v1-1-2748c2b946da@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: cdns-dsi: Don't fail on MIPI_DSI_MODE_VIDEO_BURST</title>
<updated>2025-11-13T20:34:11Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ideasonboard.com</email>
</author>
<published>2025-07-23T10:05:21Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e6f4716011fd229eb022d0b1e60fff1b5dd24332'/>
<id>urn:sha1:e6f4716011fd229eb022d0b1e60fff1b5dd24332</id>
<content type='text'>
[ 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 &lt;parth.pancholi@toradex.com&gt;
Tested-by: Jayesh Choudhary &lt;j-choudhary@ti.com&gt;
Reviewed-by: Devarsh Thakkar &lt;devarsht@ti.com&gt;
Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-15-e61cc06074c2@ideasonboard.com
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ideasonboard.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: cdns-dsi: Fix REG_WAKEUP_TIME value</title>
<updated>2025-11-13T20:34:11Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ideasonboard.com</email>
</author>
<published>2025-07-23T10:05:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6827f61b02f4d57d1a1805c68b5f2258a26b86cf'/>
<id>urn:sha1:6827f61b02f4d57d1a1805c68b5f2258a26b86cf</id>
<content type='text'>
[ 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 &lt;parth.pancholi@toradex.com&gt;
Tested-by: Jayesh Choudhary &lt;j-choudhary@ti.com&gt;
Reviewed-by: Devarsh Thakkar &lt;devarsht@ti.com&gt;
Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-11-e61cc06074c2@ideasonboard.com
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ideasonboard.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: lt9211: Drop check for last nibble of version register</title>
<updated>2025-10-23T14:20:33Z</updated>
<author>
<name>Marek Vasut</name>
<email>marek.vasut@mailbox.org</email>
</author>
<published>2025-10-11T10:59:53Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e2a7c66261fe94929d931ece69ae441997ee0421'/>
<id>urn:sha1:e2a7c66261fe94929d931ece69ae441997ee0421</id>
<content type='text'>
[ 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 &lt;marek.vasut@mailbox.org&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/r/20251011110017.12521-1-marek.vasut@mailbox.org
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: it6505: select REGMAP_I2C</title>
<updated>2025-10-15T10:00:04Z</updated>
<author>
<name>Chia-I Wu</name>
<email>olvaffe@gmail.com</email>
</author>
<published>2025-06-10T23:58:25Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=91fc36f23b3097203f138a1d1921462fcbb60bb3'/>
<id>urn:sha1:91fc36f23b3097203f138a1d1921462fcbb60bb3</id>
<content type='text'>
[ 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 &lt;olvaffe@gmail.com&gt;
Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
Reviewed-by: Chen-Yu Tsai &lt;wenst@chromium.org&gt;
Link: https://patch.msgid.link/20250610235825.3113075-1-olvaffe@gmail.com
Signed-off-by: Chen-Yu Tsai &lt;wenst@chromium.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm: bridge: cdns-mhdp8546: Fix missing mutex unlock on error path</title>
<updated>2025-09-25T09:13:48Z</updated>
<author>
<name>Qi Xi</name>
<email>xiqi2@huawei.com</email>
</author>
<published>2025-09-04T03:44:47Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f108c98c7005a9288c6d26b138b08b5b4c8f85a5'/>
<id>urn:sha1:f108c98c7005a9288c6d26b138b08b5b4c8f85a5</id>
<content type='text'>
[ Upstream commit 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 &lt;hulkci@huawei.com&gt;
Signed-off-by: Qi Xi &lt;xiqi2@huawei.com&gt;
Reviewed-by: Luca Ceresoli &lt;luca.ceresoli@bootlin.com&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Link: https://lore.kernel.org/r/20250904034447.665427-1-xiqi2@huawei.com
Signed-off-by: Luca Ceresoli &lt;luca.ceresoli@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ</title>
<updated>2025-09-25T09:13:48Z</updated>
<author>
<name>Loic Poulain</name>
<email>loic.poulain@oss.qualcomm.com</email>
</author>
<published>2025-07-09T08:54:38Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0da73f7827691a5e2265b110d5fe12f29535ec92'/>
<id>urn:sha1:0da73f7827691a5e2265b110d5fe12f29535ec92</id>
<content type='text'>
[ Upstream commit 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 &lt;loic.poulain@oss.qualcomm.com&gt;
Fixes: 8bdfc5dae4e3 ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP")
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/r/20250709085438.56188-1-loic.poulain@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: ti-sn65dsi86: fix REFCLK setting</title>
<updated>2025-09-09T16:58:25Z</updated>
<author>
<name>Michael Walle</name>
<email>mwalle@kernel.org</email>
</author>
<published>2025-08-21T12:23:41Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=beec8f807ecc288fe4dbeee4decdf7f4609418dc'/>
<id>urn:sha1:beec8f807ecc288fe4dbeee4decdf7f4609418dc</id>
<content type='text'>
[ Upstream commit bdd5a14e660062114bdebaef9ad52adf04970a89 ]

The bridge has three bootstrap pins which are sampled to determine the
frequency of the external reference clock. The driver will also
(over)write that setting. But it seems this is racy after the bridge is
enabled. It was observed that although the driver write the correct
value (by sniffing on the I2C bus), the register has the wrong value.
The datasheet states that the GPIO lines have to be stable for at least
5us after asserting the EN signal. Thus, there seems to be some logic
which samples the GPIO lines and this logic appears to overwrite the
register value which was set by the driver. Waiting 20us after
asserting the EN line resolves this issue.

Fixes: a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver")
Signed-off-by: Michael Walle &lt;mwalle@kernel.org&gt;
Reviewed-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Signed-off-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Link: https://lore.kernel.org/r/20250821122341.1257286-1-mwalle@kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: ti-sn65dsi86: Remove extra semicolon in ti_sn_bridge_probe()</title>
<updated>2025-08-01T08:48:41Z</updated>
<author>
<name>Douglas Anderson</name>
<email>dianders@chromium.org</email>
</author>
<published>2025-07-14T20:06:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5c25b4f2769e55d663cd044965e42687b2bbf261'/>
<id>urn:sha1:5c25b4f2769e55d663cd044965e42687b2bbf261</id>
<content type='text'>
[ Upstream commit 15a7ca747d9538c2ad8b0c81dd4c1261e0736c82 ]

As reported by the kernel test robot, a recent patch introduced an
unnecessary semicolon. Remove it.

Fixes: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type")
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Closes: https://lore.kernel.org/oe-kbuild-all/202506301704.0SBj6ply-lkp@intel.com/
Reviewed-by: Devarsh Thakkar &lt;devarsht@ti.com&gt;
Signed-off-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Link: https://lore.kernel.org/r/20250714130631.1.I1cfae3222e344a3b3c770d079ee6b6f7f3b5d636@changeid
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
