[PATCH v14 2/3] drm: bridge: panel: Add drmm_panel_bridge_add_nodrm

[Jagan Teki]

On Mon, Feb 27, 2023 at 11:17 PM Maxime Ripard <maxime at cerno.tech> wrote:
>
> On Mon, Feb 27, 2023 at 11:02:30PM +0530, Jagan Teki wrote:
> > drmm_panel_bridge_add_nodrm is an another type of DRM-managed action
> > helper with nodrm pointer.
> >
> > DRM pointer is required to perform DRM-managed action,
> > - The conventional component-based drm bridges, the DRM pointer can
> >   access in component ops bind API.
> > - The non-component-based bridges (like host DSI bridges), the DRM
> >   pointer can access only when a specific bridge has been found
> >   via bridge->dev.
> >
> > This drmm_panel_bridge_add_nodrm helper exclusively for the
> > non-component-based bridges.
> >
> > Cc: Maxime Ripard <mripard at kernel.org>
> > Cc: Laurent Pinchart <Laurent.pinchart at ideasonboard.com>
> > Cc: Linus Walleij <linus.walleij at linaro.org>
> > Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> > Signed-off-by: Jagan Teki <jagan at amarulasolutions.com>
>
> It's the third or fourth time I'm telling you this, and second time
> today.

Apologies for this.

>
> You keep respinning that patch, but the issue lies in the samsung
> driver. Fix it and you won't need that helper.

This is where all get' stuck. You mentioned in a previous e-mail was,

"I'm not quite sure what you mean. You shouldn't retrieve the bridge from
the attach hook but from the probe / bind ones. If that's not working
for you, this is a bug in the documentation we should address."

If I understand correctly this would be the third case from the bridge
documentation
https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges

"The upstream driver uses the component framework and is a MIPI-DSI
host. The bridge device uses the MIPI-DCS commands to be controlled.
This is the same situation as above, and can run
mipi_dsi_host_register() in either its probe or bind hooks."

But the problem here, The samsung-dsim bridge common bridge across
Exynos and i.MX8MM.
So, the
- Upstream Exynos is component-based and
- Upstream i.MX8MM is non-component-based

With this dual scenario, retrieving the bridge pointer in a bind will
work for the Exynos case, and retrieving the bridge pointer in bridge.
attach will work for i.MX8MM. This is what I mentioned deadlock
scenario in a previous e-mail.

Hope you clear the real issue now.

Thanks,
Jagan.