[PATCH 1/3] drm/bridge: Add a function to abstract away panels

[Maxime Ripard]

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 at cerno.tech>
> > ---
> >  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 :)

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?

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20210927/5b40f0ae/attachment.sig>