On Fri, Mar 14, 2025 at 06:40:24PM +0100, Maxime Ripard wrote:
> On Fri, Mar 14, 2025 at 09:59:36AM +0200, Dmitry Baryshkov wrote:
> > On Fri, Mar 14, 2025 at 08:45:17AM +0100, Maxime Ripard wrote:
> > > On Fri, Mar 14, 2025 at 07:52:35AM +0200, Dmitry Baryshkov wrote:
> > > > On Fri, Mar 14, 2025 at 08:50:29AM +0800, Andy Yan wrote:
> > > > > At 2025-03-13 19:55:33, "Maxime Ripard" <mrip...@kernel.org> wrote:
> > > > > >Hi,
> > > > > >
> > > > > >On Thu, Mar 13, 2025 at 04:09:54PM +0800, Andy Yan wrote:
> > > > > >> At 2025-03-05 19:55:19, "Andy Yan" <andys...@163.com> wrote:
> > > > > >> >At 2025-03-04 19:10:47, "Maxime Ripard" <mrip...@kernel.org>
> > > > > >> >wrote:
> > > > > >> >>With the bridges switching over to drm_bridge_connector, the
> > > > > >> >>direct
> > > > > >> >>association between a bridge driver and its connector was lost.
> > > > > >> >>
> > > > > >> >>This is mitigated for atomic bridge drivers by the fact you can
> > > > > >> >>access
> > > > > >> >>the encoder, and then call
> > > > > >> >>drm_atomic_get_old_connector_for_encoder() or
> > > > > >> >>drm_atomic_get_new_connector_for_encoder() with drm_atomic_state.
> > > > > >> >>
> > > > > >> >>This was also made easier by providing drm_atomic_state directly
> > > > > >> >>to all
> > > > > >> >>atomic hooks bridges can implement.
> > > > > >> >>
> > > > > >> >>However, bridge drivers don't have a way to access
> > > > > >> >>drm_atomic_state
> > > > > >> >>outside of the modeset path, like from the hotplug interrupt
> > > > > >> >>path or any
> > > > > >> >>interrupt handler.
> > > > > >> >>
> > > > > >> >>Let's introduce a function to retrieve the connector currently
> > > > > >> >>assigned
> > > > > >> >>to an encoder, without using drm_atomic_state, to make these
> > > > > >> >>drivers'
> > > > > >> >>life easier.
> > > > > >> >>
> > > > > >> >>Reviewed-by: Dmitry Baryshkov <dmitry.barysh...@linaro.org>
> > > > > >> >>Co-developed-by: Simona Vetter <simona.vet...@ffwll.ch>
> > > > > >> >>Signed-off-by: Maxime Ripard <mrip...@kernel.org>
> > > > > >> >>---
> > > > > >> >> drivers/gpu/drm/drm_atomic.c | 45
> > > > > >> >> ++++++++++++++++++++++++++++++++++++++++++++
> > > > > >> >> include/drm/drm_atomic.h | 3 +++
> > > > > >> >> 2 files changed, 48 insertions(+)
> > > > > >> >>
> > > > > >> >>diff --git a/drivers/gpu/drm/drm_atomic.c
> > > > > >> >>b/drivers/gpu/drm/drm_atomic.c
> > > > > >> >>index
> > > > > >> >>9ea2611770f43ce7ccba410406d5f2c528aab022..b926b132590e78f8d41d48eb4da4bccf170ee236
> > > > > >> >> 100644
> > > > > >> >>--- a/drivers/gpu/drm/drm_atomic.c
> > > > > >> >>+++ b/drivers/gpu/drm/drm_atomic.c
> > > > > >> >>@@ -985,10 +985,55 @@
> > > > > >> >>drm_atomic_get_new_connector_for_encoder(const struct
> > > > > >> >>drm_atomic_state *state,
> > > > > >> >>
> > > > > >> >> return NULL;
> > > > > >> >> }
> > > > > >> >> EXPORT_SYMBOL(drm_atomic_get_new_connector_for_encoder);
> > > > > >> >>
> > > > > >> >>+/**
> > > > > >> >>+ * drm_atomic_get_connector_for_encoder - Get connector
> > > > > >> >>currently assigned to an encoder
> > > > > >> >>+ * @encoder: The encoder to find the connector of
> > > > > >> >>+ * @ctx: Modeset locking context
> > > > > >> >>+ *
> > > > > >> >>+ * This function finds and returns the connector currently
> > > > > >> >>assigned to
> > > > > >> >>+ * an @encoder.
> > > > > >> >>+ *
> > > > > >> >>+ * Returns:
> > > > > >> >>+ * The connector connected to @encoder, or an error pointer
> > > > > >> >>otherwise.
> > > > > >> >>+ * When the error is EDEADLK, a deadlock has been detected and
> > > > > >> >>the
> > > > > >> >>+ * sequence must be restarted.
> > > > > >> >>+ */
> > > > > >> >>+struct drm_connector *
> > > > > >> >>+drm_atomic_get_connector_for_encoder(const struct drm_encoder
> > > > > >> >>*encoder,
> > > > > >> >>+ struct
> > > > > >> >>drm_modeset_acquire_ctx *ctx)
> > > > > >> >>+{
> > > > > >> >>+ struct drm_connector_list_iter conn_iter;
> > > > > >> >>+ struct drm_connector *out_connector = ERR_PTR(-EINVAL);
> > > > > >> >>+ struct drm_connector *connector;
> > > > > >> >>+ struct drm_device *dev = encoder->dev;
> > > > > >> >>+ int ret;
> > > > > >> >>+
> > > > > >> >>+ ret =
> > > > > >> >>drm_modeset_lock(&dev->mode_config.connection_mutex, ctx);
> > > > > >> >>+ if (ret)
> > > > > >> >>+ return ERR_PTR(ret);
> > > > > >> >
> > > > > >> >It seems that this will cause a deadlock when called from a
> > > > > >> >hotplug handling path,
> > > > > >> >I have a WIP DP diver[0], which suggested by Dmitry to use this
> > > > > >> >API from a
> > > > > >> >&drm_bridge_funcs.detect callback to get the connector, as
> > > > > >> >detect is called by drm_helper_probe_detect,
> > > > > >> >which will hold connection_mutex first, so the deaklock happens:
> > > > > >> >
> > > > > >> >
> > > > > >> >drm_helper_probe_detect(struct drm_connector *connector,
> > > > > >> > struct drm_modeset_acquire_ctx *ctx,
> > > > > >> > bool force)
> > > > > >> >{
> > > > > >> > const struct drm_connector_helper_funcs *funcs =
> > > > > >> > connector->helper_private;
> > > > > >> > struct drm_device *dev = connector->dev;
> > > > > >> > int ret;
> > > > > >> >
> > > > > >> > if (!ctx)
> > > > > >> > return drm_helper_probe_detect_ctx(connector,
> > > > > >> > force);
> > > > > >> >
> > > > > >> > ret =
> > > > > >> > drm_modeset_lock(&dev->mode_config.connection_mutex, ctx);
> > > > > >> > if (ret)
> > > > > >> > return ret;
> > > > > >> >
> > > > > >> > if (funcs->detect_ctx)
> > > > > >> > ret = funcs->detect_ctx(connector, ctx, force);
> > > > > >> > else if (connector->funcs->detect)
> > > > > >> > ret = connector->funcs->detect(connector, force);
> > > > > >> > else
> > > > > >> > ret = connector_status_connected;
> > > > > >> >
> > > > > >> > if (ret != connector->status)
> > > > > >> > connector->epoch_counter += 1;
> > > > > >> >
> > > > > >> >So I wonder can we let drm_bridge_funcs.detect pass a connector
> > > > > >> >for this case ?
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >[0]https://lore.kernel.org/linux-rockchip/047eecfc-7e55-44ec-896f-13fe04333...@gmail.com/T/#m25bc53b79f5cc7bddfcb7aae5656f68df396f094
> > > > > >> >>+
> > > > > >> >>+ drm_connector_list_iter_begin(dev, &conn_iter);
> > > > > >> >>+ drm_for_each_connector_iter(connector, &conn_iter) {
> > > > > >> >>+ if (!connector->state)
> > > > > >> >>+ continue;
> > > > > >> >>+
> > > > > >> >>+ if (encoder == connector->state->best_encoder) {
> > > > > >> >>+ out_connector = connector;
> > > > > >>
> > > > > >>
> > > > > >> When try to use this patch in my bridge driver, I found that the
> > > > > >> connector->state->best_encoder
> > > > > >> maybe NULL when drm_bridge_funcs.detect or
> > > > > >> drm_bridge_funcs.detect_ctx is called:
> > > > > >>
> > > > > >> [ 52.713030] Invalid return value -22 for connector detection
> > > > > >> [ 52.713539] WARNING: CPU: 7 PID: 288 at
> > > > > >> drivers/gpu/drm/drm_probe_helper.c:602
> > > > > >> drm_helper_probe_single_connector_modes+0x5e0/
> > > > > >> 0x63c
> > > > > >> [ 52.714568] Modules linked in:
> > > > > >>
> > > > > >> [ 52.724546] Call trace:
> > > > > >> [ 52.724762]
> > > > > >> drm_helper_probe_single_connector_modes+0x5e0/0x63c (P)
> > > > > >> [ 52.725319] drm_mode_getconnector+0x2a4/0x488
> > > > > >> [ 52.725711] drm_ioctl_kernel+0xb4/0x11c
> > > > > >> [ 52.726057] drm_ioctl+0x22c/0x544
> > > > > >> [ 52.726358] __arm64_sys_ioctl+0xac/0xe0
> > > > > >> [ 52.726706] invoke_syscall+0x44/0x100
> > > > > >> [ 52.727039] el0_svc_common.constprop.0+0x3c/0xd4
> > > > > >>
> > > > > >> This is because best_encoder is set by set_best_encoder, which is
> > > > > >> called from
> > > > > >> drm_atomic_helper_check_modeset. When we call
> > > > > >> drm_mode_getconnector
> > > > > >> for the first time, the functions mentioned above have not been
> > > > > >> called yet,
> > > > > >> then we can't match the encoder from
> > > > > >> connector->state->best_encoder for this case.
> > > > > >
> > > > > >As far as I'm concerned, it's by design. Encoders and connectors have
> > > > > >1:N relationship, and only once a connector has been enabled it has
> > > > > >an
> > > > > >encoder.
> > > > > >
> > > > > >If the connector is disabled, there's no associated encoder.
> > > > >
> > > > > Does this prove that this API is not suitable for my application
> > > > > scenario:
> > > > > Get the connector in the bridge's .detect callback, so this means
> > > > > that I may
> > > > > still need to modify the bridge's connector callback so that it can
> > > > > pass the connector ?
> > > >
> > > > I'd say, yes, please.
> > >
> > > And I'd say no :)
> >
> > Fair enough :-)
> >
> > > There's no reason to deviate from the API other entities have here. It's
> > > just that the switch to DRM_BRIDGE_ATTACH_NO_CONNECTOR hasn't been
> > > completely thought through and it's one of the part where it shows.
> > >
> > > We have two alternative solutions: Either the driver creates the
> > > connector itself, since it doesn't seem to use any downstream bridge
> > > anyway, or we need a new bridge helper to find the connector on a bridge
> > > chain.
> > >
> > > We have the iterator already, we just need a new accessor to retrieve
> > > the (optional) connector of a bridge, and if there's none, go to the
> > > next bridge and try again.
> >
> > The problem is that there is no guarantee that the the created connector
> > is created for or linked to any bridge. For example, for msm driver I'm
> > waiting for several series to go in, but after that I plan to work on
> > moving connector creation to the generic code within the msm driver.
> >
> > In other words, with DRM_BRIDGE_ATTACH_NO_CONNECTOR in place it is
> > perfectly legit not to have a bridge which has "connector of a bridge".
> > It is possible to create drm_bridge_connector on the drm_encoder's side
> > after the drm_bridge_attach() succeeds.
>
> Sure, but then I'd expect detect and get_modes to only be called *after*
> that connector has been created, right?
Yes. But you can not get the connector by following bridge chain. Well,
unless you include encoder into the chain. If that's what you have had
in mind, then please excuse me, I didn't understand that from the
beginning.
But frankly speaking, I think it might be easier to pass down the
connector to the detect callback (as drm_connector_funcs.detect already
gets the connecor) rather than making bridge drivers go through the
chain to get the value that is already present in the caller function.
(For some other usecases I'd totally agree with you, especially if the
connector isn't already available on the caller side).
> Returning NULL in the case where we don't have a connector (yet?) in
> such a case would make total sense to me, just like we return NULL if
> the connector is disabled and doesn't have an encoder here.
>
> Maxime
--
With best wishes
Dmitry
