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
> 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
