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
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.
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
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.
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.
Cheers,
-Paul
