kernel/linux.git/drivers/gpu/drm/bridge, branch v6.6.36

drm/bridge/panel: Fix runtime warning on panel bridge release

2024-06-21T12:38:33+00:00

[ Upstream commit ce62600c4dbee8d43b02277669dd91785a9b81d9 ] Device managed panel bridge wrappers are created by calling to drm_panel_bridge_add_typed() and registering a release handler for clean-up when the device gets unbound. Since the memory for this bridge is also managed and linked to the panel device, the release function should not try to free that memory. Moreover, the call to devm_kfree() inside drm_panel_bridge_remove() will fail in this case and emit a warning because the panel bridge resource is no longer on the device resources list (it has been removed from there before the call to release handlers). Fixes: 67022227ffb1 ("drm/bridge: Add a devm_ allocator for panel bridge.") Signed-off-by: Adam Miotk Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20240610102739.139852-1-adam.miotk@arm.com Signed-off-by: Sasha Levin

Revert "drm/bridge: ti-sn65dsi83: Fix enable error path"

2024-06-12T09:12:43+00:00

[ Upstream commit ad81feb5b6f1f5461641706376dcf7a9914ed2e7 ] This reverts commit 8a91b29f1f50ce7742cdbe5cf11d17f128511f3f. The regulator_disable() added by the original commit solves one kind of regulator imbalance but adds another one as it allows the regulator to be disabled one more time than it is enabled in the following scenario: 1. Start video pipeline -> sn65dsi83_atomic_pre_enable -> regulator_enable 2. PLL lock fails -> regulator_disable 3. Stop video pipeline -> sn65dsi83_atomic_disable -> regulator_disable The reason is clear from the code flow, which looks like this (after removing unrelated code): static void sn65dsi83_atomic_pre_enable() { regulator_enable(ctx->vcc); if (PLL failed locking) { regulator_disable(ctx->vcc); <---- added by patch being reverted return; } } static void sn65dsi83_atomic_disable() { regulator_disable(ctx->vcc); } The use case for introducing the additional regulator_disable() was removing the module for debugging (see link below for the discussion). If the module is removed after a .atomic_pre_enable, i.e. with an active pipeline from the DRM point of view, .atomic_disable is not called and thus the regulator would not be disabled. According to the discussion however there is no actual use case for removing the module with an active pipeline, except for debugging/development. On the other hand, the occurrence of a PLL lock failure is possible due to any physical reason (e.g. a temporary hardware failure for electrical reasons) so handling it gracefully should be supported. As there is no way for .atomic[_pre]_enable to report an error to the core, the only clean way to support it is calling regulator_disabled() only in .atomic_disable, unconditionally, as it was before. Link: https://lore.kernel.org/all/15244220.uLZWGnKmhe@steina-w/ Fixes: 8a91b29f1f50 ("drm/bridge: ti-sn65dsi83: Fix enable error path") Reviewed-by: Alexander Stein Signed-off-by: Luca Ceresoli Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240426122259.46808-1-luca.ceresoli@bootlin.com (cherry picked from commit 2940ee03b23281071620dda1d790cd644dabd394) Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin

drm/bridge: tc358775: fix support for jeida-18 and jeida-24

2024-06-12T09:12:40+00:00

[ Upstream commit 30ea09a182cb37c4921b9d477ed18107befe6d78 ] The bridge always uses 24bpp internally. Therefore, for jeida-18 mapping we need to discard the lowest two bits for each channel and thus starting with LV_[RGB]2. jeida-24 has the same mapping but uses four lanes instead of three, with the forth pair transmitting the lowest two bits of each channel. Thus, the mapping between jeida-18 and jeida-24 is actually the same, except that one channel is turned off (by selecting the RGB666 format in VPCTRL). While at it, remove the bogus comment about the hardware default because the default is overwritten in any case. Tested with a jeida-18 display (Evervision VGG644804). Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver") Signed-off-by: Michael Walle Signed-off-by: Tony Lindgren Reviewed-by: Robert Foss Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240225062008.33191-5-tony@atomide.com Signed-off-by: Sasha Levin

drm/bridge: anx7625: Update audio status while detecting

2024-06-12T09:12:04+00:00

[ Upstream commit a665b4e60369867cddf50f37f16169a3e2f434ad ] Previously, the audio status was not updated during detection, leading to a persistent audio despite hot plugging events. To resolve this issue, update the audio status during detection. Fixes: 566fef1226c1 ("drm/bridge: anx7625: add HDMI audio function") Signed-off-by: Hsin-Te Yuan Reviewed-by: Robert Foss Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240416-anx7625-v3-1-f916ae31bdd7@chromium.org Signed-off-by: Sasha Levin

drm/bridge: dpc3433: Don't log an error when DSI host can't be found

2024-06-12T09:12:04+00:00

[ Upstream commit 24f4f575214de776539d346b99b8717bffa8ebba ] Given that failing to find a DSI host causes the driver to defer probe, make use of dev_err_probe() to log the reason. This makes the defer probe reason available and avoids alerting userspace about something that is not necessarily an error. Also move the "failed to attach" error message so that it's only printed when the devm_mipi_dsi_attach() call fails. Fixes: 6352cd451ddb ("drm: bridge: Add TI DLPC3433 DSI to DMD bridge") Suggested-by: AngeloGioacchino Del Regno Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Laurent Pinchart Signed-off-by: Nícolas F. R. A. Prado Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-7-619a28148e5c@collabora.com Signed-off-by: Sasha Levin

drm/bridge: tc358775: Don't log an error when DSI host can't be found

2024-06-12T09:12:04+00:00

[ Upstream commit 272377aa0e3dddeec3f568c8bb9d12c7a79d8ef5 ] Given that failing to find a DSI host causes the driver to defer probe, make use of dev_err_probe() to log the reason. This makes the defer probe reason available and avoids alerting userspace about something that is not necessarily an error. Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver") Suggested-by: AngeloGioacchino Del Regno Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Laurent Pinchart Signed-off-by: Nícolas F. R. A. Prado Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-6-619a28148e5c@collabora.com Signed-off-by: Sasha Levin

drm/bridge: lt9611uxc: Don't log an error when DSI host can't be found

2024-06-12T09:12:03+00:00

[ Upstream commit 6d9e877cde7e9b516a9a99751b8222c87557436d ] Given that failing to find a DSI host causes the driver to defer probe, make use of dev_err_probe() to log the reason. This makes the defer probe reason available and avoids alerting userspace about something that is not necessarily an error. Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge") Suggested-by: AngeloGioacchino Del Regno Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Laurent Pinchart Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: Dmitry Baryshkov Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-5-619a28148e5c@collabora.com Signed-off-by: Sasha Levin

drm/bridge: lt9611: Don't log an error when DSI host can't be found

2024-06-12T09:12:03+00:00

[ Upstream commit cd0a2c6a081ff67007323725b9ff07d9934b1ed8 ] Given that failing to find a DSI host causes the driver to defer probe, make use of dev_err_probe() to log the reason. This makes the defer probe reason available and avoids alerting userspace about something that is not necessarily an error. Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge") Suggested-by: AngeloGioacchino Del Regno Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Laurent Pinchart Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: Dmitry Baryshkov Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-4-619a28148e5c@collabora.com Signed-off-by: Sasha Levin

drm/bridge: lt8912b: Don't log an error when DSI host can't be found

2024-06-12T09:12:03+00:00

[ Upstream commit b3b4695ff47c4964d4ccb930890c9ffd8e455e20 ] Given that failing to find a DSI host causes the driver to defer probe, make use of dev_err_probe() to log the reason. This makes the defer probe reason available and avoids alerting userspace about something that is not necessarily an error. Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Suggested-by: AngeloGioacchino Del Regno Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Laurent Pinchart Signed-off-by: Nícolas F. R. A. Prado Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-3-619a28148e5c@collabora.com Signed-off-by: Sasha Levin

drm/bridge: icn6211: Don't log an error when DSI host can't be found

2024-06-12T09:12:03+00:00

[ Upstream commit 275fafe58faa7fdb10fa245412696ecef676aac5 ] Given that failing to find a DSI host causes the driver to defer probe, make use of dev_err_probe() to log the reason. This makes the defer probe reason available and avoids alerting userspace about something that is not necessarily an error. Fixes: 8dde6f7452a1 ("drm: bridge: icn6211: Add I2C configuration support") Suggested-by: AngeloGioacchino Del Regno Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Laurent Pinchart Signed-off-by: Nícolas F. R. A. Prado Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-2-619a28148e5c@collabora.com Signed-off-by: Sasha Levin