From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx.denx.de (mx.denx.de [89.58.32.78]) (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 E65311EBA1C for ; Tue, 7 Jan 2025 11:25:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=89.58.32.78 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736249108; cv=none; b=PfUeFTsPsrx6DVj1uFtJKQH4qndX1mOZfFMI1H55bRqwr809XKlL8dnmWmeh1wwxi1+HbDyXHefBnIKDFck3N1SLerRVpkKZTJ70IqIXlM11Rkp/g3Bdc4QrEsVi/PD9W9iQJAkt5SU1NU5c7f9MczLUTI0FaArbS1wA2l2BBQA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736249108; c=relaxed/simple; bh=q/cENcLO/Vvq8OXJhVTUQW6YZgU6qWCviNrMQ44MFR4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=uJHmAk7s75mEFKj9G1NpLcNCCmExyn/85FQIpWQVcWCBcYPkdzmjqHHih4KlCWDVVY5HgXWLulAYjETxVL6R/G7jP+PhTKzKZrPO3r19rd6jurjav3aO9jDCIuaxfBEEKLYi8p/eSmpANKgdxhmDA5Nra1GvqjBoUGTcp0DN4Ik= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=denx.de; spf=pass smtp.mailfrom=denx.de; dkim=pass (2048-bit key) header.d=denx.de header.i=@denx.de header.b=RTRWgK8M; arc=none smtp.client-ip=89.58.32.78 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=denx.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=denx.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=denx.de header.i=@denx.de header.b="RTRWgK8M" Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 1CF61101ECB24; Tue, 7 Jan 2025 12:24:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=mx-20241105; t=1736249096; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=r2ff0HaCcjmmj9KnhUdBh5w7Yu5An6vyL+EnPFzNUxM=; b=RTRWgK8MQwcxk8DstoWOZvN2/3kvry5mG8JD2y5yOxA82ctZZp6KWEPNEDoXWsNkRCxPK9 kK1yUy0mcKomy/pLdtu34wp/qBQLj06fK3+hhFedORfXEvPglXKnhk3wDBR9/1bIrj7ArB OI2Gi5edckf4vOG2KjWaWu+P6f9vIbMuVDg6/v6mglbrQWFw0T4QNNTZUK1gZomy83NqsC ftDYnHdWjlAcmxOpSFRZzEVd6ch+K6IalzRuHt3hy9ZEradm/uQkophOkQ8lIk4uhiWbKg /ar4bJIYqR0nefQKmR4kFGQxyau7P4yEHom8Hnuh+rYPqpxWzm2L0EcVpS/9CA== Message-ID: Date: Tue, 7 Jan 2025 12:08:12 +0100 Precedence: bulk X-Mailing-List: imx@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/4] drm/bridge: imx8mp-hdmi-tx: switch to bridge DRM_BRIDGE_ATTACH_NO_CONNECTOR To: Liu Ying , dri-devel@lists.freedesktop.org Cc: Andrzej Hajda , David Airlie , Fabio Estevam , Jernej Skrabec , Jonas Karlman , Laurent Pinchart , Maarten Lankhorst , Maxime Ripard , Neil Armstrong , Pengutronix Kernel Team , Robert Foss , Sascha Hauer , Shawn Guo , Simona Vetter , Stefan Agner , Thomas Zimmermann , imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org References: <20250105190659.99941-1-marex@denx.de> <20250105190659.99941-2-marex@denx.de> <0b1c9897-2769-4ca0-9927-ac930b4c634b@nxp.com> Content-Language: en-US From: Marek Vasut In-Reply-To: <0b1c9897-2769-4ca0-9927-ac930b4c634b@nxp.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Last-TLS-Session-Version: TLSv1.3 On 1/7/25 6:38 AM, Liu Ying wrote: > On 01/06/2025, Marek Vasut wrote: >> The dw-hdmi output_port is set to 1 in order to look for a connector >> next bridge in order to get DRM_BRIDGE_ATTACH_NO_CONNECTOR working. >> The output_port set to 1 makes the DW HDMI driver core look up the >> next bridge in DT, where the next bridge is often the hdmi-connector . >> >> Similar to 0af5e0b41110 ("drm/meson: encoder_hdmi: switch to bridge DRM_BRIDGE_ATTACH_NO_CONNECTOR") >> >> Note that looking at the upstream arch/arm64/boot/dts/freescale/imx8mp*dts , >> the oldest commit which adds HDMI support is commit: >> >> 3e67a1ddd56d ("arm64: dts: imx8mp: Enable HDMI on TQMa8MPxL/MBa8MPxL") >> >> That already contains the HDMI connector node. Most follow up additions >> of HDMI support to another devices has been a variation of the same commit, >> including connector node, which is the proper way of eanbling HDMI on the >> i.MX8MP. >> >> The rest should be covered by output_port_optional which should make systems >> with DTs without HDMI connector node work, but such DTs should be updated and >> the HDMI connector node should be added. >> >> Signed-off-by: Marek Vasut >> --- >> Cc: Andrzej Hajda >> Cc: David Airlie >> Cc: Fabio Estevam >> Cc: Jernej Skrabec >> Cc: Jonas Karlman >> Cc: Laurent Pinchart >> Cc: Liu Ying >> Cc: Maarten Lankhorst >> Cc: Maxime Ripard >> Cc: Neil Armstrong >> Cc: Pengutronix Kernel Team >> Cc: Robert Foss >> Cc: Sascha Hauer >> Cc: Shawn Guo >> Cc: Simona Vetter >> Cc: Stefan Agner >> Cc: Thomas Zimmermann >> Cc: dri-devel@lists.freedesktop.org >> Cc: imx@lists.linux.dev >> Cc: linux-arm-kernel@lists.infradead.org >> --- >> V2: No change >> V3: - Update commit message >> - Move select DRM_DISPLAY_CONNECTOR to DRM_IMX8MP_DW_HDMI_BRIDGE >> - Enable output_port_optional >> V4: - Remove select DRM_DISPLAY_CONNECTOR >> --- >> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c >> index 1e7a789ec2890..3d63200e468bf 100644 >> --- a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c >> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c >> @@ -101,6 +101,8 @@ static int imx8mp_dw_hdmi_probe(struct platform_device *pdev) >> plat_data->phy_name = "SAMSUNG HDMI TX PHY"; >> plat_data->priv_data = hdmi; >> plat_data->phy_force_vendor = true; >> + plat_data->output_port = 1; > > How would you keep the behaviour of the connector after adding > DRM_BRIDGE_ATTACH_NO_CONNECTOR in display controller driver? > dw_hdmi_connector_create() implements CEC support at least. This was pointed > out in v2 and v3 comments. > > https://lore.kernel.org/all/vvsj6ri2ke25nzocbq736yv7rphzma6pn3yk2uh7iu43zfe2sa@2fwye4k4w6he/ As far as I understand it, the CEC is being worked on separately already ?