From nobody Fri Dec 19 10:41:42 2025 Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 86D0F1B423B; Thu, 9 Oct 2025 19:31:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.11.138.130 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760038270; cv=none; b=F40lfVPeZzFJsNtXwtx/ApG6EJA6iPjRBEzlHR+4+LgQ7vBe5GlHES01SR95m4+73IABL+XKChBeV8hRR2QT6O+7MMwRgYXqa+UjTMphYvP76l8aP4KcDfS6HUI0Ub9LRzASnxFK2G9fDH8UlAJplGYmclxUVpo6AwhESqdaiFI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760038270; c=relaxed/simple; bh=BymKrN1KY0iUPYuubTEHc8AZ1vP3YNisJ6j8DS1jiuY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=gzwfZEQE1w3v6jhnwStDUJloo9xka0gLudl/EllbdTQDxmT/vAsNN6Q2/q5CeHVC+8U5MI0tGAZLcxi25uQ1DjDAwnJhi/smvEsYOVIx1lO8WzTllDv17mzSBmBe+RkqHQrc9ZooyTmOrMEt89aZYWuii8ouQmJ0HBbm7MPuMjw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sntech.de; spf=pass smtp.mailfrom=sntech.de; dkim=pass (2048-bit key) header.d=sntech.de header.i=@sntech.de header.b=Rrpy17nB; arc=none smtp.client-ip=185.11.138.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sntech.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sntech.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sntech.de header.i=@sntech.de header.b="Rrpy17nB" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sntech.de; s=gloria202408; h=Content-Transfer-Encoding:MIME-Version:Message-ID:Date: Subject:Cc:To:From:Reply-To:Content-Type:In-Reply-To:References; bh=tw4U5ow5h6FPqPQ3p8BSDeHqWyCqOyJva3sSK1gq9wU=; b=Rrpy17nByDvTXKcuvVcCQjnAxY f9ogDmNV3bsmRAENNWoDza9zFVKIH67/47SuVb5HpoNwc7vaANXPbKlE4nB3qdZGbF1smYFADF0qI 6r18qMIVLMEvXN2gYVo24ogGgEp4+L98xTY03FAY9WuYazvY/73mxctrf7jfsj8jG3eJvbEzuJl69 CkM9cd++SdDajDgT36qFIaSEi0+mS3ehzX/lc+4unZHys3//PsDXh2GdrF4LXovYFTJiu60ziXn98 KgEbfX+wh5FI6fUYcXKrR9KzJrOkcFyrwtsixT6f8GC05B4kQxd0p1wWMFYIsRxXuCnPXv0QH/lR3 dVCaodVw==; Received: from i53875bdd.versanet.de ([83.135.91.221] helo=localhost.localdomain) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v6wLW-000644-3I; Thu, 09 Oct 2025 21:30:38 +0200 From: Heiko Stuebner To: damon.ding@rock-chips.com, dmitry.baryshkov@oss.qualcomm.com Cc: m.szyprowski@samsung.com, andrzej.hajda@intel.com, neil.armstrong@linaro.org, rfoss@kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-rockchip@lists.infradead.org, Heiko Stuebner Subject: [PATCH] drm/bridge: analogix_dp: Fix connector status detection for bridges Date: Thu, 9 Oct 2025 21:30:28 +0200 Message-ID: <20251009193028.4952-1-heiko@sntech.de> X-Mailer: git-send-email 2.47.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Right now if there is a next bridge attached to the analogix-dp controller the driver always assumes this bridge is connected to something, but this is of course not always true, as that bridge could also be a hotpluggable dp port for example. On the other hand, as stated in commit cb640b2ca546 ("drm/bridge: display- connector: don't set OP_DETECT for DisplayPorts"), "Detecting the monitor for DisplayPort targets is more complicated than just reading the HPD pin level" and we should be "letting the actual DP driver perform detection." So use drm_bridge_detect() to detect the next bridge's state but ignore that bridge if the analogix-dp is handling the hpd-gpio. Signed-off-by: Heiko Stuebner --- As this patch stands, it would go on top of v6 of Damon's bridge-connector work, but could very well be also integrated into one of the changes there. I don't know yet if my ordering and/or reasoning is the correct one or if a better handling could be done, but with that change I do get a nice hotplug behaviour on my rk3588-tiger-dp-carrier board, where the Analogix-DP ends in a full size DP port. drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/g= pu/drm/bridge/analogix/analogix_dp_core.c index c04b5829712b..cdc56e83b576 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c @@ -983,8 +983,12 @@ analogix_dp_bridge_detect(struct drm_bridge *bridge, s= truct drm_connector *conne struct analogix_dp_device *dp =3D to_dp(bridge); enum drm_connector_status status =3D connector_status_disconnected; =20 - if (dp->plat_data->next_bridge) - return connector_status_connected; + /* + * An optional next bridge should be in charge of detection the + * connection status, except if we manage a actual hpd gpio. + */ + if (dp->plat_data->next_bridge && !dp->hpd_gpiod) + return drm_bridge_detect(dp->plat_data->next_bridge, connector); =20 if (!analogix_dp_detect_hpd(dp)) status =3D connector_status_connected; --=20 2.47.2