<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/gpu/drm/bridge/synopsys, branch linux-6.4.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.4.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.4.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2023-09-13T07:48:09Z</updated>
<entry>
<title>drm: bridge: dw-mipi-dsi: Fix enable/disable of DSI controller</title>
<updated>2023-09-13T07:48:09Z</updated>
<author>
<name>Ondrej Jirman</name>
</author>
<published>2023-06-17T22:48:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=98d233259a4dbc5c26abcabc506baf34d516ae00'/>
<id>urn:sha1:98d233259a4dbc5c26abcabc506baf34d516ae00</id>
<content type='text'>
[ Upstream commit 05aa61334592adb230749ff465b103ee10e63936 ]

Before this patch, booting to Linux VT and doing a simple:

  echo 2 &gt; /sys/class/graphics/fb0/blank
  echo 0 &gt; /sys/class/graphics/fb0/blank

would result in failures to re-enable the panel. Mode set callback is
called only once during boot in this scenario, while calls to
enable/disable callbacks are balanced afterwards. The driver doesn't
work unless userspace calls modeset before enabling the CRTC/connector.

This patch moves enabling of the DSI host from mode_set into pre_enable
callback, and removes some old hacks where this bridge driver is
directly calling into other bridge driver's callbacks.

pre_enable_prev_first flag is set on the panel's bridge so that panel
drivers will get their prepare function called between DSI host's
pre_enable and enable callbacks, so that they get a chance to
perform panel setup while DSI host is already enabled in command
mode. Otherwise panel's prepare would be called before DSI host
is enabled, and any DSI communication used in prepare callback
would fail.

With all these changes, the enable/disable sequence is now well
balanced, and host's and panel's callbacks are called in proper order
documented in the drm_panel API documentation without needing the old
hacks. (Mainly that panel-&gt;prepare is called when DSI host is ready to
allow the panel driver to send DSI commands and vice versa during
disable.)

Tested on Pinephone Pro. Trace of the callbacks follows.

Before:

[    1.253882] dw-mipi-dsi-rockchip ff960000.dsi: mode_set
[    1.290732] panel-himax-hx8394 ff960000.dsi.0: prepare
[    1.475576] dw-mipi-dsi-rockchip ff960000.dsi: enable
[    1.475593] panel-himax-hx8394 ff960000.dsi.0: enable

echo 2 &gt; /sys/class/graphics/fb0/blank

[   13.722799] panel-himax-hx8394 ff960000.dsi.0: disable
[   13.774502] dw-mipi-dsi-rockchip ff960000.dsi: post_disable
[   13.774526] panel-himax-hx8394 ff960000.dsi.0: unprepare

echo 0 &gt; /sys/class/graphics/fb0/blank

[   17.735796] panel-himax-hx8394 ff960000.dsi.0: prepare
[   17.923522] dw-mipi-dsi-rockchip ff960000.dsi: enable
[   17.923540] panel-himax-hx8394 ff960000.dsi.0: enable
[   17.944330] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO
[   17.944335] panel-himax-hx8394 ff960000.dsi.0: sending command 0xb9 failed: -110
[   17.944340] panel-himax-hx8394 ff960000.dsi.0: Panel init sequence failed: -110

echo 2 &gt; /sys/class/graphics/fb0/blank

[  431.148583] panel-himax-hx8394 ff960000.dsi.0: disable
[  431.169259] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO
[  431.169268] panel-himax-hx8394 ff960000.dsi.0: Failed to enter sleep mode: -110
[  431.169282] dw-mipi-dsi-rockchip ff960000.dsi: post_disable
[  431.169316] panel-himax-hx8394 ff960000.dsi.0: unprepare
[  431.169357] pclk_mipi_dsi0 already disabled

echo 0 &gt; /sys/class/graphics/fb0/blank

[  432.796851] panel-himax-hx8394 ff960000.dsi.0: prepare
[  432.981537] dw-mipi-dsi-rockchip ff960000.dsi: enable
[  432.981568] panel-himax-hx8394 ff960000.dsi.0: enable
[  433.002290] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO
[  433.002299] panel-himax-hx8394 ff960000.dsi.0: sending command 0xb9 failed: -110
[  433.002312] panel-himax-hx8394 ff960000.dsi.0: Panel init sequence failed: -110

-----------------------------------------------------------------------

After:

[    1.248372] dw-mipi-dsi-rockchip ff960000.dsi: mode_set
[    1.248704] dw-mipi-dsi-rockchip ff960000.dsi: pre_enable
[    1.285377] panel-himax-hx8394 ff960000.dsi.0: prepare
[    1.468392] dw-mipi-dsi-rockchip ff960000.dsi: enable
[    1.468421] panel-himax-hx8394 ff960000.dsi.0: enable

echo 2 &gt; /sys/class/graphics/fb0/blank

[   16.210357] panel-himax-hx8394 ff960000.dsi.0: disable
[   16.261315] dw-mipi-dsi-rockchip ff960000.dsi: post_disable
[   16.261339] panel-himax-hx8394 ff960000.dsi.0: unprepare

echo 0 &gt; /sys/class/graphics/fb0/blank

[   19.161453] dw-mipi-dsi-rockchip ff960000.dsi: pre_enable
[   19.197869] panel-himax-hx8394 ff960000.dsi.0: prepare
[   19.382141] dw-mipi-dsi-rockchip ff960000.dsi: enable
[   19.382158] panel-himax-hx8394 ff960000.dsi.0: enable

       (But depends on functionality intorduced in Linux 6.3, so this patch will
        not build on older kernels when applied to older stable branches.)

Fixes: 46fc51546d44 ("drm/bridge/synopsys: Add MIPI DSI host controller bridge")
Signed-off-by: Ondrej Jirman &lt;megi@xff.cz&gt;
Reviewed-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Signed-off-by: Robert Foss &lt;rfoss@kernel.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20230617224915.1923630-1-megi@xff.cz
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm: bridge: dw_hdmi: fix connector access for scdc</title>
<updated>2023-07-23T11:53:35Z</updated>
<author>
<name>Adrián Larumbe</name>
</author>
<published>2023-06-01T12:31:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=552f79aa9e801ed4f74d6b3221af78042ba4f235'/>
<id>urn:sha1:552f79aa9e801ed4f74d6b3221af78042ba4f235</id>
<content type='text'>
[ Upstream commit 98703e4e061fb8715c7613cd227e32cdfd136b23 ]

Commit 5d844091f237 ("drm/scdc-helper: Pimp SCDC debugs") changed the scdc
interface to pick up an i2c adapter from a connector instead. However, in
the case of dw-hdmi, the wrong connector was being used to pass i2c adapter
information, since dw-hdmi's embedded connector structure is only populated
when the bridge attachment callback explicitly asks for it.

drm-meson is handling connector creation, so this won't happen, leading to
a NULL pointer dereference.

Fix it by having scdc functions access dw-hdmi's current connector pointer
instead, which is assigned during the bridge enablement stage.

Fixes: 5d844091f237 ("drm/scdc-helper: Pimp SCDC debugs")
Signed-off-by: Adrián Larumbe &lt;adrian.larumbe@collabora.com&gt;
Reported-by: Lukas F. Hartmann &lt;lukas@mntre.com&gt;
Acked-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
[narmstrong: moved Fixes tag before first S-o-b and added Reported-by tag]
Signed-off-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20230601123153.196867-1-adrian.larumbe@collabora.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/scdc-helper: Pimp SCDC debugs</title>
<updated>2023-04-05T22:30:12Z</updated>
<author>
<name>Ville Syrjälä</name>
</author>
<published>2023-04-03T22:36:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5d844091f2370f01752c3129b147861b9dcd3d98'/>
<id>urn:sha1:5d844091f2370f01752c3129b147861b9dcd3d98</id>
<content type='text'>
Include the device and connector information in the SCDC
debugs. Makes it easier to figure out who did what.

v2: Rely on connector-&gt;ddc (Maxime)

Cc: Andrzej Hajda &lt;andrzej.hajda@intel.com&gt;
Cc: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Cc: Robert Foss &lt;rfoss@kernel.org&gt;
Cc: Laurent Pinchart &lt;Laurent.pinchart@ideasonboard.com&gt;
Cc: Jonas Karlman &lt;jonas@kwiboo.se&gt;
Cc: Jernej Skrabec &lt;jernej.skrabec@gmail.com&gt;
Cc: Thierry Reding &lt;thierry.reding@gmail.com&gt;
Cc: Emma Anholt &lt;emma@anholt.net&gt;
Cc: Maxime Ripard &lt;mripard@kernel.org&gt;
Cc: intel-gfx@lists.freedesktop.org
Cc: linux-tegra@vger.kernel.org
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20230403223652.18848-1-ville.syrjala@linux.intel.com
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Acked-by: Maxime Ripard &lt;maxime@cerno.tech&gt;
Reviewed-by: Andrzej Hajda &lt;andrzej.hajda@intel.com&gt;
Acked-by: Thierry Reding &lt;treding@nvidia.com&gt;
</content>
</entry>
<entry>
<title>drm/bridge: dw-hdmi-i2s-audio: Convert to platform remove callback returning void</title>
<updated>2023-03-20T10:51:55Z</updated>
<author>
<name>Uwe Kleine-König</name>
</author>
<published>2023-03-18T19:08:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ed58ee126c4da81af79ab40b7c6508a7100c7eac'/>
<id>urn:sha1:ed58ee126c4da81af79ab40b7c6508a7100c7eac</id>
<content type='text'>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Signed-off-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20230318190804.234610-18-u.kleine-koenig@pengutronix.de
</content>
</entry>
<entry>
<title>drm/bridge: dw-hdmi-gp-audio: Convert to platform remove callback returning void</title>
<updated>2023-03-20T10:51:54Z</updated>
<author>
<name>Uwe Kleine-König</name>
</author>
<published>2023-03-18T19:08:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2b9efaed4e4045a40944265f99f52b232df3347f'/>
<id>urn:sha1:2b9efaed4e4045a40944265f99f52b232df3347f</id>
<content type='text'>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Signed-off-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20230318190804.234610-17-u.kleine-koenig@pengutronix.de
</content>
</entry>
<entry>
<title>drm/bridge: dw-hdmi-cec: Convert to platform remove callback returning void</title>
<updated>2023-03-20T10:51:54Z</updated>
<author>
<name>Uwe Kleine-König</name>
</author>
<published>2023-03-18T19:08:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8891698273b125e57d0d2b6a91451bac06e968be'/>
<id>urn:sha1:8891698273b125e57d0d2b6a91451bac06e968be</id>
<content type='text'>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Signed-off-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20230318190804.234610-16-u.kleine-koenig@pengutronix.de
</content>
</entry>
<entry>
<title>drm/bridge: dw-hdmi-ahb-audio: Convert to platform remove callback returning void</title>
<updated>2023-03-20T10:51:54Z</updated>
<author>
<name>Uwe Kleine-König</name>
</author>
<published>2023-03-18T19:07:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e85f436824f2e2e067c0a151e954cb403b483234'/>
<id>urn:sha1:e85f436824f2e2e067c0a151e954cb403b483234</id>
<content type='text'>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Signed-off-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20230318190804.234610-15-u.kleine-koenig@pengutronix.de
</content>
</entry>
<entry>
<title>ASoC: hdmi-codec: zero clear HDMI pdata</title>
<updated>2023-01-20T11:51:48Z</updated>
<author>
<name>Kuninori Morimoto</name>
</author>
<published>2023-01-20T06:32:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=54650eb17132a099100264caf59bb2210f65085a'/>
<id>urn:sha1:54650eb17132a099100264caf59bb2210f65085a</id>
<content type='text'>
commit f77a066f4ed307d ("ASoC: hdmi-codec: Allow playback and capture
to be disabled") added new no_i2s_playback/capture.
We need to zero clear HDMI pdata first, otherwise unexpected flag
will be added.

Fixes: f77a066f4ed3 ("ASoC: hdmi-codec: Allow playback and capture to be disabled")
Signed-off-by: Kuninori Morimoto &lt;kuninori.morimoto.gx@renesas.com&gt;
Link: https://lore.kernel.org/r/87k01hlnqj.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm: bridge: dw_hdmi: fix preference of RGB modes over YUV420</title>
<updated>2022-12-01T08:24:04Z</updated>
<author>
<name>Guillaume BRUN</name>
</author>
<published>2022-11-16T14:35:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d3d6b1bf85aefe0ebc0624574b3bb62f0693914c'/>
<id>urn:sha1:d3d6b1bf85aefe0ebc0624574b3bb62f0693914c</id>
<content type='text'>
Cheap monitors sometimes advertise YUV modes they don't really have
(HDMI specification mandates YUV support so even monitors without actual
support will often wrongfully advertise it) which results in YUV matches
and user forum complaints of a red tint to light colour display areas in
common desktop environments.

Moving the default RGB fall-back before YUV selection results in RGB
mode matching in most cases, reducing complaints.

Fixes: 6c3c719936da ("drm/bridge: synopsys: dw-hdmi: add bus format negociation")
Signed-off-by: Guillaume BRUN &lt;the.cheaterman@gmail.com&gt;
Tested-by: Christian Hewitt &lt;christianshewitt@gmail.com&gt;
Reviewed-by: Robert Foss &lt;robert.foss@linaro.org&gt;
Signed-off-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20221116143523.2126-1-the.cheaterman@gmail.com
</content>
</entry>
<entry>
<title>drm: bridge/dw-hdmi-ahb-audio: use strscpy() is more robust and safer</title>
<updated>2022-09-20T08:59:13Z</updated>
<author>
<name>Minghao Chi</name>
</author>
<published>2022-09-19T03:04:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=110ae8a21bbe779a133c1672a1463105c9d50590'/>
<id>urn:sha1:110ae8a21bbe779a133c1672a1463105c9d50590</id>
<content type='text'>
The implementation of strscpy() is more robust and safer.

That's now the recommended way to copy NUL terminated strings.

Reported-by: Zeal Robot &lt;zealci@zte.com.cn&gt;
Signed-off-by: Minghao Chi &lt;chi.minghao@zte.com.cn&gt;
Reviewed-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Signed-off-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220919030401.211331-1-chi.minghao@zte.com.cn
</content>
</entry>
</feed>
