[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFBinCBwO0CJMPA3K6e8OxXcinzrA5LrSqaKu1XtZPWLXT8Krw@mail.gmail.com>
Date: Sat, 16 Oct 2021 00:34:05 +0200
From: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To: Neil Armstrong <narmstrong@...libre.com>, sam@...nborg.org
Cc: daniel@...ll.ch, Laurent.pinchart@...asonboard.com,
dri-devel@...ts.freedesktop.org, linux-amlogic@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 6/6] drm/meson: encoder_cvbs: switch to bridge with ATTACH_NO_CONNECTOR
Hi Neil, Hi Sam,
On Fri, Oct 15, 2021 at 4:11 PM Neil Armstrong <narmstrong@...libre.com> wrote:
[...]
> +static const struct drm_bridge_funcs meson_encoder_cvbs_bridge_funcs = {
> + .attach = meson_encoder_cvbs_attach,
> + .enable = meson_encoder_cvbs_enable,
> + .disable = meson_encoder_cvbs_disable,
> + .mode_valid = meson_encoder_cvbs_mode_valid,
> + .get_modes = meson_encoder_cvbs_get_modes,
> + .atomic_enable = meson_encoder_cvbs_atomic_enable,
I did some testing on boards where u-boot doesn't initialize the video outputs.
It seems that meson_encoder_cvbs_enable() is never called with this patch.
meson_encoder_cvbs_atomic_enable() is called though.
>From what I can see in drm_bridge.c [0] this is even expected.
Does this mean that we need to move all logic from .enable to
.atomic_enable (and same with .disable -> moving that logic to
.atomic_disable)?
The same comment applies to the HDMI patch.
Best regards,
Martin
[0] https://elixir.bootlin.com/linux/v5.15-rc5/source/drivers/gpu/drm/drm_bridge.c#L717
Powered by blists - more mailing lists