From: Paul Boddie <paul@boddie.org.uk>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Paul Cercueil <paul@crapouillou.net>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
linux-mips <linux-mips@vger.kernel.org>,
list@opendingux.net, dri-devel <dri-devel@lists.freedesktop.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders
Date: Fri, 24 Sep 2021 00:51:39 +0200 [thread overview]
Message-ID: <4366739.KZ8Jxz7LyS@jason> (raw)
In-Reply-To: <B7B431EC-BC73-4B39-A03C-003347D8C239@goldelico.com>
On Thursday, 23 September 2021 22:23:28 CEST H. Nikolaus Schaller wrote:
>
> > Am 23.09.2021 um 21:39 schrieb Paul Cercueil <paul@crapouillou.net>:
> >
> > 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
next prev parent reply other threads:[~2021-09-23 22:57 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-22 20:55 [PATCH v3 0/6] drm/ingenic: Various improvements v3 Paul Cercueil
2021-09-22 20:55 ` [PATCH v3 1/6] drm/ingenic: Simplify code by using hwdescs array Paul Cercueil
2021-09-22 20:55 ` [PATCH v3 2/6] drm/ingenic: Add support for private objects Paul Cercueil
2021-09-22 20:55 ` [PATCH v3 3/6] drm/ingenic: Move IPU scale settings to private state Paul Cercueil
2021-09-22 20:55 ` [PATCH v3 4/6] drm/ingenic: Set DMA descriptor chain register when starting CRTC Paul Cercueil
2021-09-22 20:55 ` [PATCH v3 5/6] drm/ingenic: Upload palette before frame Paul Cercueil
2021-09-22 20:55 ` [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders Paul Cercueil
2021-09-23 5:52 ` H. Nikolaus Schaller
2021-09-23 8:49 ` Paul Cercueil
2021-09-23 9:19 ` H. Nikolaus Schaller
2021-09-23 9:27 ` Laurent Pinchart
2021-09-23 9:55 ` H. Nikolaus Schaller
2021-09-23 10:03 ` Laurent Pinchart
2021-09-23 11:41 ` H. Nikolaus Schaller
2021-09-23 11:56 ` H. Nikolaus Schaller
2021-09-23 13:30 ` Paul Cercueil
2021-09-23 18:52 ` H. Nikolaus Schaller
2021-09-23 19:39 ` Paul Cercueil
2021-09-23 20:23 ` H. Nikolaus Schaller
2021-09-23 22:51 ` Paul Boddie [this message]
2021-09-24 8:29 ` Paul Cercueil
2021-09-25 15:55 ` Paul Boddie
2021-09-25 19:08 ` Paul Cercueil
2021-09-25 19:26 ` H. Nikolaus Schaller
2021-09-25 19:39 ` Paul Cercueil
2021-09-27 16:18 ` H. Nikolaus Schaller
2021-09-24 11:40 ` H. Nikolaus Schaller
2021-09-23 9:23 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4366739.KZ8Jxz7LyS@jason \
--to=paul@boddie.org.uk \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hns@goldelico.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=list@opendingux.net \
--cc=paul@crapouillou.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.