Hi,

On 16/10/2021 00:07, Martin Blumenstingl wrote:

Hi Neil,

On Fri, Oct 15, 2021 at 4:11 PM Neil Armstrong [off-list ref] wrote:

quoted

This implements the necessary change to no more use the embedded
connector in dw-hdmi and use the dedicated bridge connector driver
by passing DRM_BRIDGE_ATTACH_NO_CONNECTOR to the bridge attach call.

The necessary connector properties are added to handle the same
functionalities as the embedded dw-hdmi connector, i.e. the HDR
metadata, the CEC notifier & other flags.

The dw-hdmi output_port is set to 1 in order to look for a connector
next bridge in order to get DRM_BRIDGE_ATTACH_NO_CONNECTOR working.

Signed-off-by: Neil Armstrong <redacted>
Acked-by: Sam Ravnborg <redacted>

another great piece which helps a lot with HDMI support for the 32-bit SoCs!
I have one question below - but regardless of the answer there this gets my:
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>

[...]

quoted

+       pdev = of_find_device_by_node(remote);

I am wondering if we should use something like:
    encoder_hdmi->cec_notifier_pdev

quoted

+       if (pdev) {
+               struct cec_connector_info conn_info;
+               struct cec_notifier *notifier;
+
+               cec_fill_conn_info_from_drm(&conn_info, meson_encoder_hdmi->connector);
+
+               notifier = cec_notifier_conn_register(&pdev->dev, NULL, &conn_info);
+               if (!notifier)
+                       return -ENOMEM;
+
+               meson_encoder_hdmi->cec_notifier = notifier;
+       }

and then move this logic to meson_encoder_hdmi_attach()

We can't because we create the connector after the attach.

This would be important if .detach() and .attach() can be called
multiple times (for example during suspend and resume). But I am not
sure if that's a supported use-case.

Attach for now will only be done once at probe, and detach only a remove,
we don't change the bridge chaining while suspend/resume, we only reset the
pipeline state and put the old state back when resuming.

Neil

Best regards,
Martin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel