Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp1010725pxb; Thu, 23 Sep 2021 15:58:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzSQDrn6L1JttP/LQaz0xPU8kIBQuHueGkHTK7zW8Tfg1whuHz2Y00hd/vrracBxEX/TAMg X-Received: by 2002:a6b:f301:: with SMTP id m1mr6064624ioh.3.1632437902783; Thu, 23 Sep 2021 15:58:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632437902; cv=none; d=google.com; s=arc-20160816; b=Z8H3svbZyiaMY06ZbQHWFBddSf8Tu30uQlZzCifk+DDG9K1BQ7NJZVdljrPNueYoaQ SIBX6NBFTmkJCukTo5DIJlQrsV32eZdgQQF8HEdVOdHToPPvVKsU8k/a/6jEs7NPHAAj 8WzAoiaXszlvnyC5QAhMGf88E1YdVwvQ9SQTBSVWukX6Gd+Nmi/yy0PMSE+j7QjGfEoC 7zJWYhJHSiiO5LvmL5/fq6v4rUq5brCW+hn5umBo6l2DFgjviMDfhE5RanfZK3/dfsD8 PJhtQBDtD+Ydffrhdt97vceDtqHWP1XpeB+Cht0xtn4tOBw9C4gpM0AzDhWv0fXHgZlN lKuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=e4PZqbATcpFKvMSWvz2SaHStw0CXunL88V36uVDDWCY=; b=W5y3j0LCF51tGm8JIV5DhAm8GMGwYO+CTadHbUxolcyd57ksZUpNBfp9Y9qOie/UEA 7nTCikf39m3+j4Oy9a3xUUEedgNKzyHjoKJ5jBBtXVc4OmbuaDpilMIdWErC4lS7aKwJ k48heGlzBtAFRuX8xSWHSmANUMJrS15nS+XPkfjqi3p1GZHb0moQk+LbZe97C6AzwYYX 7YCPd26j94T0a+0O0Ai70kQ3kAB4Bg+emtNgikGyZr6sRJ8kp2oGaVZSsncQb8JlKr3u /IoHRgEedxxWuOg/gnhkPfjkf6RswlAZ214X2dW3+XyF/oh8ejNA9FJcPH/3aamSd9C6 MoDQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@boddie.org.uk header.s=dkim header.b=OFTg1Ac2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o12si8460768ilj.142.2021.09.23.15.58.11; Thu, 23 Sep 2021 15:58:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@boddie.org.uk header.s=dkim header.b=OFTg1Ac2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243505AbhIWW6z (ORCPT + 99 others); Thu, 23 Sep 2021 18:58:55 -0400 Received: from smtp2.de.opalstack.com ([139.162.136.213]:48228 "EHLO smtp2.de.opalstack.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236363AbhIWW6y (ORCPT ); Thu, 23 Sep 2021 18:58:54 -0400 X-Greylist: delayed 334 seconds by postgrey-1.27 at vger.kernel.org; Thu, 23 Sep 2021 18:58:54 EDT Received: from jason.localnet (host-37-191-188-128.lynet.no [37.191.188.128]) by smtp2.de.opalstack.com (Postfix) with ESMTPSA id A004E129C6B; Thu, 23 Sep 2021 22:51:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boddie.org.uk; s=dkim; t=1632437506; 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=e4PZqbATcpFKvMSWvz2SaHStw0CXunL88V36uVDDWCY=; b=OFTg1Ac2UZUlbgTsGydnHAY5uSE+xsua3v4Eu4kFF4WcjRbWYKciC02F+5A+g7dE2bNapz Hao6cKqlHFp5+P6PBp3gBtnU8Bsnz0r48kzs6hX4DhqnbiPATRl3LslnOK09sxVH7NM5il MaJLXl9igFrtG5dr0huIBpR37G8bPC0= From: Paul Boddie To: "H. Nikolaus Schaller" Cc: Paul Cercueil , Laurent Pinchart , David Airlie , Daniel Vetter , linux-mips , list@opendingux.net, dri-devel , linux-kernel Subject: Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders Date: Fri, 24 Sep 2021 00:51:39 +0200 Message-ID: <4366739.KZ8Jxz7LyS@jason> In-Reply-To: References: <20210922205555.496871-1-paul@crapouillou.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-0.28 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, 23 September 2021 22:23:28 CEST H. Nikolaus Schaller wrote: > > > Am 23.09.2021 um 21:39 schrieb Paul Cercueil : > > > > Start by wiring things properly, like in my previously linked DTS, and > > *test*. If it fails, tell us where it fails. > > Well, I tell where drm_bridge_attach fails with > DRM_BRIDGE_ATTACH_NO_CONNECTOR... I tried to piece together this entire discussion from the mailing list archives, but there appear to be two approaches that "work", in that they activate the LCD controller with the HDMI peripheral: 1. Nikolaus's approach, which involves getting the Synopsys driver to create a connector and then avoiding the call to drm_bridge_connector_init in the Ingenic DRM driver. 2. My approach, which just involves changing the Synopsys driver to set the bridge type in dw_hdmi_probe like this: hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA; Otherwise, I don't see how the bridge's (struct drm_bridge) type will be set. And this causes drm_bridge_connector_init to fail because it tests the bridge type. Now, I just reintroduced the HDMI connector to the device tree as follows: hdmi_connector { compatible = "hdmi-connector"; label = "hdmi"; type = "a"; port { hdmi_connector_in: endpoint { remote-endpoint = <&dw_hdmi_out>; }; }; }; And then I added a second port to the HDMI peripheral node as follows: port@1 { reg = <1>; dw_hdmi_out: endpoint { remote-endpoint = <&hdmi_connector_in>; }; }; And I removed any of the above hacks. What I observe, apart from an inactive LCD controller (and ingenic-drm driver), is the following in /sys/devices/ platform/10180000.hdmi/: consumer:platform:13050000.lcdc0 consumer:platform:hdmi_connector Maybe I don't understand the significance of "consumer" here, but the LCD controller and the HDMI connector obviously have rather different roles. Then again, the device tree is defining bidirectional relationships, so maybe this is how they manifest themselves. > > Because your "it doesn't work" arguments have zero weight otherwise. > > I hope I still can find it. So I can't promise anything. > We have had it complete in DTS and added code to parse it. > It may have been wiped out by cleaning up patch series during rebase. I suppose the question is whether this is actually handled already. I would have thought that either the DRM framework would be able to identify such relationships in a generic way or that the Synopsys driver would need to do so. This might actually be happening, given that the sysfs entries are there, but I might also imagine that something extra would be required to set the bridge type. I did start writing some code to look up a remote endpoint for the second port, find the connector type, and then set it, but it was probably after midnight on that occasion as well. Short-circuiting this little dance and setting the bridge type indicated that this might ultimately be the right approach, but it would probably also mean introducing a point of specialisation to the Synopsys driver so that device-specific drivers can define a function to set the connector type. Otherwise, I can't see the Synopsys driver working for devices like the JZ4780, but then again, it seems that all the other devices seem to incorporate the Synopsys functionality in a different way and do not need to deal with connectors at all. > > If I can find some time this weekend I will test it myself. > > You may be faster than me. So, when I wrote about approaches that "work", I can seemingly get the LCD controller and HDMI peripheral registers set up to match a non-Linux environment where I can demonstrate a functioning display, and yet I don't get a valid signal in the Linux environment. Nikolaus can actually get HDMI output, but there may be other factors introduced by the Linux environment that frustrate success for me, whereas my non-Linux environment is much simpler and can reliably reproduce a successful result. For me, running modetest yields plenty of information about encoders, connectors (and the supported modes via the EDID, thanks to my HDMI-A hack), CRTCs, and planes. But no framebuffers are reported. Paul