lkml.org 
[lkml]   [2021]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders
Hi Paul,

Le ven., sept. 24 2021 at 00:51:39 +0200, Paul Boddie
<paul@boddie.org.uk> 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@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.

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


\
 
 \ /
  Last update: 2021-09-24 10:30    [W:0.091 / U:0.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site