On Mon, Sep 27, 2021 at 09:43:44PM +0200, Maxime Ripard wrote:
> On Thu, Sep 23, 2021 at 03:29:37AM +0300, Laurent Pinchart wrote:
> > Hi Maxime,
> >
> > Thank you for the patch.
> >
> > I know this has already been merged, but I have a question.
> >
> > On Fri, Sep 10, 2021 at 03:09:39PM +0200, Maxime Ripard wrote:
> > > Display drivers so far need to have a lot of boilerplate to first
> > > retrieve either the panel or bridge that they are connected to using
> > > drm_of_find_panel_or_bridge(), and then either deal with each with ad-hoc
> > > functions or create a drm panel bridge through drm_panel_bridge_add.
> > >
> > > In order to reduce the boilerplate and hopefully create a path of least
> > > resistance towards using the DRM panel bridge layer, let's create the
> > > function devm_drm_of_get_next to reduce that boilerplate.
> > >
> > > Signed-off-by: Maxime Ripard <maxime@xxxxxxxxxx>
> > > ---
> > > drivers/gpu/drm/drm_bridge.c | 42 ++++++++++++++++++++++++++++++++----
> > > drivers/gpu/drm/drm_of.c | 3 +++
> > > include/drm/drm_bridge.h | 2 ++
> > > 3 files changed, 43 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > > index a8ed66751c2d..10ddca4638b0 100644
> > > --- a/drivers/gpu/drm/drm_bridge.c
> > > +++ b/drivers/gpu/drm/drm_bridge.c
> > > @@ -28,6 +28,7 @@
> > > #include <drm/drm_atomic_state_helper.h>
> > > #include <drm/drm_bridge.h>
> > > #include <drm/drm_encoder.h>
> > > +#include <drm/drm_of.h>
> > > #include <drm/drm_print.h>
> > >
> > > #include "drm_crtc_internal.h"
> > > @@ -51,10 +52,8 @@
> > > *
> > > * Display drivers are responsible for linking encoders with the first bridge
> > > * in the chains. This is done by acquiring the appropriate bridge with
> > > - * of_drm_find_bridge() or drm_of_find_panel_or_bridge(), or creating it for a
> > > - * panel with drm_panel_bridge_add_typed() (or the managed version
> > > - * devm_drm_panel_bridge_add_typed()). Once acquired, the bridge shall be
> > > - * attached to the encoder with a call to drm_bridge_attach().
> > > + * devm_drm_of_get_bridge(). Once acquired, the bridge shall be attached to the
> > > + * encoder with a call to drm_bridge_attach().
> > > *
> > > * Bridges are responsible for linking themselves with the next bridge in the
> > > * chain, if any. This is done the same way as for encoders, with the call to
> > > @@ -1233,6 +1232,41 @@ struct drm_bridge *of_drm_find_bridge(struct device_node *np)
> > > return NULL;
> > > }
> > > EXPORT_SYMBOL(of_drm_find_bridge);
> > > +
> > > +/**
> > > + * devm_drm_of_get_bridge - Return next bridge in the chain
> > > + * @dev: device to tie the bridge lifetime to
> > > + * @np: device tree node containing encoder output ports
> > > + * @port: port in the device tree node
> > > + * @endpoint: endpoint in the device tree node
> > > + *
> > > + * Given a DT node's port and endpoint number, finds the connected node
> > > + * and returns the associated bridge if any, or creates and returns a
> > > + * drm panel bridge instance if a panel is connected.
> > > + *
> > > + * Returns a pointer to the bridge if successful, or an error pointer
> > > + * otherwise.
> > > + */
> > > +struct drm_bridge *devm_drm_of_get_bridge(struct device *dev,
> > > + struct device_node *np,
> > > + unsigned int port,
> > > + unsigned int endpoint)
> > > +{
> > > + struct drm_bridge *bridge;
> > > + struct drm_panel *panel;
> > > + int ret;
> > > +
> > > + ret = drm_of_find_panel_or_bridge(np, port, endpoint,
> > > + &panel, &bridge);
> > > + if (ret)
> > > + return ERR_PTR(ret);
> > > +
> > > + if (panel)
> > > + bridge = devm_drm_panel_bridge_add(dev, panel);
> > > +
> > > + return bridge;
> >
> > I really like the idea, I've wanted to do something like this for a long
> > time. I however wonder if this is the best approach, or if we could get
> > the panel core to register the bridge itself. The part that bothers me
> > here is the assymetry in the lifetime of the bridges, the returned
> > pointer is either looked up or allocated.
> >
> > Bridge lifetime is such a mess that it may not make a big difference,
> > but eventually we'll have to address that problem globally.
>
> We can't have Rust soon enough :)
:-) Jokes aside, Rust or C, this would need a design overhaul as a first
step.
> Does it really matter though? I thought the bridges couldn't be unloaded
> from a DRM device anyway, so for all practical purposes this will be
> removed at around the same time: when the whole DRM device is going to
> be teared down?
Try to unbind a bridge device from its driver in sysfs, and it won't be
pretty.
--
Regards,
Laurent Pinchart
