[PATCH v2 4/6] drm/meson: encoder_hdmi: switch to bridge DRM_BRIDGE_ATTACH_NO_CONNECTOR
Neil Armstrong
narmstrong at baylibre.com
Mon Oct 18 00:50:00 PDT 2021
Hi,
On 16/10/2021 00:07, Martin Blumenstingl wrote:
> Hi Neil,
>
> On Fri, Oct 15, 2021 at 4:11 PM Neil Armstrong <narmstrong at baylibre.com> wrote:
>>
>> 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 <narmstrong at baylibre.com>
>> Acked-by: Sam Ravnborg <sam at ravnborg.org>
> 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 at googlemail.com>
>
> [...]
>> + pdev = of_find_device_by_node(remote);
> I am wondering if we should use something like:
> encoder_hdmi->cec_notifier_pdev
>
>> + 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
>
More information about the linux-arm-kernel
mailing list