From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 Message-ID: <09ec241b-113a-6cd4-ef4f-7010d1829bad@basealt.ru> Date: Wed, 15 Jul 2026 11:45:49 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: Daniil Gnusarev References: <20260714061503.170801-1-gnusarevda@basealt.ru> <20260714061503.170801-2-gnusarevda@basealt.ru> From: Vasiliy Kovalev In-Reply-To: <20260714061503.170801-2-gnusarevda@basealt.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: ALT Linux kernel packages development Subject: Re: [d-kernel] [PATCH 1/1] drm: rockchip: dwhdmiqp-rockchip: attach next bridge to the HDMI bridge X-BeenThere: devel-kernel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux kernel packages development List-Id: ALT Linux kernel packages development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2026 08:45:56 -0000 Archived-At: List-Archive: List-Post: Добрый день, On 7/14/26 09:15, Daniil Gnusarev wrote: > For embedded systems, additional bridges may be connected after > the HDMI bridge being created. To ensure full functionality, they > must be added to the DRM bridge chain. > > Signed-off-by: Daniil Gnusarev > --- > .../gpu/drm/rockchip/dw_hdmi_qp-rockchip.c | 22 +++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c > index 409f1a1e82a061..9485d85a16f35c 100644 > --- a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c > +++ b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c > @@ -430,6 +430,8 @@ static int dw_hdmi_qp_rockchip_bind(struct device *dev, struct device *master, > struct drm_connector *connector; > struct drm_encoder *encoder; > struct rockchip_hdmi_qp *hdmi; > + struct drm_bridge *hdmi_bridge; > + struct drm_bridge *next_bridge; > struct resource *res; > struct clk_bulk_data *clks; > int ret, irq, i; > @@ -441,6 +443,11 @@ static int dw_hdmi_qp_rockchip_bind(struct device *dev, struct device *master, > if (!hdmi) > return -ENOMEM; > > + next_bridge = NULL; > + ret = drm_of_find_panel_or_bridge(pdev->dev.of_node, 1, 0, NULL, &next_bridge); > + if (ret && ret != -ENODEV) > + return ret; > + > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > if (!res) > return -ENODEV; > @@ -556,6 +563,21 @@ static int dw_hdmi_qp_rockchip_bind(struct device *dev, struct device *master, > return ret; > } > > + if (next_bridge) { > + hdmi_bridge = drm_bridge_chain_get_last_bridge(encoder); > + if (hdmi_bridge) > + ret = drm_bridge_attach(encoder, next_bridge, hdmi_bridge, > + DRM_BRIDGE_ATTACH_NO_CONNECTOR); > + else > + ret = -ENODEV; > + if (hdmi_bridge) > + drm_bridge_put(hdmi_bridge); > + if (ret) { > + dev_err(hdmi->dev, "failed to attach next bridge: %d\n", ret); > + return ret; > + } > + } > + > connector = drm_bridge_connector_init(drm, encoder); > if (IS_ERR(connector)) { > ret = PTR_ERR(connector); Патч трогает только rockchip-часть (dw_hdmi_qp-rockchip.c), но по сути это обход того, что должна делать библиотека моста dw-hdmi-qp.c. Оба файла активно сопровождаются - по git log правки свежие: $ git log --format="%ad" -- ./drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c | head -5 Sat Jul 4 11:12:02 2026 +0200 Tue Jun 9 14:44:04 2026 +0200 Tue Jun 9 14:44:03 2026 +0200 Thu Apr 23 11:17:24 2026 +0200 Tue Mar 10 00:44:34 2026 +0200 $ git log --format="%ad" -- ./drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | head -5 Fri Jun 19 14:24:39 2026 +0200 Tue Jun 9 14:44:02 2026 +0200 Wed May 20 16:43:39 2026 +0200 Mon Apr 27 09:02:57 2026 +0200 Thu Feb 5 10:33:06 2026 +0100 Так что имеет смысл предложить это напрямую в dri-devel + linux-rockchip, а не заводить только в ALT. По самому патчу, в mainline dw_hdmi_qp_bind() подключает только свой мост и на этом останавливается: (https://elixir.bootlin.com/linux/v7.2-rc3/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c#L1369) ret = drm_bridge_attach(encoder, &hdmi->bridge, NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR); Колбэка .attach в dw_hdmi_qp_bridge_funcs нет. При этом в обычном dw-hdmi он есть и делает подключение следующего моста сам: (https://elixir.bootlin.com/linux/v7.2-rc3/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2907) static int dw_hdmi_bridge_attach(struct drm_bridge *bridge, struct drm_encoder *encoder, enum drm_bridge_attach_flags flags) { struct dw_hdmi *hdmi = bridge->driver_private; /* DRM_BRIDGE_ATTACH_NO_CONNECTOR requires a remote-endpoint to the next bridge */ if (WARN_ON((flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) && !hdmi->plat_data->output_port)) return -EINVAL; if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) { struct device_node *remote __free(device_node) = of_graph_get_remote_node(hdmi->dev->of_node, hdmi->plat_data->output_port, -1); if (!remote) return -ENODEV; struct drm_bridge *next_bridge __free(drm_bridge_put) = of_drm_find_and_get_bridge(remote); if (!next_bridge) return -EPROBE_DEFER; return drm_bridge_attach(encoder, next_bridge, bridge, flags); } return dw_hdmi_connector_create(hdmi); } Возможно логику лучше держать в самой библиотеке моста (.attach + output_port в plat_data), а не в rockchip-части через drm_bridge_chain_get_last_bridge() - тогда там останется одна строка и это же решение должно покрыть и другие чипы. Плюс drm_of_find_panel_or_bridge(), который вызывается в патче, сам помечен как deprecated в комментарии https://elixir.bootlin.com/linux/v7.2-rc3/source/drivers/gpu/drm/drm_of.c#L234: * This function is deprecated and should not be used in new drivers. Use * of_drm_get_bridge_by_endpoint() instead when not looking for a panel, or * devm_drm_of_get_bridge() otherwise. Для dw-hdmi такой подход в своё время принимали: https://lore.kernel.org/all/20200526011505.31884-24-laurent.pinchart+renesas@ideasonboard.com/ но как правильнее, лучше спросить у мейнтейнеров. В отличие от Байкал, патчи к которому апстрим не принимает в принципе (https://lore.kernel.org/all/20260227072726.1142944-2-andriy.shevchenko@linux.intel.com/) в этой ситуации форк не обязателен - всё делается через апстрим. После принятия в mainline можно попробовать бэкпортировать в ALT 6.18 (в stable апстрима такое не возьмут - это не фикс безопасности), хотя маловероятно: зависит от расхождения кода и от того, кто в ALT это потащит. -- Vasiliy