<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/bridge, branch v4.19.112</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.112</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.112'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-12-31T15:35:14+00:00</updated>
<entry>
<title>drm/bridge: dw-hdmi: Restore audio when setting a mode</title>
<updated>2019-12-31T15:35:14+00:00</updated>
<author>
<name>Daniel Kurtz</name>
<email>djkurtz@chromium.org</email>
</author>
<published>2019-10-08T10:21:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=327e41607bd197fea43bfb0001b158210e89fc08'/>
<id>urn:sha1:327e41607bd197fea43bfb0001b158210e89fc08</id>
<content type='text'>
[ Upstream commit fadfee3f9d8f114435a8a3e9f83a227600d89de7 ]

When setting a new display mode, dw_hdmi_setup() calls
dw_hdmi_enable_video_path(), which disables all hdmi clocks, including
the audio clock.

We should only (re-)enable the audio clock if audio was already enabled
when setting the new mode.

Without this patch, on RK3288, there will be HDMI audio on some monitors
if i2s was played to headphone when the monitor was plugged.
ACER H277HU and ASUS PB278 are two of the monitors showing this issue.

Signed-off-by: Cheng-Yi Chiang &lt;cychiang@chromium.org&gt;
Signed-off-by: Daniel Kurtz &lt;djkurtz@chromium.org&gt;
Signed-off-by: Yakir Yang &lt;ykk@rock-chips.com&gt;
Reviewed-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Signed-off-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20191008102145.55134-1-cychiang@chromium.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: dw-hdmi: Refuse DDC/CI transfers on the internal I2C controller</title>
<updated>2019-12-31T15:34:58+00:00</updated>
<author>
<name>Matthias Kaehlcke</name>
<email>mka@chromium.org</email>
</author>
<published>2019-10-02T19:44:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=da6c7498c6a656edc3b737a877670348dce3f2f0'/>
<id>urn:sha1:da6c7498c6a656edc3b737a877670348dce3f2f0</id>
<content type='text'>
[ Upstream commit bee447e224b2645911c5d06e35dc90d8433fcef6 ]

The DDC/CI protocol involves sending a multi-byte request to the
display via I2C, which is typically followed by a multi-byte
response. The internal I2C controller only allows single byte
reads/writes or reads of 8 sequential bytes, hence DDC/CI is not
supported when the internal I2C controller is used. The I2C
transfers complete without errors, however the data in the response
is garbage. Abort transfers to/from slave address 0x37 (DDC) with
-EOPNOTSUPP, to make it evident that the communication is failing.

Signed-off-by: Matthias Kaehlcke &lt;mka@chromium.org&gt;
Reviewed-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Reviewed-by: Sean Paul &lt;sean@poorly.run&gt;
Acked-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Signed-off-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20191002124354.v2.1.I709dfec496f5f0b44a7b61dcd4937924da8d8382@changeid
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: analogix-anx78xx: silence -EPROBE_DEFER warnings</title>
<updated>2019-12-31T15:34:48+00:00</updated>
<author>
<name>Brian Masney</name>
<email>masneyb@onstation.org</email>
</author>
<published>2019-08-15T00:48:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0f08ffb42e43d83d5979bceef721cdb7584b7775'/>
<id>urn:sha1:0f08ffb42e43d83d5979bceef721cdb7584b7775</id>
<content type='text'>
[ Upstream commit 2708e876272d89bbbff811d12834adbeef85f022 ]

Silence two warning messages that occur due to -EPROBE_DEFER errors to
help cleanup the system boot log.

Signed-off-by: Brian Masney &lt;masneyb@onstation.org&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190815004854.19860-4-masneyb@onstation.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/rockchip: Check for fast link training before enabling psr</title>
<updated>2019-10-07T16:56:32+00:00</updated>
<author>
<name>Sean Paul</name>
<email>seanpaul@chromium.org</email>
</author>
<published>2019-06-11T16:08:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=441c1558233856636110b2330cf0c91ce069355e'/>
<id>urn:sha1:441c1558233856636110b2330cf0c91ce069355e</id>
<content type='text'>
[ Upstream commit ad309284a52be47c8b3126c9376358bf381861bc ]

Once we start shutting off the link during PSR, we're going to want fast
training to work. If the display doesn't support fast training, don't
enable psr.

Changes in v2:
- None
Changes in v3:
- None
Changes in v4:
- None
Changes in v5:
- None

Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-3-sean@poorly.run
Link to v2: https://patchwork.freedesktop.org/patch/msgid/20190326204509.96515-2-sean@poorly.run
Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-9-sean@poorly.run
Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-8-sean@poorly.run

Cc: Zain Wang &lt;wzz@rock-chips.com&gt;
Cc: Tomasz Figa &lt;tfiga@chromium.org&gt;
Tested-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Reviewed-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Signed-off-by: Sean Paul &lt;seanpaul@chromium.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190611160844.257498-8-sean@poorly.run
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: tc358767: Increase AUX transfer length limit</title>
<updated>2019-10-07T16:56:29+00:00</updated>
<author>
<name>Andrey Smirnov</name>
<email>andrew.smirnov@gmail.com</email>
</author>
<published>2019-06-19T05:27:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=db472be8b3409d308d1742ff8d717c87adba32ce'/>
<id>urn:sha1:db472be8b3409d308d1742ff8d717c87adba32ce</id>
<content type='text'>
[ Upstream commit e0655feaec62d5139b6b13a7b1bbb1ab8f1c2d83 ]

According to the datasheet tc358767 can transfer up to 16 bytes via
its AUX channel, so the artificial limit of 8 appears to be too
low. However only up to 15-bytes seem to be actually supported and
trying to use 16-byte transfers results in transfers failing
sporadically (with bogus status in case of I2C transfers), so limit it
to 15.

Signed-off-by: Andrey Smirnov &lt;andrew.smirnov@gmail.com&gt;
Reviewed-by: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Reviewed-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Cc: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Cc: Laurent Pinchart &lt;Laurent.pinchart@ideasonboard.com&gt;
Cc: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Cc: Andrey Gusakov &lt;andrey.gusakov@cogentembedded.com&gt;
Cc: Philipp Zabel &lt;p.zabel@pengutronix.de&gt;
Cc: Cory Tusar &lt;cory.tusar@zii.aero&gt;
Cc: Chris Healy &lt;cphealy@gmail.com&gt;
Cc: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190619052716.16831-9-andrew.smirnov@gmail.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: tfp410: fix memleak in get_modes()</title>
<updated>2019-09-06T08:22:02+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2019-06-10T13:57:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=edd40f54736d716ad4e40aa6f18b0a1b79051f70'/>
<id>urn:sha1:edd40f54736d716ad4e40aa6f18b0a1b79051f70</id>
<content type='text'>
[ Upstream commit c08f99c39083ab55a9c93b3e93cef48711294dad ]

We don't free the edid blob allocated by the call to drm_get_edid(),
causing a memleak. Fix this by calling kfree(edid) at the end of the
get_modes().

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190610135739.6077-1-tomi.valkeinen@ti.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: lvds-encoder: Fix build error while CONFIG_DRM_KMS_HELPER=m</title>
<updated>2019-08-25T08:47:54+00:00</updated>
<author>
<name>YueHaibing</name>
<email>yuehaibing@huawei.com</email>
</author>
<published>2019-07-29T07:12:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=202aa96f052aa65d13a2e49f9c268ed124dbd648'/>
<id>urn:sha1:202aa96f052aa65d13a2e49f9c268ed124dbd648</id>
<content type='text'>
[ Upstream commit f4cc743a98136df3c3763050a0e8223b52d9a960 ]

If DRM_LVDS_ENCODER=y but CONFIG_DRM_KMS_HELPER=m,
build fails:

drivers/gpu/drm/bridge/lvds-encoder.o: In function `lvds_encoder_probe':
lvds-encoder.c:(.text+0x155): undefined reference to `devm_drm_panel_bridge_add'

Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Fixes: dbb58bfd9ae6 ("drm/bridge: Fix lvds-encoder since the panel_bridge rework.")
Signed-off-by: YueHaibing &lt;yuehaibing@huawei.com&gt;
Reviewed-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Signed-off-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190729071216.27488-1-yuehaibing@huawei.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: sii902x: pixel clock unit is 10kHz instead of 1kHz</title>
<updated>2019-07-31T05:26:59+00:00</updated>
<author>
<name>Jyri Sarha</name>
<email>jsarha@ti.com</email>
</author>
<published>2019-05-27T13:47:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f9bfd6bd8223b0fccd12d39131a8c6d5d3333cc0'/>
<id>urn:sha1:f9bfd6bd8223b0fccd12d39131a8c6d5d3333cc0</id>
<content type='text'>
[ Upstream commit 8dbfc5b65023b67397aca28e8adb25c819f6398c ]

The pixel clock unit in the first two registers (0x00 and 0x01) of
sii9022 is 10kHz, not 1kHz as in struct drm_display_mode. Division by
10 fixes the issue.

Signed-off-by: Jyri Sarha &lt;jsarha@ti.com&gt;
Reviewed-by: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Signed-off-by: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/1a2a8eae0b9d6333e7a5841026bf7fd65c9ccd09.1558964241.git.jsarha@ti.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: tc358767: read display_props in get_modes()</title>
<updated>2019-07-31T05:26:58+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2019-05-28T08:27:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7af9abd7d6bd7df0aea2408d6541a011cfaa99b3'/>
<id>urn:sha1:7af9abd7d6bd7df0aea2408d6541a011cfaa99b3</id>
<content type='text'>
[ Upstream commit 3231573065ad4f4ecc5c9147b24f29f846dc0c2f ]

We need to know the link bandwidth to filter out modes we cannot
support, so we need to have read the display props before doing the
filtering.

To ensure we have up to date display props, call tc_get_display_props()
in the beginning of tc_connector_get_modes().

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Reviewed-by: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Signed-off-by: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190528082747.3631-22-tomi.valkeinen@ti.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: adv7511: Fix low refresh rate selection</title>
<updated>2019-06-15T09:54:03+00:00</updated>
<author>
<name>Matt Redfearn</name>
<email>matt.redfearn@thinci.com</email>
</author>
<published>2019-04-24T13:22:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=124c23dca3ac1d786022cd0e62f483a7961ed124'/>
<id>urn:sha1:124c23dca3ac1d786022cd0e62f483a7961ed124</id>
<content type='text'>
[ Upstream commit 67793bd3b3948dc8c8384b6430e036a30a0ecb43 ]

The driver currently sets register 0xfb (Low Refresh Rate) based on the
value of mode-&gt;vrefresh. Firstly, this field is specified to be in Hz,
but the magic numbers used by the code are Hz * 1000. This essentially
leads to the low refresh rate always being set to 0x01, since the
vrefresh value will always be less than 24000. Fix the magic numbers to
be in Hz.
Secondly, according to the comment in drm_modes.h, the field is not
supposed to be used in a functional way anyway. Instead, use the helper
function drm_mode_vrefresh().

Fixes: 9c8af882bf12 ("drm: Add adv7511 encoder driver")
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Signed-off-by: Matt Redfearn &lt;matt.redfearn@thinci.com&gt;
Signed-off-by: Sean Paul &lt;seanpaul@chromium.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190424132210.26338-1-matt.redfearn@thinci.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
