Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders

From: Paul Cercueil
Date: Fri Sep 24 2021 - 04:29:25 EST

Hi Paul,

Le ven., sept. 24 2021 at 00:51:39 +0200, Paul Boddie <paul@xxxxxxxxxxxxx> a écrit :
On Thursday, 23 September 2021 22:23:28 CEST H. Nikolaus Schaller wrote:

> Am 23.09.2021 um 21:39 schrieb Paul Cercueil <paul@xxxxxxxxxxxxxxx>:
> 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

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.

The bridge's type is set in hdmi-connector, from DTS. The 'type = "a"' will result in the bridge's .type to be set to DRM_MODE_CONNECTOR_HDMIA.

And this causes drm_bridge_connector_init to fail because it tests the bridge

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/


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

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.

Could you paste the result of "modetest -a -c -p" somewhere maybe?

If you have info about the CRTCs, encoders, connectors and EDID info, then I would assume it is very close to working fine.

For your "no framebuffer" issue, keep in mind that CONFIG_FB and CONFIG_FRAMEBUFFER_CONSOLE are now disabled by default.

If that doesn't fix anything, that probably means that one .atomic_check() fails, so it would be a good place to start debugging.